Hi Russ, > -----Original Message----- > From: Russ Housley <[email protected]> > Sent: 16 May 2023 16:14 > To: Rob Wilton (rwilton) <[email protected]> > Cc: IESG <[email protected]>; [email protected]; Cose > Chairs Wg <[email protected]>; cose <[email protected]>; > [email protected] > Subject: Re: Robert Wilton's No Objection on draft-ietf-cose-aes-ctr-and-cbc- > 04: (with COMMENT) > > > > ---------------------------------------------------------------------- > > 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). [Rob Wilton (rwilton)]
I'll leave to the authors/WG to decide whether this text is useful for including. I thought that there might have been a RFC that you could have pointed to. > > > (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. [Rob Wilton (rwilton)] Okay. > > > (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. [Rob Wilton (rwilton)] Presumably these aren't currently used (because they don't have a value assigned), and if users should always use a different protocol in preference (because these are marked as deprecated), then I'm struggling to understand why we are publishing this at all? Or in summary, I think that the calling them deprecated may cause confusion. Thanks, Rob > > Russ _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
