Subject: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Wed, 17 Feb 2021 05:36:13 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-lwig-curve-representations-19: 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/iesg/statement/discuss-criteria.html
for more information about IESG 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:
----------------------------------------------------------------------

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.

---

From: Rene Struik <[email-masked]>
Date: Wed, 17 Feb 2021 10:50:58 -0500

Hi Magnus:

I don't think a brief glimpse at 00 document does this document or my 
efforts on this justice ("my brief review of the 00"). However, let me 
walk you through this draft document. Perhaps, this helps in 
appreciating it better.

{First off, though: this draft has received extensive reviews by Daniel 
Migault, Russ Housley, Stanislav Smyshlyaev. John Mattson (Nov 6, 2020, 
5.06pm EST): "I looked through this draft again. I think it is a very 
good draft and I think it will be a solution to some of the problems IoT 
devices have with Ed25519. I will bring up this draft for discussion in 
the LAKE WG at IETF 109")

Now, the walk-through:

According to the abstract of the lwig curve document, this document 
deals with different representations of the same objects:

    This document specifies how to represent Montgomery curves and
    (twisted) Edwards curves as curves in short-Weierstrass form and
    illustrates how this can be used to carry out elliptic curve
    computations using existing implementations of, e.g., ECDSA and ECDH
    using NIST prime curves. We also provide extensive background
    material that may be useful for implementers of elliptic curve
    cryptography.

It is shown in Section 4 how this can be used to reuse existing 
implementations and existing specifications (thereby assisting the 
community in lowering development and maintenance cost):

    Any existing specification of cryptographic schemes using elliptic curves in Weierstrass form and that allows introduction of a new elliptic curve
    (here: Wei25519) is amenable to similar constructs, thus spawning "offspring" protocols, simply by instantiating these using the new curve in short-Weierstrass
    form, thereby allowing code and/or specifications reuse and, for implementations that so desire, carrying out curve computations "under the hood" on Montgomery
    curve and twisted Edwards curve cousins hereof (where these exist).  This
    would simply require definition of a new object identifier for any such envisioned "offspring" protocol.  This could significantly
    simplify standardization of schemes and help keeping at bay thresource and maintenance cost of implementations supporting algorithm
    agility [RFC7696  <https://datatracker.ietf.org/doc/html/rfc7696>].

Section 4 illustrates how to
a) {Section 4.1} reuse an *existing* NIST SP 800-56a-compliant 
implementation of co-factor ECDH (which requires a specific, so-called 
short-Weierstrass, representation of curve points to be compliant. It 
does not define anything new. In fact, the entire point of ECDH25519 is 
to be strictly compliant with *existing* NIST specifications, including 
all representations of bit/byte-strings and all necessary security 
checks (e.g., public key validation), so that one can amortize 
development cost and, perhaps, gets this FIPS-ed. See Note 2.

b) {Section 4.2} reuse an *existing* Montgomery ladder to implement 
EdDSA (RFC 8032), where the "gap" between Curve25519 and Ed25519 is 
bridged by a simple representation change. This is a public 
transformation. See also the first sentence of Section 8, which writes:

     The different representations of elliptic curve points discussed in 
this document are all obtained using a publicly known transformation, 
which is either an isomorphism or a low-degree isogeny.

c) {Section 4.3} reuse an *existing* implementation of FIPS 186-4 
compliant implementation of ECDSA w/ SHA256 and P-256 and simple swap 
the domain parameters of Wei25519 for P-256. This reuses all existing 
representations (bit/byte-ordering), and all necessary security checks 
that have been specified for 1 1/2 decades.

d) {Section 4.4} reuse any other existing implementation, where this is 
simply illustrated for Curve448 (the other CFRG curve besides Curve25519).

Section 7 provides evidence that this indeed works, where the reference 
to the NXP chip (but Infineon chips [not mentioned] can do the same) is 
of particular interest, since a chipset out in the field that implements 
generic HW-assisted curve arithmetic with all the "nice on the box logo 
capabilities" that one knows of devices that can do ECDH, ECDSA as NIST 
specified 1 1/2 decades ago.

The main contribution of this document is to illustrate how simple this 
is and how much overdue appreciation of this is.

The only technicality is that some existing chipsets may have hardbaked 
curve parameters (a=-3) in there, which requires a little bit more 
computations: in this case one needs a so-called isogeny, rather than a 
trivial x-coordinate shift (as the representation switch above does). 
This makes the representation material more complete, but by necessity 
requires more explanation. The corresponding mappings and 
representations, and examples are printed in the internet draft, but 
these are by *no* means standardized: I wanted to keep this simple and 
trivial to implement with existing libraries. (So, no Wei25519.-3, but 
only Wei25519, etc.)

Why so many appendices?
The answer is simple: this is to serve the community, since it fills the 
current void that there is no other ietf document that specifies these 
things and confusion/myth-forming can be avoided by simply being able to 
reuse this.

How does this draft fit with lwig's scope, as articulated in the charter?
The purpose of the LWIG working group is to collect experiences 
fromimplementors of IP stacks in constrained devices. Thegroup shall 
focus only on techniques that have been used in actualimplementations 
and do not impact interoperability with other devices.
RS>> More elaborated upon below.

This document will be helpful for the implementors of new devices or for 
theimplementors of new general-purpose small IP stacks.
RS>> See RFC 8928 - Address-Protected Neighbor Discovery for Low-Power 
and Lossy Networks and next item

It is also expectedthat the document increases our knowledge of what 
existing smallimplementations do, and helps in the further optimization 
of theexisting implementations.
RS>> This allows implementors to minimize implementation cost, e.g., by 
having ECDSA w/ SHA256 and {NIST curve P-256 or curve Wei25519} under 
the hood (reuse everything, except other modular arithmetic constants).

On areas where the considerations for smallimplementations have already 
been documented the group shall make aneffort to refer to those 
documents instead of developing its own.
RS>> See Implementation Considerations and Implementation Status section.

Generic hardware design advice and software implementation techniquesare 
outside the scope of this work, as such expertise is not within theIETF 
domain. Protocol implementation experience, however, is within the
IETF domain.
RS>> The material on alternative elliptic curve representations, though 
extremely simple, now has a place and can be simply used by implementors 
and developers.

The group shall also not develop any new protocols orprotocol behavior 
modifications beyond what is already allowed byexisting RFCs, because it 
is important to ensure that different types ofdevices can work together.
RS>> the entire point of the document is how to reuse existing 
specifications and implementations. Everything is used modularly, where 
algorithms are used as have been specified 1 1/2 decades ago and are 
used widely.

The group shall not develop assumptions orprofiles about the operating 
environment of the devices, because, ingeneral, it is not possible to 
guarantee any special configuration.
RS>> n/a.

Finally, while implementation techniques relating to security 
mechanismsare within scope, mere removal of security functionality from 
a protocolis not an acceptable recommendation.
RS>> This draft avoids all shortcuts, since examples are strictly 
compliant with existing NIST and FIPS specifications, without taking out 
seemingly unnecessary security checks.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Feb 2021 17:30:14 +0000

Hi Rene,

I think you are not correctly understanding my discuss. This is a discuss on the
failures in following IETF process that has occurred for this document. 

From my perspective there is no question that the current draft put in front of
IESG is not within the chartered scope for the LWIG WG. It attempts to register
a new, not before existing COSE algorithms. That is clearly specification work,
something LWIG is not chartered to do. 

It is good that you gotten some feedback on the draft. However, I am convinced
more feedback would have been provided had this work been done in a more
appropriate venue. I would also note that the email from John Mattsson that you
quote below also do indicate issues with coordination with COSE WG for example. 
https://mailarchive.ietf.org/arch/msg/lwip/PHKTq30QucdjdtAfqsYqqbVep4A/

To be clear, I have no interest in killing your document, simply ensure that
IETF process is followed correctly to enable that your document can eventually
published. 

From my perspective, what is most important to you and the WG proponents, define
the new algorithms or describe how you implement existing algorithms with this
transform methodlogy? If it is the first then I think moving this document to
another WG where defining new algorithms are in scope. If it is the later, then
you and the WG have to strip down the document to not define new algorithms,
only how they can be implemented. 

On Wed, 2021-02-17 at 10:50 -0500, Rene Struik wrote:
> Hi Magnus:
> 
> I don't think a brief glimpse at 00 document does this document or my efforts
> on this justice ("my       brief review of the 00"). However, let me walk you
> through this draft document. Perhaps, this helps in appreciating it better.

Let me attempt to clarify what my I see as my role as AD are in the document
approval process are. I review documents to find where my expertise and
experience of IETF may find significant issues that has gone unnoticed so far. 

This particular week we have 11 documents (407 pages in total) and two charters
to review. I at least don't read the documents in detail. I skim a lot to find
those documents and parts of documents where I need to understand. Simply so
that I can determine if there are any issue. For your document I am not a
subject matter expert. To me it was sufficent to briefly look at the document to
understand on a high level what the document does. That high level understanding
was sufficient to see that there was an process issue here due to the scope of
the document and the scope the WG's charter defines. 

I have after that initial realization tried to understand a bit how we ended up
with this situation. As I said this scope issues should have been detected and
handled much earlier. That is why I briefly looked at -00 and -04, where the
later is the point where this document definitely had crossed the line for
LWIG's charter scope. The fact that the document contained IANA considerations
for crypto algorithms was all I needed to make that determination. It is an
organizational failure in my view that this scope issue was not address already
in 2019. 

So can we please focus on what is important to resolve the situation, i.e. which
path should be taken here. 

Cheers

Magnus Westerlund

---

From: Rene Struik <[email-masked]>
Date: Wed, 17 Feb 2021 13:57:29 -0500

Hi Magnus:

According to Section 16.11 of RFC 8152 [1], registration of IANA code 
points does not require a specification that is actually an IETF draft 
or RFC document (I could have posted the specification on my own website 
for that matter). {Obviously, unambiguous specifications have to be 
there, see the very first draft of Nov 13, 2017, almost 3 1/2 years ago 
[2].} The same Section 16.11 also does not seem to require a iana cose 
section.

I am sure you have much more process experience than I do. However, I 
have trouble understanding how having a IANA section makes this suddenly 
a process violation. Do I understand correctly that, in your mind, this 
process issue would be moot if I would simply partition the doc into two 
parts A and B, where C:=A+B is the current document and where A=C\B and 
B:={Section 12.2, Section 12.3}?

Just for your info: I do hold the editorial organizational principle 
dear, where I think I serve the community at large best by having a 
coherent treatment of all relevant material in one carefully edited 
document (rather than sprinkled around).

In case the A+B partitioning is your preference, how does this help an 
implementer, who may be more interested in finding what he/she needs 
than in procedural matters somewhere along the way? Where would they 
find part B, in case they are interested in this?

I simply would like to understand, since I do not right now.

Best regards, Rene

[1] [excerpt of Section 16.11 of RFC 8152 - Expert Review Instructions]
Specifications are required for the standards track range of point assignment.  Specifications should exist for specification required ranges, but early assignment before
a specification is available is considered to be permissible.  Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed
environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.

[2] 
https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00#section-3

[excerpt of your email]

I have after that initial realization tried to understand a bit how we ended up with this situation. As I said this scope issues should have been detected and handled much earlier. That is why I briefly looked at -00 and -04, where the later is the point where this document definitely had crossed the line for LWIG's charter scope. The fact that the document contained IANA considerations for crypto algorithms was all I needed to make that determination. It is an organizational failure in my view that this scope issue was not address already in 2019.

Ref: [1] https://tools.ietf.org/html/rfc8152#section-16.11

---

From: Rene Struik <[email-masked]>
Date: Wed, 17 Feb 2021 14:14:39 -0500

Just to be clear: everything has been described in much detail in Section 4 of the lwig curve doc. There is no new algorithm: ECDSA has been specified in FIPS 186-4, ANSI X9F, SECG, BSI docs for 1 1/2 decades; same thing for co-factor ECDH. Perhaps, the confusion comes from the fact that each such algorithm actually can only be instantiated once one agrees on bit/byte ordering or such? As an example, FIPS 186-4 specified ECDSA, which has inputs {an elliptic curve in short-Weierstrass format, a suitable hash function, and representation of signature components r and s}. This does not make any instantiation another algorithm, similar as any interface with input parms does not specify another protocol (at least, in my reading). Same thing for elliptic curve points: if one represents an affine curve point (x,y) in compressed form (e.g., (x,y) ---> (x, y (mod 2))), this does not create another point, just a more bit-efficient way of sending this over or storing this in time. The same holds for representations that do have the benefit of economizing on development effort, by reusing specs, code, hw, or all of this.

In short: there are no new algorithms.

I hope this helps.

==
 From my perspective, what is most important to you and the WG proponents, define the new algorithms or describe how you implement existing algorithms with this
transform methodlogy? If it is the first then I think moving this document to another WG where defining new algorithms are in scope. If it is the later, then
you and the WG have to strip down the document to not define new algorithms, only how they can be implemented.

On 2021-02-17 1:57 p.m., Rene Struik wrote:
> or RFC document (I could have posted the specification on my own 
> website for that matter). {Obviously, unambiguous specifications have 
> to be there, see the very first draft of Nov 13, 2017, almost 3 1/2 
> years ago [2].} The same Section 16.11 also does not seem to require a 
> iana cose section.
>
> have trouble understanding how having a IANA section makes this 
> suddenly a process violation. Do I understand correctly that, in your 
> mind, this process issue would be moot if I would simply partition the 
> doc into two parts A and B, where C:=A+B is the current document and 
> where A=C\B and B:={Section 12.2, Section 12.3}?
>
> email:[email-masked]  | Skype: rstruik

---

From: Erik Kline <[email-masked]>
Date: Wed, 17 Feb 2021 16:10:25 -0800

I think Magnus's DISCUSS points all make sense, and the process
failures are mine.  I understand the point that a document this
crypto-heavy might have a better venue.

I think tomorrow I'd like to get an understanding of the decision tree
for what to do here.

    - My reading of things is that the decision with the greatest
impact is probably figuring out a proper home.

    - As for the intended document track, this seems to be largely a
function of whether there are IANA requests and what specifically is
requested (vis. Info vs PS), ergo this seems deferrable until other
decisions have been made.

I'd be interested to hear where specifically folks agree this document
should go, or perhaps whether it should go to secdispatch first to
have this question addressed by folks there.

If the consensus is that some version of this document is fine within
lwig, then changes like extracting the IANA-impacting sections to
another document in another venue all seem reasonable to me.

Thanks,
-Erik

---

From: Rene Struik <[email-masked]>
Date: Wed, 17 Feb 2021 20:27:41 -0500

Dear colleagues:

I uploaded v20 of this document. It is my sincere hope that this will 
help in making swift progress.

Changes (compared to previous version v19):
- removed the cose iana requests subsections, so as to avoid further 
pollution of discussion of this document (which is long overdue to get out).

[Excerpt email RS of Feb 16, 2021, 11.50am EST; see 
https://mailarchive.ietf.org/arch/msg/lwip/9SH1J3OZoiwMZ8jx49OhOlZOtAg/ ]

The iana cose "bickering" is about the value of 6 one-word character strings, in an otherwise quite voluminous, since 137 pages, document, where the value could be "new" or "reuse existing" (i.e., at most six bits of entropy). The current iana cose request may not be perfect. If it requires improvement, I can write some text to accommodate this *in parallel* to the IESG review.

---

From: Daniel Migault <[email-masked]>
Date: Thu, 18 Feb 2021 01:33:11 +0000

I personally do not see at that stage a clear advantage of adding another round to secdispatch and - again speaking only for myself - I would prefer at that point to see the document being moved forward in lwig with the status that enables all IANA registration.

Yours,
Daniel

________________________________
From: Lwip <[email-masked]> on behalf of Erik Kline <[email-masked]>
Sent: Wednesday, February 17, 2021 7:10 PM
To: Rene Struik <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; [email-masked] <[email-masked]>; Mohit Sethi M <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

Thanks,
-Erik

_______________________________________________
Lwip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lwip

---

From: Rene Struik <[email-masked]>
Date: Wed, 17 Feb 2021 20:40:12 -0500

Thanks Daniel!

On 2021-02-17 8:33 p.m., Daniel Migault wrote:

> I personally do not see at that stage a clear advantage of adding 
> another round to secdispatch and - again speaking only for myself - I 
> would prefer at that point to see the document being moved forward in 
> lwig with the status that enables all IANA registration.
>
> Yours,
> Daniel
>
> ------------------------------------------------------------------------
> *From:* Lwip <[email-masked]> on behalf of Erik Kline 
> <[email-masked]>
> *Sent:* Wednesday, February 17, 2021 7:10 PM
> *To:* Rene Struik <[email-masked]>
> *Cc:* Magnus Westerlund <[email-masked]>; 
> [email-masked] <[email-masked]>; Mohit Sethi M 
> <[email-masked]>; [email-masked] <[email-masked]>; 
> [email-masked] <[email-masked]>; 
> [email-masked] 
> <[email-masked]>
> *Subject:* Re: [Lwip] Magnus Westerlund's Discuss on 
> draft-ietf-lwig-curve-representations-19: (with DISCUSS)
> <https://www.ietf.org/mailman/listinfo/lwip>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Feb 2021 18:12:32 -0800

Hi Rene,

> pollution of discussion of this document (which is long overdue to get out).

Is there WG consensus for this action?

Note that once the draft was adopted by the WG, change control passed to
the WG/the IETF, and your role becomes that of an editor, tasked with
realizing the consensus positions (even when they disagree with your own).
While you retain significant editorial latitude in editorial matters, I
would have expected that matters such as whether or not to request
allocation of IANA codepoints would be a consensus decision.

> The iana cose "bickering" is about the value of 6 one-word character strings, in an otherwise quite voluminous, since 137 pages, document, where the value could be "new" or "reuse existing" (i.e.,…

For the record, I dispute this characterization on several counts.

You say "bickering" where I see legitimate technical concerns that remain
unanswered.  (Yes, there was a statement made by one individual about
previous IANA review of the COSE registrations and that statement turned
out to be inaccurate.  I note that the statement in question was prefaced
with "to my undersanding" and the author of the statement was quick to
acknowledge the correction.)

I believe that the technical issues raised involve more than just the
character strings (that also correspond to integer values for the CBOR
encoding).  In addition to the topic of what class of semantics those
values are to convey, there was also a question raised relating to ECDSA on
Wei25519 and the need to truncate the hash function output to a number of
bits not divisible by 8.  In what review of the document I have done so far
I do note a fastidious (possibly excessively so) attention to bit-order of
encoding, but it is not clear to me that proper prominence has been given to
the need to pay attention to this concern as it relates to ECDSA over a
curve that requires truncation to a non-multiple of 8 bits, and whether the
behavior of the existing COSE ECDSA codepoints (which indicate specific
hash functions) has been fully specified in terms of the bits to select for
signature input.  I do not recall seeing technical discussion to indicate
that this issue has been closed (but I am only human, and would welcome a
pointer to where such discussion has occurred).

You say that you could write some text in parallel to the IESG review, but
this document is intended to be published on the IETF stream, and per RFC
8789 all documents on the IETF stream require IETF consensus.  I think it
is clear from the ongoing discussions on the COSE WG list that further
effort is needed to determine the consensus position on these proposed IANA
registrations, and thus that it is premature for the IESG to evaluate text
that is in flux and has undetermined consensus status.

Thank you,

Ben

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Feb 2021 18:29:14 -0800

On Wed, Feb 17, 2021 at 10:57 AM Rene Struik <[email-masked]> wrote:

> I am sure you have much more process experience than I do. However, I have
> trouble understanding how having a IANA section makes this suddenly a
> process violation. Do I understand correctly that, in your mind, this
> [...]

Hopefully this helps rather than muddies things further, and Magnus (and
Erik, and Ben, etc.) can correct me if I'm wrong:

The first issue: The Last Call announcement for this document indicated
that the working group wants it to have Informational status when
published.  After that Last Call was completed, our procedures assert that
the document, with any Last Call feedback worked into it, has IETF
consensus to be published with that specific status.  Changing the status
being sought to Standards Track without also running a new Last Call saying
so violates our procedures; the document can't go forward unless that
status change is reverted, or a second Last Call is done indicating the new
intended status.  This point has nothing at all to do with the content of
the document, but rather the path it has followed through the process so
far.

The second issue: The LWIG working group does not appear (on a cursory
read) to be chartered to produce a document that does this sort of work
with cryptographic algorithms.  Since a working group's charter is in
effect a contract between the working group and the IESG to describe
exactly the work it will produce, the delta between what this document is
doing and what LWIG's charter says is large enough that this is something
worthy of discussion and resolution before the document should advance.  If
the charter is wrong, let's renegotiate it; if this work needs to be done
in a different venue, let's make that arrangement; etc.

I believe Magnus is right to put the brakes on until these issues are
sorted out.

-MSK

---

From: Erik Kline <[email-masked]>
Date: Wed, 17 Feb 2021 20:51:59 -0800

On Wed, Feb 17, 2021 at 6:29 PM Murray S. Kucherawy <[email-masked]> wrote:
>> I am sure you have much more process experience than I do. However, I have trouble understanding how having a IANA section makes this suddenly a process violation. Do I understand correctly that, in your mind, this process issue would be moot if I would simply partition the doc into two parts A and B, where C:=A+B is the current document and where A=C\B and B:={Section 12.2, Section 12.3}?
>>
>> [...]
>>
> Hopefully this helps rather than muddies things further, and Magnus (and Erik, and Ben, etc.) can correct me if I'm wrong:
>
> The first issue: The Last Call announcement for this document indicated that the working group wants it to have Informational status when published.  After that Last Call was completed, our procedures assert that the document, with any Last Call feedback worked into it, has IETF consensus to be published with that specific status.  Changing the status being sought to Standards Track without also running a new Last Call saying so violates our procedures; the document can't go forward unless that status change is reverted, or a second Last Call is done indicating the new intended status.  This point has nothing at all to do with the content of the document, but rather the path it has followed through the process so far.

Agreed, and failure to notice this was my fault.

> The second issue: The LWIG working group does not appear (on a cursory read) to be chartered to produce a document that does this sort of work with cryptographic algorithms.  Since a working group's charter is in effect a contract between the working group and the IESG to describe exactly the work it will produce, the delta between what this document is doing and what LWIG's charter says is large enough that this is something worthy of discussion and resolution before the document should advance.  If the charter is wrong, let's renegotiate it; if this work needs to be done in a different venue, let's make that arrangement; etc.
>
> I believe Magnus is right to put the brakes on until these issues are sorted out.
>
> -MSK

I had a sync with Suresh to get more historical context.  I understand
and agree that lwig is chartered primarily for Information document
work (and not specification).  I had thought that this registration
might be a minor side-effect of documenting the Weierstrass curve
elements, "and oh by the way here's a code point if you want to use it
explicitly", but this was harmful naivety on my part.

I'd still like to understand the best way forward in service of the
work.  Split the doc in two and do the registrations somewhere else
(where?), or bring the document to another venue (also: where?).

It has been pointed out to me that the formally correct way to deal
with this question at this point, given all the feedback to date, is
probably to withdraw the document from this telechat ("it is premature
for the IESG to evaluate text that is in flux") and to add a
management item for tomorrow's telechat to discuss the path forward.
This is what I will now do.

Thanks to all,
-Erik

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 18 Feb 2021 14:16:31 +0000

Hi Murray, IESG,

Sorry for the somewhat long email but I thought it is worth elaborating on the history of this document a little. I guess many of us struggled with the question if LWIG is the right venue before this document was adopted. Suresh (AD at the time of adoption), Ben Kaduk, and I (co-chair) did note that this draft is crypto-dense. Ben in 2019 asked:

Hi all,

I happened to see the IoTdir review of
draft-ietf-lwig-curve-representations go by, and was kind of struck by how
math/crypto-dense it was (and how long it was).  It's really the sort of
thing I expect to see come out of CFRG, and doesn't strike me as really
LWIG's core competency.

Could you say a bit more about why it's being pursued in LWIG?

Thanks,

Ben

and Suresh responded:

Yes. It has been very concerning to me and and I did raise my concern several times with the IESG including the last time at the IESG wrap up meeting for Prague on March 29. I was also concerned about the crypto heavy nature and proceeded based on the Stanislav Smyshlyaev review from the Crypto Review panel. I had also specifically asked for a SecDir review before I send this off to IETF LC but the Sec Dir review due on 10/04 has not arrived yet. I will let Mohit and Zhen make the call, but if you think the cfrg would be a good venue for this I would personally be happy to approve the move.

Thanks
Suresh

I think some of our concerns were assuaged because this draft was sent to the IETF Crypto Review Panel (https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel) through Alexey Melnikov. Stanislav Smyshlyaev reviewed the document and the formulae. I believe comments from the Crypto Review Panel were addressed by Rene.

Ben later responded:

Hi Mohit,

I didn't know that Stanislav had done a crypto review (or rather, I forgot,
since I think I am on that mailing list as a courtesy); he does good work,
and that alleviates most of my concerns.

My gut feeling remains that CFRG is "more appropriate" in some abstract
sense, but it's not clear that the benefit of moving the document is worth
any gains that might be had.  Hopefully one of us can remember to forward
the IETF LC note to the CFRG when that happens, which should be enough
awareness there.

Thanks for the extra background,

Ben

LWIG has done lots of security related RFCs and drafts:

RFC 7815: Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation: https://datatracker.ietf.org/doc/rfc7815/
RFC 8387: Practical Considerations and Implementation Experiences in Securing Smart Object Networks: https://datatracker.ietf.org/doc/rfc8387/
draft-ietf-lwig-minimal-esp: Minimal ESP: https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/

When Rene's draft was adopted, there were no IANA registrations (https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-00#section-5). As it happens sometimes, the scope of the work expanded after working group adoption and perhaps everyone involved could have been more diligent. I understand the IESG concerns about LWIG charter not covering this work item precisely. But as an individual contributor: I think we are at a point of diminishing returns and pursuing this document elsewhere is perhaps not the best choice. I like Carsten's suggestion of reverting this document to informational and allowing some values to be registered even if they require standards action. Carsten explains the logic rather nicely here: https://mailarchive.ietf.org/arch/msg/cose/g8UaczrsG6zHqR6qDIxRt-JJMtM/

Obviously, you, the IESG members have way more experience than me and I'll follow your recommendations here (both as co-chair and document shepherd).

--Mohit

On 2/18/21 4:29 AM, Murray S. Kucherawy wrote:
On Wed, Feb 17, 2021 at 10:57 AM Rene Struik <[email-masked]<mailto:[email-masked]>> wrote:
I am sure you have much more process experience than I do. However, I have trouble understanding how having a IANA section makes this suddenly a process violation. Do I understand correctly that, in your mind, this process issue would be moot if I would simply partition the doc into two parts A and B, where C:=A+B is the current document and where A=C\B and B:={Section 12.2, Section 12.3}?

[...]

-MSK

_______________________________________________
Lwip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lwip

---

From: Rene Struik <[email-masked]>
Date: Thu, 18 Feb 2021 09:42:00 -0500

> Is there WG consensus for this action?

RS>> I removed that subsection for now, after the litany of emails with 
mixed messaging the last few days (I thought this was what would make 
Magnus "happy" and this was something I thought Erik Kline recommended). 
I don't know how to play these type of "games", since am completely 
bewildered by this.

<<RS
> allocation of IANA codepoints would be a consensus decision

RS>> BTW - I used the word "bickering" with quotation marks and am a 
non-native speaker, but it is the right word for the games being played:

    According to sex and relationship therapist Tammy Nelson, PhD, the
    clear line between*bickering*and*fighting*when it comes to style
    of*arguing*in a relationship is about whether you play dirty. ...
    “The problem is not that you*argue*; the problem is whether or not
    you resolve your*arguments*,” she says.

I have a long record of non-responsiveness by the "iana cose expert" 
(stretching for months, where even nudging people with promised 
home-baked applepie to finally get people to be responsive did not work 
and iana staff also does not seem to keep an eye on timeliness). The 
supposed COSE mailing list "discussions" also did not seem to resolve 
anything and seems to be mostly devoid from looking at actual specs, 
just presumed behavior of specs (as if considered a blackbox). More 
below. <<RS
> encoding,

RS>> In security, careful attention to details matters and, in fact, is 
imperative. I added the data conversion section and bit/byte-orderings 
to compensate for the lack of precision in lots of security-related 
internet drafts, which has become a huge problem for practitioners. For 
some of the issues with ambiguity, see, e.g.,

[a] Signatures, ECC, Taming the Many EdDSAs, ed25519, cofactor 
(Konstantinos Chalkias, Francois Garillot, Valeria Nikolaenko, IACR 
ePrint 2020-1244, SSR 2020)

[b] ECC - Provable Security for Ed25519, Theory and Practice (Jacqueline 
Brendel, Cas Cremers, Dennis Jackson, Mang Zhao, IACR ePrint 2020-823)

In fact, simply have a look at the dozens of Errata posted on 
curve-related documents and one knows enough: "loose specs sink security 
ships".

<<RS

> but it is not clear to me that proper prominence has been given to
RS>> ECDSA is not what ietf dreams it up to be; it is how it is 
specified in FIPS 186-4, BSI, ANSI X9.62, SECG (all at least 1 1/2 
decades old specifications). These specifications are precise and 
unambiguous. Those specifications use bit operations, not byte 
operations and work also when the bit-size of the prime-order subgroup 
of the curve is not a multiple of eight (e.g., when using binary curves 
sect283k1). <<RS
> signature input.

RS>> Specifications that use externally defined algorithms (such as 
ECDSA) should use those as is, not as one dreams those to be. This is 
precisely where attention to detail ("fastidiousness" if you will) 
matters. One should also read one's own specifications, instead of 
simply making speculations about what is in there. <<RS

> I do not recall seeing technical discussion to indicate

RS>> Here is the pointer: 
https://mailarchive.ietf.org/arch/msg/cose/oFTcLg_HviER-B7ciZGjPLR9xms/

<<RS

> effort is needed to determine the consensus position on these proposed IANA

RS>> It would help if people first read the RFC 8152 specification 
before posting things on the mailing list, since the (very few) postings 
I have seen often contravene what is actually in the document.

a) John Matton's email (Feb 16, 2021, 7.17am EST, see 
https://mailarchive.ietf.org/arch/msg/cose/ITvErsVZ4jkzwJVjZ9sCuIT9EwM/)

I just noticed that RFC8152bis has the recommendation:

"Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]."

I don't think this is a good recommendation for IoT devices. In the last 5 years, i.e. after work on RFC 8152 started, there has been a large amount of academic papers showing that purely deterministic ECC algorithms in accesable IoT devices suffers from side-channel and fault injection attacks. For a list of papers see e.g. Seciton 1 ofhttps://tools.ietf.org/html/draft-mattsson-cfrg-det-sigs-with-noise-02

Note RS: this inappropriate policy advice was already in RFC 8152 (and 
is still proliferating within ietf), where one should note RFC 8152 was 
published July 2017 (well after those attacks were known).

b) Ilari Liuusvara's email (Jan 28, 2021, 12.37pm EST: see 
https://mailarchive.ietf.org/arch/msg/cose/4PIPilQY8a985StsFeft0No0-YI/)

Here, things get bit more complicated with Wei25519/Wei448.

These curves have h!=1 (unlike every past elliptic curve in COSE, which
all have h=1), so it makes sense to multiply at the end by h in order
to guard for attacks with small subgroups ("co-factor ECDH").

However, RFC8152 defers to RFC6090 for ECDH, and RFC6090 assumes that
h=1. However, RFC8152 also species the output encoding per curve, so
one could specify special output encoding that multiplies by h before
encoding in order to take h into account. This should give co-factor
ECDH on the new curves without defining any new algorithms.

Note RS: I asked Ilari offline a clarification of his suggestion, since I did not understand how this would work (to which he did not respond). Two days later (Jan 30, 2021, 7.46am EST), Goran Selander and Ben Kaduk seem to embrace this approach ( https://mailarchive.ietf.org/arch/msg/cose/N7fMnbfhDCdE9ETNWaN3oBLQIXA/), where it is absolutely unclear (to me) whether they even checked that the suggestion works. For the record: I think it does not, since it confuses the "garbled up hack" confuses the notion of bijective mapping and mappings that have more than one preimage. Even if the approach would work, it would still have been a hack that is non-NIST/FIPS/BSI/ANSI compliant behavior, since a change to the original co-factor ECDH protocol (NISTSP 800-56a, decade-old; 25+ years old in academic literature).

Both a) and b) are examples that illustrate that the group seems to have an alarming lack of attention to detail and that it is hard to take email responses that evidence lack of doing one's own homework on face value.

This perhaps also explains why it was easy for me to write the cms/pkix iana section and that it is made extremely hard to reuse what is in RFC 8152, since often lacking precision and attention to detail required for security specifications.
<<RS

> that is in flux and has undetermined consensus status.

RS>> It is hard to establish consensus if the "does this make technical 
sense" lackmus test is taken out of the equation and one just count some 
loose email traffic with no conclusion and proof of workability in sight.

<<RS