> ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Daniel Migault for the SECDIR review. > > ** Duplicate normative guidance. Please say it once. > (a) Instance #1 > > -- Section 4 > For this reason, it is inappropriate to use AES-CTR with static keys. > Extraordinary measures would be needed to prevent reuse of an IV value with > the > static key across power cycles. To be safe, implementations MUST use fresh > keys > with AES-CTR. > > -- Section 8 > Therefore, it is inappropriate to use AES-CTR with static keys. Extraordinary > measures would be needed to prevent reuse of a counter block value with the > static key across power cycles. To be safe, implementations MUST use fresh > keys > with AES-CTR.
Okay. It was dropped from Section 8 in my edit buffer. > (b) Instance #2 > > -- Section 4 > Implementations MUST use AES-CTR in conjunction with an authentication and > integrity mechanism, such as a digital signature. > > -- Section 8 > Accordingly, implementations MUST use AES-CTR in conjunction with an > authentication and integrity mechanism, such as a digital signature Okay. It was dropped from Section 8 in my edit buffer. > (c) Instance #3 > > -- Section 4 > Implementations MUST use AES-CBC in conjunction with an authentication and > integrity mechanism, such as a digital signature. > > -- Section 8 > Accordingly, implementations MUST use of AES-CBC in conjunction with an > authentication and integrity mechanism, such as a digital signature. Okay. It was dropped from Section 8 in my edit buffer. > ** Section 6. Consistent guidance to implementers: > > -- Section 5 > Since AES-CBC cannot provide integrity protection for external additional > authenticated data, the decryptor MUST ensure that no external additional > authenticated data was supplied. (aside, similar text in Section 4 for > AES-CTR) > > -- Section 6 > 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. > > Wouldn’t it be more appropriate to say “must return an error”? Silent failure > seems like a bad idea and inconsistent with the protocol guidance. I changed Section 6 in my edit buffer: 6. Implementation Considerations COSE libraries that support either AES-CTR or AES-CBC and accept Additional Authenticated Data (AAD) as input MUST return an error if one of these non-AEAD content encryption algorithm is selected. This ensures that a caller does not expect the AAD to be protected when the cryptographic algorithm is unable to do so. > ** Section 8 > Since AES has a 128-bit block size, regardless of the mode employed, the > ciphertext generated by AES encryption becomes distinguishable from random > values after 2^64 blocks are encrypted with a single key. Implementations > should change the key before before reaching this limit. > > -- Typo. s/before before/before/ Fixed in my edit buffer. > -- Why would it be safe to continue to use the key past 2^64 blocks? If the ciphertext is distinguishable from random values, then it is not safe. > ** Section 8. Editorial. > Since AES-GCM uses AES-CTR for encryption, an attacker can switch the > algorithm > identifier from AES-GCM to AES-CTR, and then strip the authentication tag to > bypass the authentication and integrity, allowing the attacker to manipulate > the ciphertext. > > This is the first reference to AES-GCM. All other modes got a definition. > Please explain or cite. Reference added. I realized that this is true for AES-CCM as well. So it now reads: Since AES-CCM [RFC3610] and AES-GCM [GCMMODE] use AES-CTR for encryption, an attacker can switch the algorithm identifier to AES- CTR, and then strip the authentication tag to bypass the authentication and integrity, allowing the attacker to manipulate the ciphertext. Russ _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
