[Lwip] Roman Danyliw's Discuss on draft-ietf-lwig-curve-representations-23: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 02 February 2023 16:04 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: lwip@ietf.org
Delivered-To: lwip@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E71C14EB1E; Thu, 2 Feb 2023 08:04:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lwig-curve-representations@ietf.org, lwig-chairs@ietf.org, lwip@ietf.org, Mohit Sethi <mohit.m.sethi@ericsson.com>, mohit.m.sethi@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 9.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <167535386545.57502.16281019729244053325@ietfa.amsl.com>
Date: Thu, 02 Feb 2023 08:04:25 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/Cx5GshF9diRI0B9-tPs07n12AMk>
Subject: [Lwip] Roman Danyliw's Discuss on draft-ietf-lwig-curve-representations-23: (with DISCUSS and COMMENT)
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2023 16:04:25 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-lwig-curve-representations-23: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/



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

** Section 12.2.1, 12.2.2, 12.3.1, 12.3.2, 12.3.3.  These five registrations
are requesting “Recommended: Yes” value.  Could the basis of the answer to
“Does the IETF have a consensus recommendation to use the algorithm?” (the
definition of this field) be described?  Given that this document has
informational status and it saw limited review from the WG due to the topic, it
isn’t clear that this document is consensus recommendation.  I think it should
be "Recommended: No".

** Holding a marker with a DISCUSS on resolution of IANA review issues:
-- Expert comments: OIDs have been approved. JOSE experts had approved version
12, but new reviews are pending. A COSE expert writes that he hasn't seen a
detailed response to his February review and adds, "As I remember the overall
conclusion the COSE WG meeting Feb 17 confirmed that registrations should
follow current practice, and that, e.g., ES256K is an exception not to be
followed."

-- see COMMENT on assigned code points to
https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves and
https://www.iana.org/assignments/cose/cose.xhtml#algorithms


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

Thank you for the Benjamin Smith for the 2021 Crypto Panel Review

Thank you to Stanislav Smyshlyaev for the 2018 Crypto Panel Review

Thank you to Russ Housley for the SECDIR review.

I share the assessment originally made by Magnus Westerlund and then Lars
Eggert (and supported by 7 other ADs) that this document is not in scope for
the LWIG charter.  I’m deeply appreciative of the multiple Crypto Panel
reviewers stepping in to assess a document.

** Section 1.  One of the motivations for this document is stated to be code
reuse.  Additional support for this this claim would be beneficial.

-- I don’t deeply understand the ecosystem of cryptographic libraries used in
low power devices (the focus of LWIG), but using the three implementations in
Section 7, none appear to be focused on code reuse.  [Rosener] and
https://community.nxp.com/docs/DOC-330199 both appear to focus on performance. 
The ANSSI motivations are stated as “both keep the library core mathematical
foundations simple and keep the defense-in-depth.”

-- Section 4.1, Note 2, cautions that “it is unclear whether a FIPS-accredited
module implementing the co-factor Diffie-Hellman scheme with, e.g., P-256 would
also extend this accreditation to the Montgomery versions X25519+ or X25519”
which suggests that the code reuse might not be possible in select cases.

-- The second Crypto Panel review by Benjamin Smith
(https://mailarchive.ietf.org/arch/msg/crypto-panel/qB5WvocRX9o_UyOdeHw_L2GSaBY/)
also points areas of clarity on making the reuse argument.

** Section 12.2.1, 12.2.2, 12.3.1, 12.3.2, 12.3.3  This will be addressed by
appropriate registry DE.  I’ll note that the requested value of -1 (per
12.2.1), -24 (per 12.2.2), -2 (per 12.3.1), -48 (per 12.3.2) and -49 (per
12.3.3) will not be assigned.  The registration policy for this range of values
is Standards Action, and this document does not meet this threshold.  See
https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves and
https://www.iana.org/assignments/cose/cose.xhtml#algorithms