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

[Mike Jones <[e-mail]>]

Thanks for your review, Ben.  The one point that you may want to actually discuss during the telechat is whether the document can remain standards track so that it qualifies for "Standards Action" registrations, as described below.  My responses are inline below, prefixed by "Mike>".

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[e-mail]> 
Sent: Wednesday, June 10, 2020 9:21 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Ivaylo Petrov <[e-mail]>; [e-mail]
Subject: Benjamin Kaduk's Discuss on draft-ietf-cose-webauthn-algorithms-07: (with DISCUSS and COMMENT)

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

Mike> Sorry for not catching this in the last round of edits.  I'll make these updates.

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

Mike> OK - I'll enhance this discussion along these lines.

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

Mike> I'd prefer to keep the values in the "Standards Action" range, if we can do that.  Is it possible to get the IESG to allow this document to remain standards track?  I didn't realize that Informational RFCs didn't qualify for "Standards Action".

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

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

Mike> I only plan to update the references of the bis documents finish first.

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?

Mike> Good catch.  It should be "No".  I'll inform IANA.

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.

Mike> OK

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!

Mike> Thanks, I'll add this.

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.

Mike> OK

Section 5.3

   New COSE applications MUST NOT use this algorithm.

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

Mike> I can say "New COSE applications and protocols MUST NOT use this algorithm."

Mike> Thanks again for the thorough review!

				-- Mike