[COSE] Benjamin Kaduk's No Objection on draft-ietf-cose-webauthn-algorithms-08: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Sat, 13 June 2020 03:12 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-cose-webauthn-algorithms@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov <ivaylo@ackl.io>, ivaylo@ackl.io
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159201792233.5234.6585379937681585593@ietfa.amsl.com>
Date: Fri, 12 Jun 2020 20:12:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/p4hLNgPFzU9fryBT2-JpmC-uWbw>
Subject: [COSE] Benjamin Kaduk's No Objection on draft-ietf-cose-webauthn-algorithms-08: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cose-webauthn-algorithms-08: No Objection

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/



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

Thank you for addressing my review comments.
I would prefer to go even further on the "more strongly reiterate the
cross-algorithm risk" front, perhaps

OLD:
   Care should be taken that a secp256k1 key is not mistaken for a P-256
   [RFC7518] key, given that their representations are the same except
   for the "crv" value.  As described in Section 8.1.1 of [RFC8152], we
   currently do not have any way to deal with this attack except to
   restrict the set of curves that can be used.

NEW:
   Care should be taken that a secp256k1 key is not misinterpreted as a P-256
   [RFC7518] key, given that their representations are the same except
   for the "crv" value.  As described in Section 8.1.1 of [RFC8152], we
   currently do not have any way to deal with this attack except to
   restrict the set of curves that can be used.  In general, any system that is
   willing to accept both "crv" values "secp256k1" and "P256" is vulnerable
   to this substitution attack, absent some external mechanism for integrity
   protecting the  "crv" value used to interpret the key.

[COSE] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker