> -----Original Message----- > From: Benjamin Kaduk via Datatracker <[email protected]> > Sent: Wednesday, June 10, 2020 6:45 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; Matthew Miller <[email protected]>; > [email protected] > Subject: Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with > DISCUSS and COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-cose-rfc8152bis-algs-09: Discuss > > 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I think we need to check the [MAC] reference; following links (and chasing > redirects) seems to only find a 1985 publication that talks about DES, with no > mention of AES-CBC-MAC. [JLS] This is one of the dangers of using algorithms are not considered to be "good". The first attacks on it were published in 2000 as far as I know. This is why we should be using CMAC but too many people only do the CBC-MAC.
This is the reference that NIST SP800-38B uses A. Menezes, P. van Oorschot, S. Vanstone, Handbook of Applied Cryptography, CRC Press, Inc., Boca Raton (1996). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > It's interesting that both -struct and -algs make the claim in the Abstract > that > "this specification describes how to create and process signatures, message > authentication codes, and encryption using CBOR for serialization". Shouldn't > that only be true for one of them? > > I'd really like to see a reference for the analysis of and validity/safety of > the > deviations from RFC 5869 HKDF, in Section 5.1. [JLS] I am going to assume you are referring to using AES for the PRF. I don't know if such a thing exists. I can tell you where I got my personal analysis however. When the TLS 1.3 design group was meeting in Seattle, I spent about 20 minutes discussion what the required capabilities of the PRF are needed to get things to work correctly. At least part of the discussion in the group which occurred around the same time was the ability to break the two halves of HKDF separated the way that TLS does. Found something: https://eprint.iacr.org/2010/264.pdf look in appendix D point 4. > > Section 1 > > Should we refer to RFC 8259 by its STD number (90)? Done > > Section 1.3 > > We don't seem to use the "AE" term (just -struct does). [JLS] I copied over the new definitions from -struct. I would rather have it than not have it. > > Section 2.1.1 > > Note: Use of a deterministic signature technique is a good idea even > when good random number generation exists. Doing so both reduces the > > Note the ongoing work in the CFRG on "deterministic signatures with additional > randomness" (the name has been changing a bit recently), and fault attacks on > deterministic signatures. Done - including the reference. > > Section 2.2.1 > > How public values are computed is not the same when looking at EdDSA > and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they > should not be used with the other algorithm. > > Just to check: the claim is that EdDSA and ECDH compute public values > differently (not EdDSA and ECDSA?), but that EdDSA keys should not be used > with algorithms other than EdDSA? [JLS] > > If batch signature verification is performed, a well-seeded > cryptographic random number generator is REQUIRED. Signing and non- > batch signature verification are deterministic operations and do not > need random numbers of any kind. > > RFC 8032 doesn't talk about "batch" at all, so a reference is probably in > order. [JLS] Section 8.2 of RFC 8032. It looks like they changed the wording a bit from an earlier verion. > > Section 3.1 > > Some recipient algorithms transport the key, while others derive a > key from secret data. For those algorithms that transport the key > (such as AES Key Wrap), the size of the HMAC key SHOULD be the same > size as the underlying hash function. For those algorithms that > derive the key (such as ECDH), the derived key MUST be the same size > as the underlying hash function. > > "same size as the output of the underlying hash function", please -- hash > functions can also have an internal block size that is larger. [JLS] Done. > > Section 3.2.1 > > * A single key must only be used for messages of a fixed or known > length. If this is not the case, an attacker will be able to > > What's an example of a known-but-not-fixed length message? Just something > with internal framing? [JLS] This is a length extension problem. You need to know that the message you validated is the same length as the message that was MAC-ed by the sender. This is the reason for CMAC coming into existence. > > Section 4.1 > > The Galois/Counter Mode (GCM) mode is a generic authenticated > encryption block cipher mode defined in [AES-GCM]. The GCM mode is > combined with the AES block encryption algorithm to define an AEAD > cipher. > > GCM on its own is merely AE but AES-GCM is AEAD? That doesn't seem to add > up... [JLS] Actually, GCM is not an AE algorithm, it is a mode. Ok - it now reads AEAD. > > Section 6.1.2 > > If the salt/nonce value is generated randomly, then it is suggested > that the length of the random value be the same length as the hash > function underlying HKDF. While there is no way to guarantee that it > > "output length of the hash function", please. [JLS] Done. > > Section 6.2, 6.3, 6.4 > > Why does Direct Key [encryption] get its own top-level subsection with > reference to -struct, but we jump straight into AES Key Wrap without a > wrapping "Key Wrap" subsection or -struct reference, and likewise for "Direct > Key Agreement" and "Key Agreement with Key Wrap"? It feels like Section 6.1 > is the outlier here. > > Section 6.3 > > be unique for the pair of keys being used. It is acceptable to > use a global counter that is incremented for every static-static > operation and use the resulting value. When using static keys, > > Perhaps say something strongly worded about storing the updated counter > value to permanent storage before using the resulting key? [JLS] Done. > > Section 7.2 > > s/X25591/X25519/ [JLS] Yep > > Section 8 > > The algorithm identifier is not part of the capabilities data as it > should already be part of message structure. There is a presumption > in the way that this is laid out is that the algorithm identifier > > nit: strike the last "is". > > itself is not needed to be a part of this as it is specified in a > different location. > > nit(?): "be a part of this" is a little vague/informal. > > capabilities. This means that if one wishes to enumerate all of the > capabilities for a device which implements ECDH, it requires multiple > pairs of capability structures (algorithm, key) to deal with the > different key types and curves that are supported. For a key, the > > An example of this would be pretty helpful. > > Section 8.1 > > * OKP, EC2: The list of capabilities is: > > - The key type value. (1 for OKP or 2 for EC2.) > > - One curve for that key type from the "COSE Elliptic Curve" > registry. > > Am I reading this right that the idea is to use capabilities to lock a key > down to > a single curve? > > * Symmetric: The list of capabilities is: > > - The key type value (4). > > but we're not using this opportunity to indicate whether a symmetric key is > for > encryption vs. HMAC? > > Section 8.2 > > (from the "COSE Key Types" Registry). It is expected future > registered algorithms could have zero, one, or multiple elements. > > nit: missing "that". [JLS] Section 8 has been re-written - you are going to need to review again. > > Section 10 > > Is [this document] going to be added as a reference on these registries? > Should it replace or augment 8152 in that role? [JLS] We will see what happens w/ the question I sent to Barry about Jean-Marc's DISCUSS on -struct. It applies to this document as well. > > I think that the COSE Header Algorithm Parameters Registry updates need to > be in this document, not -struct. [JLS] Done. > > Section 10.1, 10.2 > > Do we want to say anything about the encoded verson of the Capabilities array > being an array of integers? [JLS] It isn't. I can be either integers or text strings. > > Section 10.2 > > Why is the word "reserved" in the description for the IV-GENERATION > algorithm? [JLS] I did reserve this at one point and finally am registering it. - Gone. > > Section 11 > > I'm not 100% sure that we want the security considerations to be so close to > identical between -struct and -algs. [JLS] I will take another pass at trying to delete things. > > One area that has been starting to get exposure is doing traffic > analysis of encrypted messages based on the length of the message. > > I think this may have graduated from "starting" to be more of a mainstream > thing :) [JLS] I guess I should go and see if you had any other comments. > > Section 12.1 > > Trying to chase [MAC] gives me a "reference has moved" notice. > I guess there's a newer version? [JLS] Why do I feel like I discussed this one already? -- Ah - because it is a Discuss. > > Section 12.2 > > I think RFC 8017 needs to be normative, since we use it for I2OSP [JLS] Yeah - that makes sense. > > Acknowledgments > > Göran could probably get his proper name, now. [JLS] done. > > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
