On Thu, Jun 18, 2020 at 10:53:10AM -0700, Jim Schaad wrote: > > > > -----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).
That looks like something that would work (though I no longer have an easily accessible copy). > > > > > > ---------------------------------------------------------------------- > > 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. AES-CBC-MAC as the PRF, but also for sometimes skipping the extract step. > Found something: https://eprint.iacr.org/2010/264.pdf look in appendix D > point 4. I think this is probably also what Bob Moskowitz came up with when he was using the analogous CMAC-based KDF for HIP-DEX. Definitely add it as a reference. I do note that "the analytical results in [the CBC-MAC] case are much more restricted than with HMAC" and also that point 5 discusses a modification of K(1) that "may be advisable with other PRF modes (such as CBC-MAC)". I suppose that we cannot safely make that modification at this time, at least without assigning new codepoints, as it would break interoperability with existing deployments.. > > > > 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. I see it now (which just serves to indicate the section reference is helpful :) > > > > 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. Okay. Would "self-describing length" work? > > > > 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. Okay, I'll wait for the new revision. > > > > 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. Was I supposed to see a question you asked Barry in response to Jean-Marc's response to my Discuss ballot? (I don't.) > > > > 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. Oops, I guess I forgot to delete the corresponding COMMENT; sorry. > > > > 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. Thanks for the updates; I'll look for the revised I-D. -Ben _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
