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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.