Attribute encryption and low entropy

Hi, Joseph,

Thanks for the information on the discussion of element and attribute.
My personal opinion is that XML-Encryption SHOULD support attribute
encryption. The reason is as you have mentioned... our standard should
be "bad-design-tolerant"... Indeed in some cases perhaps it is not
even a problem of bad-design..

For the plain text entropy problem.. we are mostly concerned with the
ECB (Electronic Codebook) attack or others... and this happens mostly
when encrypting a small atribute value or even a small enough element.


In order to overcome this problem, XML-Encryption may recommend several
techniques, e.g.,

1. Each time when encrypting a small text, a different symmetric encryption
key "SHOULD" be used (either with RSA-or ECIES-encryption of the session random
symmetric key, or with different ECDH or DH ephemeral exponents). That is,
a pre-shared symmetric key MUST not be used.

2. The plain-text MUST be padded with session randomness and then encrypted
in CBC mode.

I also suggest that XML encryption SHOULD before XML-DSIG (though
this might not be possile in practice for all the time). I am not sure whehter
we can specify this. But otherwise, signature schemes will leak the plain-text
information for sure. Especially, if the encrypted part can be
dictionary-guessed.
(e.g., the small attribute value... the attacker can guess the value of it
and then hash it to compare with the signed hash value)...

Yongge



> The problem is that it is not so easy to say, "well sorry, that's bad
> design." As a bit of history, there was a fair amount of argument about what
> features went into XML1.0 itself. Folks argued about what bits to throw out
> and extend (attributes, namespaces, PIs, encodings, etc.) from its mother
> tongue, SGML. In fact, these arguments continue to this day [1] in the form
> of proposals for the next version (2.0) or alternative versions (Simple
> XML). We're fortunate that the arguments about XML 1.0 are over, but we're
> unfortunate in that it is what it is, warts and all! People do use
> attributes in ways that have heterogeneous security requirements.
>
> [1] http://xmlhack.com/read.php?item=116
>
> In the other XML security application <smile> I recall the WG having a
> difficult time trying to come up with the conventions/rules for determining
> when to store a data value in an attribute value or element content [2].
> While we were concerned with issues of terseness (keep it small in attribute
> values), requirements for nested structures (if it needs to be extended,
> make it an element), and the features provided by attributes such as
> defaults (#FIXED) and attribute typing [3] (ID, IDREF, IDREFS), how things
> would be encrypted was not one of them! This is one of the contributing
> factors to the maxim that we can't expect people to design their schemas to
> our convenience.
>
> [2] http://www.w3.org/Signature/Drafts/xmldsig-ed-conventions-19991019.html
> [3] http://www.w3.org/TR/REC-xml#sec-attribute-types
>
> We can make an informed decision balancing application requirements against
> design/implementation complexity. On the issue of application requirements,
> we've had folks argue this is, and is not a requirement. This sort of
> argument doesn't resolve with a satisfying "aha!" because the words can just
> keep going back and forth, but I tend to err on the side of inclusion if a
> chunk of people think it's important. On the issue of complexity, we've had
> folks argue it's unnecessarily complex, and on this issue I tend to err on
> the side of simplicity unless it's demonstrated otherwise. However, to that
> end, Ed's taken the effort to demonstrate that what he wants to do *is*
> possible, which I very much appreciate.
>
> I haven't made up my mind yet, as I'm still learning a lot in this
> discussion. I suspect that if we don't do attribute encryption, when the WG
> starts and represents that in its requirement document and proposal, we'll
> certainly hear from a broader audience about it! I'm also wondering if
> there's a middle ground between Blair/Phil/Thane's point of view and
> Ed/Steve/Sanjeev's point of view so the WG could migrate its design if need
> be once we start getting wider review, and I suspect this would also serve
> the effort of hitting the end user sweet spot of scope versus complexity
> (forcing attribute encryption implementation on everyone versus abandoning
> the requirements of a part of the community.) Instead of being two complete
> proposals, something that could be easily plugged in. Sort of like we ended
> up doing with XPath and Signature. This might not be achievable in this
> instance (need to think more) and we might just have to make a hard choice!
>
> With respect to plain text entropy and length, I expect we're going to need
> solutions to these problems regardless.

Received on Thursday, 18 January 2001 12:33:18 UTC