W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2001

Attribute encryption and low entropy

From: Yongge Wang <ywang@certicom.com>
Date: Thu, 18 Jan 2001 12:33:03 -0500
To: xml-encryption@w3.org
Message-ID: <852569D8.005FE69F.00@smtpmail.certicom.com>
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
(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)...


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:01 UTC