Re: Update to XML Encryption 1.1 editors draft (resend with PDF)

Frederick,

I still find recommendation #1 a bit murky.  There's an extraneous "of" in 
there, but even with that removed, we might be able to improve it further. 
 Part of the problem lies in that we're talking about both symmetric keys 
and asymmetric keypairs in the same sentence.  I would suggest that the 
recommendation for asymmetric processing is that one SHOULD use a 
different keypair for data privacy than that used for data integrity. 
Furthermore, for symmetric keys, I would suggest the recommendation is 
that key material used in one algorithm SHOULD NOT be used in another, and 
if one is to use the key for both privacy and integrity, then it SHOULD 
only be used that way if it is used as a base for separately-derived keys 
for each function.

Bruce A Rich
brich at-sign us dot ibm dot com




From:   <Frederick.Hirsch@nokia.com>
To:     <mnystrom@microsoft.com>
Cc:     <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>
Date:   11/30/2012 03:11 PM
Subject:        Re: Update to XML Encryption 1.1 editors draft (resend 
with PDF)



(retry with PDF instead of image) 

Magnus 

Changing "can" to "may be able to" in the first bullet list of the 
Backwards Compatibility Attacks section seems fine to me, it really 
doesn't change the meaning.

Re-ordering the bullets for the recommendations seems ok, and the change 
to the statement about Always using different keys seems to simplify it 
without a substantial change to the meaning. 

I'm not sure we should make the proposed  change to the second bullet in 
the re-ordered recommendations :

Changing the MUST to MAY for rejecting documents with RSA-PKCS#1 v1.5 and 
AES-CBC in the case where  chosen cipher text attacks are possible seems 
to remove the substance of the recommendation, so I suggest we not make 
this change.

what do others think of Magnus's proposed changes (attached is image of 
redline for the archive)

regards, Frederick

Frederick Hirsch
Nokia



On Nov 29, 2012, at 1:29 PM,  wrote:

Comment from Magnus: 

I would suggest a slight rewording, see below.
Motivations:
a)      The success of an attacker is not a given; it depends on many 
factors including computational power, scenario, etc. Therefore switching 
from the definitive “can” to “may be able to” makes more sense to me.
b)      Clarify when the recommendations apply in particular
c)       For the recommendations, I’d like to start with the generic one 
which is to always follow good key hygiene practice. It can also be 
shortened to just cover the actual recommendation.
d)      For the (now) first recommendation, the private key is only used 
for decryption, not encryption, thus that proposed change.
e)      For the (now) second recommendation, I observe that it may not 
always be necessary or possible to do the restriction; hence the “When 
appropriate” part. As for the last sentence, it is again a little 
dependent on the scenario (e.g.: Can the attacker even mount a chosen 
ciphertext attack) and I would suggest we therefore strike it and satisfy 
with the recommendation to not use the modes known to be secure in 
chosen-cipher text attacks.
 
-- Magnus
 
6.1.3 Backwards Compatibility Attacks
Use of state-of-the-art and secure encryption algorithms such as RSA-OAEP 
and AES-GCM can become insecure when the adversary can force the server to 
process eavesdropped ciphertext with legacy algorithms such as RSA-PKCS#1 
v1.5 or AES-CBC [NDSS-2012-TLS]:
1.      The attacker can may be able to break the security of an AES-GCM 
ciphertext if he is able to force the server to process the ciphertext 
with AES-CBC and the same symmetric key.
2.      The attacker can may be able to decrypt an RSA-OAEP ciphertext if 
he is able to force the server to process the ciphertext with RSA-PKCS#1 
v1.5 and the same asymmetric key.
3.      The attacker can may be able to forge valid server signatures if 
the server decrypts RSA-PKCS#1 v1.5 ciphertexts and the signatures are 
computed with the same asymmetric key pair.
Accordingly, in situations where an attacker may be able to mount 
chosen-ciphertext attacks, we recommend the following to implementers:
1.      2. It is a bad cryptographic practice to apply the same 
cryptographic keys for different cryptographic tasks and algorithms. We 
recommend enforcing Always use of different keys for public key en
decryption and signature processing (ciphertext decryption and signature 
creation) and different keys for different algorithms, even if serving a 
similar function. This can be done using derived keys basing the 
derivation on the algorithm identifier, for example
2.      1. When appropriate, restrict algorithm usage to algorithms known 
to be secure in the face of chosen-ciphertext attacks (RSA-OAEP, AES-GCM). 
In that case, documents containing RSA-PKCS#1 v1.5 and AES-CBC ciphertexts 
must may be rejected without decryption.Allowing use of either RSA-PKCS#1 
v1.5 or AES-CBC is dangerous.






On Nov 29, 2012, at 12:29 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:

I have updated the XML Encryption 1.1 editors draft with a new security 
consideration section [1] 

[[
6.1.3 Backwards Compatibility Attacks
Use of state-of-the-art and secure encryption algorithms such as RSA-OAEP 
and AES-GCM can become insecure when the adversary can force the server to 
process eavesdropped ciphertext with legacy algorithms such as RSA-PKCS#1 
v1.5 or AES-CBC [XMLENC-BACKWARDS-COMP]:
1.      The attacker can break the security of an AES-GCM ciphertext if he 
is able to force the server to process the ciphertext with AES-CBC and the 
same symmetric key.
2.      The attacker can decrypt an RSA-OAEP ciphertext if he is able to 
force the server to process the ciphertext with RSA-PKCS#1 v1.5 and the 
same asymmetric key.
3.      The attacker can forge valid server signatures if the server 
decrypts RSA-PKCS#1 v1.5 ciphertexts and the signatures are computed with 
the same asymmetric key pair.
Accordingly, we recommend the following to implementers:
1.      Restrict algorithm usage to algorithms known to be secure in the 
face of chosen-ciphertext attacks (RSA-OAEP, AES-GCM). In that case, 
documents containing RSA-PKCS#1 v1.5 and AES-CBC ciphertexts must be 
rejected without decryption. Allowing use of RSA-PKCS#1 v1.5 and AES-CBC 
is dangerous.
2.      It is a bad cryptographic practice to apply the same cryptographic 
keys for different cryptographic tasks and algorithms. We recommend 
enforcing use of different keys for public key encryption and signature 
processing (ciphertext decryption and signature creation).
]]

This is based on the proposed text from Juraj and Tibor, attached.

I am aware of a comment from Magnus which I will share to the list after 
this message.

regards, Frederick

Frederick Hirsch
Nokia

[1] 
http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.src.html#sec-backwards-compatibility-attacks



<bc-attacks.txt>

[attachment "proposed-change.pdf" deleted by Bruce Rich/Austin/IBM]