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: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
