> -----Original Message-----
> From: Benjamin Kaduk <[email protected]>
> Sent: Monday, June 29, 2020 9:58 PM
> To: Jim Schaad <[email protected]>
> Cc: [email protected]; [email protected];
'Matthew
> Miller' <[email protected]>; 'The IESG' <[email protected]>;
> [email protected]
> Subject: Re: [COSE] Benjamin Kaduk's Discuss on
draft-ietf-cose-rfc8152bis-
> algs-09: (with DISCUSS and COMMENT)
>
> 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?
[JLS] In the construction that is being used in COSE, I think that it would
be just fine as the CBOR array is being built by the validator and thus
cannot be directly attacked. More generally, I think this construct is much
more susceptible to the bit twiddling attacks on CBC that just having the
length prefixed would be. This is be more true if the length is prefixed by
the validator rather than carried over the wire. I could be completely
wrong.
>
> [...]
> > > > > 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)
[JLS] Fixed.
>
> > > > >
> > > > > 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
