Alternative Elliptic Curve Representations
draft-ietf-lwig-curve-representations-23
Discuss
Yes
Erik Kline
No Objection
(Andrew Alston)
(Robert Wilton)
Abstain
No Record
Deb Cooley
Gunter Van de Velde
Jim Guichard
Mahesh Jethanandani
Orie Steele
Éric Vyncke
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Roman Danyliw
Discuss
Discuss
(2023-02-02)
Sent
** 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
(2023-01-31)
Sent
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
Erik Kline
Yes
John Scudder
No Objection
Comment
(2023-01-27)
Not sent
I support Lars’s DISCUSS.
Paul Wouters
No Objection
Comment
(2023-02-02)
Sent for earlier
I fully support Roman's DISCUSS. I also agree with Lars, which is the reason I'm balloting No Objection. I feel the document is not telling the full story of the price to pay for this code re-use effort. After all, Section 10 and 12 is requesting code points JOSE / COSE, so this effort is not simply something that is limited in scope to implementaton details. There is a price to facilitate this. The reason I am not objecting to the code points, is that the registry defines a range for non-standard track "specification required" entries. But I agree with Roman that these entries cannot have "Recommended: Y". NOTE 2: At this point, 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. (For cryptographic module validation program guidance, see, e.g., [FIPS-140-2].) This note should be re-evaluated as it is based on FIPS-140-2 which was obsoleted by FIPS-140-3 about 4 years ago. If the note is still valid, the reference should be updated. Note that storage would have reduced to a single 64-byte table if only the Curve25519 curve would have been generated so as to be isomorphic to a Weierstrass curve with hardcoded a=-3 parameter (this corresponds to l=1). This feels like aimed at a discussion and/or implementer that is not in scope for this document. The Privacy Considerations text feels out of scope for this document. Open IANA Expert issue: 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."
Warren Kumari
No Objection
Comment
(2023-02-01)
Not sent
I'm balloting "NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term, with a strong emphasis on the "outside my area of expertise" bit. While the document might not have been within the charter of LWIG, the fact remains that it *was* discussed and progressed there, and went through IETF LCed, etc - penalizing the authors and WG for an administrative failure seems unfair.
Zaheduzzaman Sarker
No Objection
Comment
(2021-07-14 for -21)
Not sent
I also support Lars's discuss.
Francesca Palombini
Abstain
Comment
(2023-02-02)
Sent
I concur with others' ballots about this not being in scope for lwig, and I am not sure why it was not instead moved to CFRG as it was originally suggested by Magnus. Giving the history and the several reviews from the crypto panel I will not block, but I don't think it is correct to ballot No Objection. A couple of points below. As Roman noted in his COMMENT (which could be raised to a DISCUSS level IMO): the IANA requested values that are in the Standards Action With Expert Review range should not be assigned, since this is an Informational. I trust that the responsible AD, the DE for the registries and IANA will pay attention to that. Thanks to Erik Thormarker for his review; Erik raised the two points below: * What is the reason for the y-coordinate of the basepoint for Wei25519 (appendix E in draft) to be in this document the inverse of the basepoint of W-25519 in NIST draft 186-5? * Clarification question: why would someone want to use ECDSA with Wei25519 instead of P-256? Has this been clarified in the document? Francesca
Murray Kucherawy
(was No Objection)
Abstain
Comment
(2023-01-31)
Not sent
I don't want to obstruct this document's progress further, but I am balloting ABSTAIN on the basis that LWIG was not chartered to produce this work, which is something that should've been sorted out long before it came to the IESG.
Deb Cooley
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
Mahesh Jethanandani
No Record
Orie Steele
No Record
Éric Vyncke
No Record
Alissa Cooper Former IESG member
No Objection
No Objection
(2021-02-17 for -19)
Not sent
I support Magnus' DISCUSS.
Alvaro Retana Former IESG member
No Objection
No Objection
(2021-07-13 for -21)
Not sent
I support Lars' DISCUSS.
Andrew Alston Former IESG member
No Objection
No Objection
()
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2021-02-17 for -19)
Not sent
I second Magnus’s DISCUSS.
Deborah Brungard Former IESG member
No Objection
No Objection
(2021-02-17 for -19)
Not sent
Agree with Magnus's Discuss -
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2023-01-31)
Sent for earlier
This document is not in scope for LWIG. In the interest of not further blocking publication, I choose to ballot "No Objection", but I am deeply concerned that we let a WG work on something outside its charter for so long.
Robert Wilton Former IESG member
No Objection
No Objection
(for -21)
Not sent
Magnus Westerlund Former IESG member
(was Discuss)
No Record
No Record
(2021-03-09 for -20)
Sent for earlier
Clearing my discuss as I step down. Responsible AD will have to address the issues in my discuss, copied below. So this discuss is on the process violations that has occurred for this document. The first which is fairly straightforward to address is in regards to that the document would require a new IETF last call for proposed standard as it was last called only as informational on 2020-08-25. However, there is no point of doing this before the second part of this discuss has been addressed. The second part of the discuss is that this document is out of charter for the LWIG WG. The LWIG charter is clear on that the WG shall not define protocols, only describe how one does implementation that are lightweight but standard compliants. Thus, the document in its current form where it define a number of new curves is thus outside of this charter and that needs to be addressed before this work has a chance to be progressed. I think it is important that this is taken serious as this work defines new curves even if derived from existing ones do need proper review in relevant WG or RG where interested parties are more likely to see and comment on this work. I think a good illustration of this is the reaction in COSE WG when people become aware of this work. So lets look at what I think are a couple of potential ways of dealing with this, in falling preferences from my perspective. 1) Move the draft to an appropriate WG/RG, I think CFRG could be a reasonable choice but I assume the SEC ADs might have better guidance on this. 2) Rewrite the document to fit the LWIG chartered scope, i.e. not define any new curves only document how one can realize existing standard curves using the transform method in this document. 3) Recharter LWIG to allow this work. I think this is a bad choice as doing security standard specification appears to be out of scope. 4) Declare the work dead A path here needs to be chosen. I can understand that this is frustrating for the author and other proponents. However, there appear to exist venues within IETF and IRTF which do works on curve specifications and their application to various protocols. Thus, we need to use these to ensure proper review. I don't think there is much reason to try to place any blame here. There are multiple parties that appears to have made less than optimal decision during the process since WG adoption. What is clear to me is that the scope of the draft has crept from its original adoption into LWIG when it appears to have been in scope from my brief review of the 00.