RE: Xenc Requirements req - comments on security and other issues

Resulting document:
    http://www.w3.org/Encryption/2001/03/21-xml-encryption-req.html

At 15:46 3/28/2001 +0100, Amir Herzberg wrote:
>Joseph,
>
>Having joined the discussions recently, I took your note as motivation to go
>over this document [1]

Thank you for your comments Amir.

>Substantive comments:
>1. In section 5 (Security), item 3.2: I believe there is a bigger potential
>security exposure using `encrypt before you sign`, specifically that with
>some encryption algorithm we lost the non-repudiation property which is such
>an important feature of public key signatures. Specifically, if the signer
>can find two messages m1 and m2 and two keys k1 and k2 which encrypt to the
>same ciphertext (E_k1(m1)=E_k2(m2)), then signing only ciphertext will allow
>the signer to select later whether to claim he signed m1 (sharing key k1
>with recipient) or m2 (sharing k2). This can be solved by either signing
>(also) the plaintext, of course using techniques as I described in my other
>note to prevent confidentiality exposure, or by using an encryption
>algorithm where finding such pairs is infeasible.

The non-repudiation for signing (E_k1(m1)) stands if that is what is signed. 
Of course, what that blob means is an issue of the transforms and how they 
are written; this is addressed in the signature spec. (There are XSLT 
transforms one could do before signature which has a similar problem.) As 
you suggest, doing the transforms well mitigates this problem, if you want 
to suggest some text for the spec, I think that would be a good thing. (I've 
been waiting for the thread to settle before asking my Chair question of, 
"Ok, who would like to propose some text for the Security Concerns". 
<smile/>) For the requirements, I'm not sure if you are challenging that we 
should provide recommendations about encrypt-then-sign, or are merely 
offering another example of why it's important. To help me better 
understand, if you are suggesting a change to the Requirements, could 
you  please propose exactly the change (plug-and-play).

>2. Ditto, item 2: I think this volunerability implies there should be an
>integrity check mechanism as part of XENC, which I believe is not in the doc
>(section 3) presently.

3.4.7 states:
Message Authentication {FTF1}: AES/3DES with SHA1 is optional to implement.

At the FTF we said:
Resolution: If anyone is an advocate of specifying encryption with a 
corresponding integrity algorithm, please write up a proposal - the 
workgroup is amenable to it, but it is not required. ... 4.2.7 Message 
authentication We will do some integrity, such as a checksum, combined with 
the encryption; at least one encryption + checksum category will be 
included; AES with SHA1 and 3DES with SHA1; see earlier discussion on IV as 
part of <CipherText>; encryption with an MDC

If you don't think this is captured in the Requirements please suggest 
specific text.

>3. Ditto, item 3.1 and 4.1: First, I think these two comments are too
>similar and should be merged. Secondly, we should say that this weakness
>`may exist unless the hashing/signature takes appropriate precautions`.

Ok 4.1 is stricken. The requirements merely require that the spec address 
it, and leaves it to the spec. (Plus, all these vulnerabilities exist unless 
precautions are taken, the point of this section is to identify those that 
must be addressed by the spec...?)

>4. In section 3.3 (Requirements / Processing), item 6., Encryption and
>Signatures: I think there is another option we should explore, that will
>allow an application to sign securely plaintext, ciphertext or both, and the
>verifier can verify or not the plaintext as he wishes. We just began
>discussing this on the list and all I suggest is for now to either remove
>the `applications have the following options` sentence or add a mention that
>there is still discussion on this.

Ok, added "The WG is continuing to discuss these options and others."

>Minor comments:
>
>1. First sentence of section 2. is obscure to me, i.e. what you mean by
>`describes requirements over intended result`. Maybe just a language
>problem.

Now reads:
2. Design Principles and ScopeThis section describes high level principles 
of design and definition of scope. They are an expression of 
intent/motivation. How these motivations are realized are addressed in 
subsequent sections.


>2. In section 3.3 (Requirements / Processing), item 1.3, a typo in second
>line (`a lterations to particular DOM and/or XML parser implementations`)
>3. Ditto, item 2.2, should be `following` not `follow`
>4. Ditto, item 5.1, at the end: should be `encrypting it` not `encrypted`

fixed.


__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Wednesday, 28 March 2001 19:25:22 UTC