- From: <Frederick.Hirsch@nokia.com>
- Date: Thu, 29 Nov 2012 18:29:40 +0000
- To: <public-xmlsec@w3.org>
- CC: <Frederick.Hirsch@nokia.com>, <mnystrom@microsoft.com>
- Message-ID: <1CB2E0B458B211478C85E11A404A2B2701832EF3@008-AM1MPN1-034.mgdnok.nokia.com>
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 endecryption 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<http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.src.html#bib-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>
Received on Thursday, 29 November 2012 18:30:15 UTC