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? _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
