RE: Xenc Requirements req - comments on security and other issu es

Joe, thanks for your efficient and courteous handling of these belated
comments.

Responding to your note below. To make it easier for you to use my `plug and
play` text I'm sending this message in HTML, not in plain text as I usually
do, hope this will be Ok to most readers (can resend in plaintext if
needed). 

Best regards,
Amir Herzberg
CTO, NewGenPay Inc. 

See our demo and overview/tutorials on secure e-commerce in
http://www.NewGenPay.com <http://www.NewGenPay.com> 

> >1. In section 5 (Security), item 3.2: I believe there is a bigger
potential
> >security exposure using `encrypt before you sign`, specifically that ...
>
> 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.

The problem is beyond that of a transform, since it is the result of the
encryption itself - if proper precautions are not taken. Specifically, a
dishonest signer can send a signed message sign(E_k(m)) but when there's a
dispute, and the recipient is showing <k,E_k(m),sign(E_k(m))>, the sender
produces another pair <k',E_k'(m'),sign()> where E_k'(m')=E_k(m). Or a
dishonest recipient may find such <k',m'>. So I believe XML Encrypt should
address this concern.

In the requirements document we just need to warn about this issue and maybe
mention some known techniques to address it. One technique is to sign the
plaintext (instead or in addition to signing the cihertext), with proper
randomization to prevent guessing attack of course. Another technique is to
use encryption mechanisms where it is infeasible to find <k1,m1> and <k2,m2>
s.t. E_k1(m1)=E_k2(m2).

> 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.

In this comment, I'm suggeting another recommendation that should be added
to the encrypt-then-sign case. I think the existing recommendation there is
also valid. However, notice, that looking back at the motivation cited for
the existing comment, which is a note by Joe Ashwood, I think that note
actually refered to the issue I'm now suggesting to add. That's why I
suggest to use these references for the entire item (maybe adding a
reference to this note or my earlier note). 

> To help me better
> understand, if you are suggesting a change to the Requirements, could
> you  please propose exactly the change (plug-and-play).

Sure. I'll provide it together with my recommended change to item 1 as well
(see discussion below): 



1.	sign before you encrypt: weaknesses if a plaintext hash (inside an
XML Signature) is provided along with the encrypted data, unless proper
precautions are taken (such as properly adding an encrypted random string to
the plaintext before hashing). { List
<http://www.w3.org/Encryption/2001/03/21-xml-encryption-req.html#ref-List> :
Finney
<http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0081.html> } 

2.	encrypt before you sign: potential for fraud if one is induced to
digitally sign encrypted data that may not be what the user expected. Also,
there may be more than one <data,key> pairs resulting in the same encrypted
data, therefore special care must be taken in the selection of the
encryption function or in the signature process to provide non-repudiation
of the data. .{ List
<http://www.w3.org/Encryption/2001/03/21-xml-encryption-req.html#ref-List> :
Wang <http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0071.html>
, Ashwood
<http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0076.html> }


> >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.
 
Yes, but that's authentication, where for that voluerability authentication
may be sufficient; furthermore using MAC may not be feasible if we use
public key encryption and the parties do not (wish to) share a key. 
>
> 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. ...
 
I'll give a try at providing something later, if time permits. 

> 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; 
 
These are fine mechanisms when there is a shared key (and then using MAC is
the right thing). However this does not address the problem for public key
encryption; in this what is needed really is plaintext-aware encryption such
as RSA-OEAP, already specified for key transport.
>
> If you don't think this is captured in the Requirements please suggest
specific text.
 
One addition is in the algorithms, where currently there is simply no
algorithm specified for public key block encryption. I suggest to add
RSA-OEAP, with the same text as now used for key transport, i.e. add in
section 3.4, item 2.2, a new sub-item 4 with content:
 
    4. RSA-OEAP used with AES is required to implement. 
 
Also in section 2,  item 3,  change to:
 
The specification will not address authentication. { List
<http://www.w3.org/Encryption/2001/03/21-xml-encryption-req.html#ref-List> :
Reagle
<http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0017.html> , WS
<http://www.w3.org/Encryption/2001/03/21-xml-encryption-req.html#ref-WS> } .
However, the specification may address ensuring integrity of the decrypted
data. 

>
> >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. 
 
Please see my proposed text above. 
 
...
> >4. In section 3.3 (Requirements / Processing), item 6., Encryption and
> >Signatures: I think there is another option we should...
 
> Ok, added "The WG is continuing to discuss these options and others."
 
thanks!
>
> >Minor comments:
> fixed.
Thanks!

 
[1] Handbook of applied cryptogrpahy, Menezes, van Oorschot and Venstone,
section 8.7.3, p. 311.