Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 10 Jun 2020 18:45:09 -0700

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.

----------------------------------------------------------------------
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.

Section 1

Should we refer to RFC 8259 by its STD number (90)?

Section 1.3

We don't seem to use the "AE" term (just -struct does).

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.

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?

   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.

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.

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?

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...

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.

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?

Section 7.2

s/X25591/X25519/

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".

Section 10

Is [this document] going to be added as a reference on these registries?
Should it replace or augment 8152 in that role?

I think that the COSE Header Algorithm Parameters Registry updates need
to be in this document, not -struct.

Section 10.1, 10.2

Do we want to say anything about the encoded verson of the Capabilities
array being an array of integers?

Section 10.2

Why is the word "reserved" in the description for the IV-GENERATION
algorithm?

Section 11

I'm not 100% sure that we want the security considerations to be so
close to identical between -struct and -algs.

   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 :)

Section 12.1

Trying to chase [MAC] gives me a "reference has moved" notice.
I guess there's a newer version?

Section 12.2

I think RFC 8017 needs to be normative, since we use it for I2OSP

Acknowledgments

Göran could probably get his proper name, now.

---

From: Jim Schaad <[email-masked]>
Date: Thu, 18 Jun 2020 10:53:10 -0700

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[email-masked]>
> Sent: Wednesday, June 10, 2020 6:45 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Matthew Miller <[email-masked]>;
> [email-masked]
> Subject: Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with
> DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> 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).

> 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.

> Should we refer to RFC 8259 by its STD number (90)?
Done

> 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.

> 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.

> differently (not EdDSA and ECDSA?), but that EdDSA keys should not be used
> with algorithms other than EdDSA?
[JLS] 
> 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.
 
> "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.

> 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.

> 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.

> "output length of the hash function", please.
[JLS] Done.

> 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
> 
[JLS] Done.

> s/X25591/X25519/
[JLS] Yep

> Am I reading this right that the idea is to use capabilities to lock a key down to
> a single curve?
> 
> but we're not using this opportunity to indicate whether a symmetric key is for
> encryption vs. HMAC?
> 
> Section 8.2
> 
[JLS] Section 8 has been re-written - you are going to need to review again.

> 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.

> Why is the word "reserved" in the description for the IV-GENERATION
[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.

> 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.

> I guess there's a newer version?
[JLS] Why do I feel like I discussed this one already?  -- Ah - because it is a Discuss.

> I think RFC 8017 needs to be normative, since we use it for I2OSP
[JLS] Yeah - that makes sense.

> Göran could probably get his proper name, now.
[JLS] done.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 20 Jun 2020 19:27:35 -0700

> 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).

> [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 grou…

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] 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 :)

> [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…

Okay.  Would "self-describing length" work?

> [JLS] Section 8 has been re-written - you are going to need to review again.

Okay, I'll wait for the new revision.

> [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] 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.

> > Göran could probably get his proper name, now.

Thanks for the updates; I'll look for the revised I-D.

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Wed, 24 Jun 2020 19:45:08 -0700

> From: Benjamin Kaduk <[email-masked]>
> Sent: Saturday, June 20, 2020 7:28 PM
> To: Jim Schaad <[email-masked]>
> Cc: 'The IESG' <[email-masked]>; [email-masked];
cose-
> [email-masked]; 'Matthew Miller' <[email-masked]>;
> [email-masked]
> Subject: Re: [COSE] Benjamin Kaduk's Discuss on
draft-ietf-cose-rfc8152bis-
> algs-09: (with DISCUSS and COMMENT)
> 
> > > Subject: Benjamin Kaduk's Discuss on
> > > draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT)
> > >
> > > 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
> > > 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.

> > [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.
of
> K(1) that "may be advisable with other PRF modes (such as CBC-MAC)".
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.

> > > 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

> > > 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.
helpful :)
> > [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.
> 
[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.

> > > Am I reading this right that the idea is to use capabilities to lock
> > > a key down to a single curve?
> > >
> > > but we're not using this opportunity to indicate whether a symmetric
> > > key is for encryption vs. HMAC?
> > >
> > > Section 8.2
> > >
> > [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.
> 
[JLS] No it was a private note, and it is going to be done.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 29 Jun 2020 21:58:02 -0700

> > > > draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT)
[...]
> rather just switch to KMAC personally.

Fair enough; the existing construction feels just "weird" enough to make me
not entirely comfortable...

[...]
> 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?

[...]
> > Okay, I'll wait for the new revision.

(This still seems to apply to the -10, now in §8.1)

> [JLS] No it was a private note, and it is going to be done.

Okay, thanks for confirming.  (And for the updates!)

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Tue, 30 Jun 2020 10:07:20 -0700

> Sent: Monday, June 29, 2020 9:58 PM
'Matthew
> Miller' <[email-masked]>; 'The IESG' <[email-masked]>;
> [email-masked]
> > > Cc: 'The IESG' <[email-masked]>;
> > > [email-masked];
> > cose-
> > > > > Cc: [email-masked];
> > > > > [email-masked]; [email-masked]; Matthew Miller
> > > > > <[email-masked]>;
> > > 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
> > > without assigning new codepoints, as it would break interoperability
> > [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...
> > > 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.
> > >
> > 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.
> 
> -- 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.

> > > > [JLS] Section 8 has been re-written - you are going to need to
> > > > review
> > again.
> > >

[JLS] Fixed.