John: Thanks for the careful review.
> This is useful. Thanks for driving this. Some comments: > > > - RFC 8152 is obsolete Yes, RFC 9052 was published. I'll reference that. > - "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 > <https://csrc.nist.gov/news/2022/proposal-to-revise-sp-800-38a> Good point. I will gladly drop ECB from the listed modes. Of course, there was never an intent to assign a code point for ECB. > - "This document specifies AES-CTR and AES-GCM" > Should be AES-CBC This typo is fixed. > - "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? Yes. That typo is fixed too. > - "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? The real point is at the send of the sentence: Since AES-CTR cannot provide integrity protection for external additional authenticated data, the decryptor MUST ensure that no external additional authenticated data was supplied. I think we do want to define an alternative for Enc_structure. Wouldn't that be even more disruptive to implementation that wants to support AES-CTR or AES-CBC? > - "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. It already does: With AES-CTR, it is trivial to use a valid ciphertext to forge other (valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to use AES-CTR without a companion authentication and integrity mechanism. Implementations MUST use AES-CTR in conjunction with an authentication and integrity mechanism, such as a digital signature. and: AES-CBC does not provide integrity protection. Thus, an attacker can introduce undetectable errors if AES-CBC is used without a companion authentication and integrity mechanism. Implementations MUST use AES-CBC in conjunction with an authentication and integrity mechanism, such as a digital signature. and: This document specifies AES-CTR and AES-GCM for COSE, which are not authenticated encryption with additional data (AEAD) ciphers. The use of the ciphers is limited to special use cases where integrity and authentication is provided by another mechanism, such as firmware encryption. > - 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. The initial block of key stream is clearly defined by the IV. If we remove the option to use an LFSR, and instead always determine the next counter value by + 1 mod 2^128. Would this resolve the concern? The LFSR came about from RFC 3686, where the counter space is divided in a manner that the first part totally under the control of the sender, so there was no need for the sender and receiver to agree on the way that it is computed. That is not really the situation here, Russ
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
