Hi, This is useful. Thanks for driving this. Some comments:
- RFC 8152 is obsolete - "NIST has defined several modes of operation for use with AES [MODES]. Each of these modes has different characteristics. The five modes are: ECB (Electronic Code Book), CBC (Cipher Block Chaining)..." Mentioning ECB as a NIST defined method without stating anything more is dangerous. Some might think it gives similar properties as CTR and CBC and use it instead. NIST now finally states that "the use of ECB to encrypt confidential information constitutes a severe security vulnerability", which should have been done a long time ago. I suggest removing all mention of ECB and just write that CTR and CBC are two modes of operation defined by NIST. https://csrc.nist.gov/news/2022/proposal-to-revise-sp-800-38a - "This document specifies AES-CTR and AES-GCM" Should be AES-CBC - "For example, the same keying material must not be used with AES-CTR and AES-GCM." Not wrong, but maybe you meant CBC here as well? - "Since AES-CTR cannot provide integrity protection for external additional authenticated data" It cannot provide integrity protection for COSE internal aad either. Can AES-CTR be used with protected headers? Should the implementor still create an Enc_structure? - "Since AES-GCM uses AES-CTR for encryption, an attacker can switch the algorithm identifier from AES-GCM to AES-CTR" An attacker can also switch other header parameters such as content type, kid, IV, Partial IV, kid context, etc... The draft should probably make recommendations on integrity protecting all header parameters with the mandatoty authentication and integrity mechanism. Or fixing them outside of COSE. - AES-CTR seems less specified than the other COSE encryption algorithms including AES-CBC. The IV length is not specified, and it is not specified how to combine initial IV with the block counter (or LFSR). Given COSE with AES-GCM, and IV, and a key, two implementations can talk to each other. This is not true for the AES-CTR COSE algorithm as currently specified. As they anyway need to agree on an external integrity algorithm this is not a big problem, but it should probably be mentioned. Cheers, John From: COSE <[email protected]> on behalf of Mike Prorock <[email protected]> Date: Tuesday, 17 January 2023 at 23:43 To: Russ Housley <[email protected]> Cc: Mike Jones <[email protected]>, cose <[email protected]>, Cose Chairs Wg <[email protected]> Subject: Re: [COSE] WGLC of draft-ietf-cose-aes-ctr-and-cbc I believe this document is ready. Mike Prorock mesur.io<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-297abd84feb9f9cf&q=1&e=b577a9dc-bd0f-4393-9e79-c1593c208293&u=http%3A%2F%2Fmesur.io%2F> On Tue, Jan 17, 2023, 14:44 Russ Housley <[email protected]<mailto:[email protected]>> wrote: Of course, I this this document is ready to go forward to the iESG. Russ On Jan 17, 2023, at 4:39 PM, Mike Jones <[email protected]<mailto:[email protected]>> wrote: Dear all, This message starts the Working Group Last Call of draft-ietf-cose-aes-ctr-and-cbc – https://datatracker.ietf.org/doc/html/draft-ietf-cose-aes-ctr-and-cbc . The working group last call will run for two weeks, ending on Tuesday, January 31, 2023. Please review and send any comments or feedback to the working group. Even if your feedback is "this is ready", please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
