https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-08 has been
published and contains the changes described below to address Ben's comments,
as well as explaining the basis of the “not recommended” registration in
Section 5.4, per Roman's comment. Thanks both for your useful reviews!
-- Mike
-----Original Message-----
From: Mike Jones
Sent: Thursday, June 11, 2020 6:47 AM
To: 'Benjamin Kaduk' <[email protected]>; The IESG <[email protected]>
Cc: [email protected]; [email protected];
[email protected]; Ivaylo Petrov <[email protected]>
Subject: RE: Benjamin Kaduk's Discuss on
draft-ietf-cose-webauthn-algorithms-07: (with DISCUSS and COMMENT)
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 <[email protected]>
Sent: Wednesday, June 10, 2020 9:21 PM
To: The IESG <[email protected]>
Cc: [email protected]; [email protected];
[email protected]; Ivaylo Petrov <[email protected]>; [email protected]
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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
