Re: [COSE] COSE Support for AES-CTR and AES-CBC

[Russ Housley <[e-mail]>]

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