Alternative Elliptic Curve Representations
draft-ietf-lwig-curve-representations-21

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Lars Eggert Discuss

Discuss (2021-07-13)
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.
Comment (2021-07-13)
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

Comment (2021-07-13)
No email
send info
I support Lars' DISCUSS.

Murray Kucherawy No Objection

Comment (2021-08-12)
No email
send info
I support Lars's DISCUSS, with the background provided in Magnus's original position.

Robert Wilton No Objection

Zaheduzzaman Sarker No Objection

Comment (2021-07-14)
No email
send info
I also support Lars's discuss.

Benjamin Kaduk No Record

Francesca Palombini No Record

John Scudder No Record

Martin Duke No Record

Martin Vigoureux No Record

Roman Danyliw No Record

Warren Kumari No Record

Éric Vyncke No Record

(Alissa Cooper; former steering group member) No Objection

No Objection (2021-02-17 for -19)
No email
send info
I support Magnus' DISCUSS.

(Barry Leiba; former steering group member) No Objection

No Objection (2021-02-17 for -19)
No email
send info
I second Magnus’s DISCUSS.

(Deborah Brungard; former steering group member) No Objection

No Objection (2021-02-17 for -19)
No email
send info
Agree with Magnus's Discuss -

(Magnus Westerlund; former steering group member) (was Discuss) No Record

No Record (2021-03-09 for -20)
No email
send info
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.