Scott: > Introducing AES-CTR and/or AES-CBC into COSE tokens that already support > AES-GCM will open the GCM implementations to new security issues. Namely, > potential padding oracle vulnerabilities.
I think that adding a reference to the existing paragraph in the Security Considerations will address this concern: With AES-CBC mode, implementers SHOULD perform integrity checks prior to decryption to avoid padding oracle vulnerabilities [Vaudenay]. > At minimum, the Security Considerations section of > draft-ietf-cose-aes-ctr-and-cbc-01 needs to call this risk out: Applications > that encrypt or decrypt with AES-GCM *MUST NOT* support AES-GCM or AES-CTR > with the same cryptographic materials, due to the existence of cross-protocol > issues. One way to safeguard users from potential misuse is to use a separate > "type" for keys used with unauthenticated encryption modes; similar to how > COSE distinguishes MACs from Signatures. I suggest an addition paragraph in the Security Considerations: To avoid cross-protocol concerns, implementations MUST NOT use the same keying material with AES-CTR and AES-GCM. Likewise, implementations MUST NOT use the same keying material with AES-CTR and AES-CCM. > Additionally, I'd like to recommend sharing this draft with the CFRG mailing > list to ensure it has the appropriate level of oversight from the IETF's > cryptography experts. AES-CTR and AES-CBC are not new cryptographic modes. New techniques deserve CFRG review, but AES-CTR and AES-CBC have been included in RFCs for many years. Russ
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
