> On Jan 18, 2023, at 12:55 PM, Ilari Liusvaara <[email protected]> > wrote: > > On Wed, Jan 18, 2023 at 01:53:10PM -0500, Russ Housley wrote: >> Laurence: >> >> Obviously it is too late to add anything to RFC 9052. >> >> I propose the following for draft-ietf-cose-aes-ctr-and-cbc: >> >> X. Implementation Considerations >> >> COSE libraries that support either AES-CTR or AES-CBC and accept >> Additional Authenticated Data (AAD) as input should return an error >> if one of these non-AEAD content encryption algorithm is selected. >> This would ensure that a caller does not expect the AAD to be >> protected when the cryptographic algorithm is unable to do so. > > RFC 9052 already requires that if using AE algorithm: > > - Attempt to encrypt or decrypt with non-empty external aad MUST fail. > - Attempt to encrypt with any protected header parameters MUST fail. > - Atttept to decrypt message with any protected header parameters MUST > fail. > > It seems to me that AES-CTR and AES-CBC are analogous to these, but > with even more serious limitations, so all these limitations should be > inherited.
After reading section 5 in 9052 more carefully, I’d like to suggest that draft-ietf-cose-aes-ctr-and-cbc give normative instructions that say how to use a fully non-authenticated encryption algorithm. Technically speaking, neither 5.2 (AEAD) or 5.3 (AE) apply to AES-CTR or AES-CBC since they have no authentication. Those instructions amount to following 5.3 so it’s not a big deal, but from a standards completeness view it seems necessary. We double-warn about the danger of AES-CTR in draft-ietf-cose-aes-ctr-and-cbc (in the main body and in security considerations) plus its dangers are also well described externally. Thus seems about equivalent to also warn about AAD in draft-ietf-cose-aes-ctr-and-cbc. (For me, there is also still the issue of warning that AEAD doesn’t really provide the same level of authentication that public key signing does, especially with one-time random CEKs, but I will get to that in another message once I understand better how SUIT does sign-then-encrypt). LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
