updated XML Encryption 1.1 editors draft for 6.1.3 security consideration

I have updated the XML Encryption 1.1 editors draft section 6.1.3 security consideration, incorporating changes based on Magnus and Bruce comments.

I don't think we need to say "When appropriate" everywhere - that is the purpose of SHOULD, meaning it should be done unless you have a good reason not to...

Any more comments on this text, or is it ok? [cc Juraj and Tibor for review as well]

[[

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 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 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 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.  Implementations should always use a different public key pair for data confidentiality and for data integrity functionality.
  2.  Implementations using asymetric keys should not use the same key material for different algorithms, even if serving the same purpose. Key derivation based on a single key and the algorithm identifier can be used to accomplish this, for example.
  3.  Implementations that plan to use the same asymetric key for both confidentiality and integrity functions should use it as the basis for a key derivation producing different keys for those functions.
  4.  Implementions should 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 should be rejected without decryption.

[XMLENC-BACKWARDS-COMP]
Tibor Jager, Kenneth G. Paterson, Juraj Somorovsky. One Bad Apple: Backwards Compatibility Attacks on State-of-the-Art Cryptography.<http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/> In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2013. URL: http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/

]]

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

On a related note, should we define in XML Encryption 1.1 the specific key derivation function to derive a key based on algorithm identifier and key? I'm concerned about what this means for interop and progressing the specification. If we do need this I suggest we might progress it as an independent specification, but am not sure we need to do this. Thoughts?

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG