Robert Wilton has entered the following ballot position for draft-ietf-cose-aes-ctr-and-cbc-04: 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: ---------------------------------------------------------------------- Hi, Thanks for this document. I had a few minor comments for you to consider please: (1) p 2, sec 4. AES Counter Mode When AES-CTR is used as a COSE Content Encryption algorithm, the encryptor generates a unique value that is communicated to the decryptor. This value is called an initialization vector (IV) in this document. The same IV and AES key combination MUST NOT be used more than once. The encryptor can generate the IV in any manner that ensures the same IV value is not used more than once with the same AES key. Is there any RFC that could be referenced here on how to generate suitable IVs? (2) p 4, sec 5. AES Cipher Block Chaining Mode AES-CBC mode requires an 16 octet Initialization Vector (IV). Use of a randomly or pseudo-randomly generated IV ensures that the encryption of the same plaintext will yield different ciphertext. The IV initialization text differs compared to section 4, I assume that this is intentional and these modes have fundamentally different IV initialization requirements? (3) p 6, sec 5.2. AES-CBC COSE Algoritm Identifiers The following table defines the COSE AES-CBC algorithm values. Note that these algorithms are being registered as "Deprecated" to avoid accidental use without a companion integrity protection mechanism. +=========+=======+==========+========================+=============+ | Name | Value | Key Size | Description | Recommended | +=========+=======+==========+========================+=============+ | A128CBC | TBD4 | 128 | AES-CBC w/ | Deprecated | | | | | 128-bit key | | +---------+-------+----------+------------------------+-------------+ | A192CBC | TBD5 | 192 | AES-CBC w/ | Deprecated | | | | | 192-bit key | | +---------+-------+----------+------------------------+-------------+ | A256CBC | TBD6 | 256 | AES-CBC w/ | Deprecated | | | | | 256-bit key | | +---------+-------+----------+------------------------+-------------+ I wanted to check that "Deprecated" is really the best choice for "Recommended" for both AES-CTR and AES-CBC. I read 'deprecated' as meaning that other COSE algorithms should be used in preference to these, but it wasn't clear that is the intent here. I note that this column contains some entries with a value such as "Filter Only", hence wondering it these should be labelled as "Confidentiality only", perhaps with the description indicating that integrity must be handled separately? Thanks, Rob _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
