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

[Roman Danyliw via Datatracker <[e-mail]>]

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


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