Alternative Elliptic Curve Representations
draft-ietf-lwig-curve-representations-23
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Lars Eggert Discuss
Even with the switch to Informational, I don't see how this document is in scope for LWIG. The LWIG charter constrains the group to work on network and transport layer protocols, and even contains a pretty specific list of protocols that are in scope. An alternative representation for ECs - even if it has benefits for embedded devices - is not what LWIG is chartered to produce. Has the group negotiated going beyond their charter in this way with the responsible AD? Is that documented somewhere? If not, I sincerely hope that LWIG pays more attention to its charter going forward, to avoid running into late process issues that cause upset and require special-case handling. That said, we need to find a way to get this document published without much further delay. This seems to be technically sound work with some clear benefits. Publishing via the CFRG would be an option, but would cause some delay. I wonder if AD-sponsoring it would avoid such delays. I don't want to set a precedent that it's OK for WGs to violate their charter, and hence I wouldn't want us to simply publish this via LWIG. I also want to make it clear that this issue is not something that is due to the authors, or something tat they can resolve. The WG chairs and the IESG need to discuss how we got into this situation and how we can avoid similar issues in the future. The IANA review of this document seems to not have concluded yet; I am holding a DISCUSS for IANA until it has.
Document has Informational status, but uses RFC2119 keywords. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "Master"; alternatives might be "active", "central", "initiator", "leader", "main", "orchestrator", "parent", "primary", "server". * Term "his"; alternatives might be "they", "them", "their". * Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread". ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "Q.3.1. ", paragraph 28, nit: - (r, s) if valid only if the ECDSA signature (r,-s) is, one can - ^ + (r, s) is valid only if the ECDSA signature (r,-s) is, one can + ^ "Q.3.2. ", paragraph 28, nit: - (r, s) if valid only if the ECDSA signature (r,-s) is, one can - ^ + (r, s) is valid only if the ECDSA signature (r,-s) is, one can + ^ "Q.3.3. ", paragraph 28, nit: - (r, s) if valid only if the ECDSA signature (r,-s) is, one can - ^ + (r, s) is valid only if the ECDSA signature (r,-s) is, one can + ^ "I ", paragraph 1, nit: > is due to the authors, or something tat they can resolve. The WG chairs and > ^^^ In British English, the noun "tat" means tasteless or shoddy items. Did you mean "that"? Section 5.1. , paragraph 2, nit: > e if only the Curve25519 curve would have been generated so as to be isomorph > ^^^^^^^^^^^^^^^ Did you mean "had been"? Section 10.2. , paragraph 6, nit: > example, if there is ambiguity as to whether to represent the binary digit 0 > ^^^^^^^^^^^^^ Consider shortening this phrase to just "whether", or rephrase the sentence to avoid "as to". "B.1. ", paragraph 2, nit: > n z of degree zero. If m>1 (i.e., if if q is a strict prime power), then GF(q > ^^ Did you mean "is"? "F.1. ", paragraph 4, nit: > hose with the desired property with lowest possible degree. Appendix G. Furt > ^^^^^^ A determiner may be missing. "K.3.1. ", paragraph 10, nit: > en the two constructions above is that that the first construction uses the m > ^^^^^^^^^ Possible typo: you repeated a word. "O.4. ", paragraph 9, nit: > ticular cryptographic criteria). Despite of its wide-spread use, some details > ^^^^^^^^^^ Did you mean "Despite" (or, alternatively, "in spite of")? Uncited references: [draft-FIPS-186-5], [SP-800-56c], [tEd], [ECC], [draft-NIST-800-186], [SWUmap]
Erik Kline Yes
Alvaro Retana No Objection
I support Lars' DISCUSS.
Murray Kucherawy No Objection
I support Lars's DISCUSS, with the background provided in Magnus's original position.
Robert Wilton No Objection
Zaheduzzaman Sarker No Objection
I also support Lars's discuss.
Andrew Alston No Record
Francesca Palombini No Record
John Scudder No Record
Martin Duke No Record
Paul Wouters No Record
Roman Danyliw No Record
Warren Kumari No Record
Éric Vyncke No Record
(Alissa Cooper; former steering group member) No Objection
I support Magnus' DISCUSS.
(Barry Leiba; former steering group member) No Objection
I second Magnus’s DISCUSS.
(Deborah Brungard; former steering group member) No Objection
Agree with Magnus's Discuss -
(Magnus Westerlund; former steering group member) (was Discuss) No Record
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.