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

[Rene Struik <[e-mail]>]

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.

On 2021-02-17 8:36 a.m., Magnus Westerlund via Datatracker wrote:
> 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.
>
>
>
>
>

-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]