Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-webauthn-algorithms-07: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 10 Jun 2020 21:20:40 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cose-webauthn-algorithms-07: 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-webauthn-algorithms/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As Roman notes, the conversion of secp256k1 to not-recommended in the
-07 was incomplete: Table 2 and the prose below it still need to be
adjusted.  (Putting this in the discuss section so I remember to
double-check it when the new revision arrives.)

Also, I think we need to more strongly reiterate the cross-algorithm
risk, specifically mentioned in Section 2.1.1 of
draft-ietf-cose-rfc8152bis-algs-09, regarding an attacker changing
headers from secp256r1 to secp256k1 (or vice versa), and that the only
known way to deal with this attack is to limit any given protocol
participant to using at most one of the two curves.  (AFAIK neither
'alg' nor 'crv' are required to be protected elements, so while limiting
this curve to the ES256K algorithm helps in many cases, is not a
fail-safe.)

Finally, my apologies for not catching this earlier, but the COSE
charter says that the WG deliverable to "define the algorithms needed
for W3C Web Authentication for COSE" is to be an Informational document.
It looks like we didn't notice that when the WG -00 was submitted and it
has just been carried through unchanged.  (Note, however, that the
requested values for ES256K and secp256k1 are in the "Standards Action"
range and would not be available for an informational document.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Are we planning to update the section references from RFC 8152 to the
bis documents also on this telechat?

Section 2

I see that the IANA registry currently lists RS256 as
Recommended:Deprecated, but this document lists it as Recommended:No.
Which is correct?

Section 3.1

   preserved.  If the uncompressed representation is used, the "y" value
   represented MUST likewise be exactly 256 bits, with any leading zeros
   preserved; if the compressed representation is used, the "y" value
   MUST be a boolean value, as specified in Section 13.1.1 of [RFC8152].

At least the "MUST be a boolean value" is fully redundant with RFC 8152,
and might not need normative language.

Section 3.3

   This specification defines how to use the secp256k1 curve for ECDSA
   signatures for both JOSE and COSE implementations.  While in theory,
   the curve could also be used for ECDH-ES key agreement, it is beyond
   the scope of this specification to state whether this is or is not
   advisable.  Thus, whether to recommend its use with ECDH-ES is left
   for experts to decide in future specifications.

This text doesn't really do a great job at reflecting the potential
concerns/risks described at
https://mailarchive.ietf.org/arch/msg/cose/kS25kvSH85dcyzZi1lcU2-6yDEE/
-- "there may be theoretical problems with the curve" seems worth
noting!

Section 5.2

If we're going to mention exponent restrictions from Section 8.3 of RFC
7518 in Section 5.3, we should probably mention them here as well.

Section 5.3

   New COSE applications MUST NOT use this algorithm.

Is it new applications, or new protocols, or something else?