> ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi,
Hi Rob. > 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? I do not think that we need a reference, but more was said in Section 3.1 of RFC 3686: 3.1. Initialization Vector The AES-CTR IV field MUST be eight octets. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). Including the IV in each packet ensures that the decryptor can generate the key stream needed for decryption, even when some packets are lost or reordered. We could add: Common approaches to IV generation include incrementing a counter for each encryption operation and linear feedback shift registers (LFSRs). > (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? Yes, the IV requirements are very different. > (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? This was the consensus of the COSE WG since these algorithms do not provide both confidentiality and integrity. Russ _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
