On Wed, Jun 24, 2020 at 07:45:08PM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk <[email protected]> > > Sent: Saturday, June 20, 2020 7:28 PM > > To: Jim Schaad <[email protected]> > > Cc: 'The IESG' <[email protected]>; [email protected]; > cose- > > [email protected]; 'Matthew Miller' <[email protected]>; > > [email protected] > > Subject: Re: [COSE] Benjamin Kaduk's Discuss on > draft-ietf-cose-rfc8152bis- > > algs-09: (with DISCUSS and COMMENT) > > > > 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) > > > > [...] > > > > > > > > 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.. > > [JLS] I have not seen that before. It is interesting but since it is not in > the RFC I am not sure that doing so would be a good idea. I think I would > rather just switch to KMAC personally.
Fair enough; the existing construction feels just "weird" enough to make me not entirely comfortable... [...] > > > > 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? > [JLS] I think so, but a large part depends on what you mean by > "self-describing length". If you started with a two byte value which is > the length of the data then yes I think that would work. I would be worried > about the ability to do any bit-flipping on this but I think it would kill > the extension attack. However, if you are using CBOR and have an array of 4 > elements that would not work. To be clear: I'm not advocating a change to the text here. But I'm not sure I understand why a CBOR array of 4 elements would not work -- the individual elements within the array are themselves self-describing, so in toto the overall length is "self-describing", isn't it? [...] > > > > 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. (This still seems to apply to the -10, now in ยง8.1) > > > > > > > > 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.) > [JLS] No it was a private note, and it is going to be done. Okay, thanks for confirming. (And for the updates!) -Ben _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
