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

How about changing that last “May” to a “Should” instead? After all, it is a recommendation.

-- Magnus

From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
Sent: 30 November, 2012 13:10
To: Magnus Nystrom
Cc: Frederick.Hirsch@nokia.com; public-xmlsec@w3.org
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 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>