Roman Danyliw has entered the following ballot position for draft-ietf-cose-aes-ctr-and-cbc-05: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-aes-ctr-and-cbc/ ---------------------------------------------------------------------- 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. (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 (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. ** 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. ** 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/ -- Why would it be safe to continue to use the key past 2^64 blocks? ** 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. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
