> -----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)
> > >
> > > 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/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > 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?
[JLS] I missed this one - changed.
> > >
> > > 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.
>
>
> > >
> > > 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] Yes
> > >
> > > 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.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.
> > > 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.
Cleaned up.
> > >
> > >
> > > 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.)
[JLS] No it was a private note, and it is going to be 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
