Hi Daniel,

Your review of the document is very much ap=
preciated in order to move this draft forward!

Since you already =
provided the review, please close the review request assignment as complete=
d.

Best regards,

-Samita

=

On Fri, Oc=
t 25, 2019 at 2:38 PM Daniel Migault via Datatracker <noreply@ietf.org> wrote:

Reviewer: Daniel Migault

Review result: Almost Ready

Hi,

I have reviewed this document as part of the IoT directorate's

ongoing effort to review all IETF documents being processed by the

IESG.=C2=A0 These comments were written primarily for the benefit of the

internet area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

The summary of the review is Almost Ready

Overall I believe the document is well written with a lot of useful

information. Though I have not carefully reviewed the annexes, I believe th= e

document could be re-organized to=C2=A0 provide more implementation details= of

Wei25519 and its potentially the implementation of the isogeny between

Wei25519.-3 and Wei25519. Note that the latest point may depend on the

implementation status of NIST curves.

Please find my review, which I hope will help to move the document to be mo= ved

forward.

Yours,

Daniel

Abstract

=C2=A0 =C2=A0This document specifies how to represent Montgomery curves and=

=C2=A0 =C2=A0(twisted) Edwards curves as curves in short-Weierstrass form a= nd

=C2=A0 =C2=A0illustrates how this can be used to carry out elliptic curve=C2=A0 =C2=A0computations using existing implementations of, e.g., ECDSA an= d ECDH

=C2=A0 =C2=A0using NIST prime curves.

<mglt>

Overall I have the impression the document's intent is to define Wei255= 19 for

COSE. The current document is very well documented and nicely written on th= e

generic methodology used, that is using the Weierstrass models of curves us= ing

other models that is in our case twisted-Edward/Montgomery curves. My readi= ng

of the document is that it might benefit by being re-focused on Wei25519 an= d

provide the necessary details in the main body - that is not the annex toimplement: * Wei25519 - the domains parameters * the isogeny between

Wei25519.-3 and Wei25519 - as this is necessary for reusing NIST curve

implementation when a hard coded. That said, this depends on the implementa= tion

status of NIST curves and may be left in the annex.

Specification is sufficient to assign code points which is sufficient with = an

Informational status.

I would even have Wei25519 in the title. In my opinion the title is too gen= eric

and the scope should be narrow down a bit. </mglt>

<mglt>

The document introduces some notations, I believe these notations should be=

specified, and maybe use the same notation as RFC7748, if possible to avoid=

that we have one notation per document. </mglt>

1.=C2=A0 Fostering Code Reuse with New Elliptic Curves

=C2=A0 =C2=A0It is well-known that elliptic curves can be represented using=

=C2=A0 =C2=A0different curve models.

<mglt>

nits: It might be preferred to remain factual and simply say "Elliptic= curves

can be represented using different models." </mglt>

=C2=A0 =C2=A0Recently, IETF standardized elliptic curves

=C2=A0 =C2=A0that are claimed to have better performance and improved robus= tness

=C2=A0 =C2=A0against "real world" attacks than curves represented= in the

=C2=A0 =C2=A0traditional "short" Weierstrass model.

<mglt>

Not being a native english speaker, the sentence above may lead the reader = to

think that Weierstrass representation is one reason for less robustness and=

performance. If that were the case, the reader may wonder why do we want to=

move to that representation.

I believe that before Montgomery or Edwards curves have been introduced cur= ves

with Weierstrass model were widely deployed and implemented. </mglt><= br>

=C2=A0 =C2=A0This document specifies an

=C2=A0 =C2=A0alternative representation of points of Curve25519, a so-calle= d

=C2=A0 =C2=A0Montgomery curve, and of points of Edwards25519, a so-called t= wisted

=C2=A0 =C2=A0Edwards curve, which are both specified in [RFC7748], as point= s of a

=C2=A0 =C2=A0specific so-called "short" Weierstrass curve, called= Wei25519.=C2=A0 We

=C2=A0 =C2=A0also define how to efficiently switch between these different<= br> =C2=A0 =C2=A0representations.

<mglt>

I understand the switch can be performed in two ways, it might help the rea= der

to distinguish two scenario one with a being a parameter and one with a bei= ng

hard coded.

We may also briefly expose why Curve25519 cannot be "proxied" by = Ed-to-Wei

followed by Wei25519. In which case Wei25519 would be an implementation det= ail.

This would justify the need to add code points for Wei25519. </mglt><= br>

=C2=A0 =C2=A0Use of Wei25519 allows easy definition of new signature scheme= s and

=C2=A0 =C2=A0key agreement schemes already specified for traditional NIST p= rime

=C2=A0 =C2=A0curves, thereby allowing easy integration with existing

=C2=A0 =C2=A0specifications, such as NIST SP 800-56a [SP-800-56a], FIPS Pub= 186-4

=C2=A0 =C2=A0[FIPS-186-4], and ANSI X9.62-2005 [ANSI-X9.62], and fostering = code

=C2=A0 =C2=A0reuse on platforms that already implement some of these scheme= s using

=C2=A0 =C2=A0elliptic curve arithmetic for curves in "short" Weie= rstrass form (see

=C2=A0 =C2=A0Appendix C.1).

<mglt>

Not being a cryptographer at all. I am wondering if the definition of "= ;new"

signature scheme is correct. At least it sounds a dangerous slope. I think = the

text wants to say it allows to re-use signature scheme defines for the NIST=

curves using another curves Wei25519, namely ECDSA in our case. </mglt&g= t;

2.=C2=A0 Specification of Wei25519

=C2=A0 =C2=A0For the specification of Wei25519 and its relationship to Curv= e25519

=C2=A0 =C2=A0and Edwards25519, see Appendix E.

<mglt>

If we are defining Wei25519, it seems that at least the definition of Wei25= 519

needs to be part of the main draft. A deep explanation as well as other

information may be left in the annexe. I would thus probably recommend to a= dd

the necessary domain parameters that are needed to instantiate Wei25519. &l= t;/mglt>

=C2=A0 =C2=A0For further details and background

=C2=A0 =C2=A0information on elliptic curves, we refer to the other appendic= es.

=C2=A0 =C2=A0The use of Wei25519 allows reuse of existing generic code that=

=C2=A0 =C2=A0implements short-Weierstrass curves, such as the NIST curve P-= 256, to

=C2=A0 =C2=A0also implement the CFRG curves Curve25519 and Edwards25519.=C2= =A0 We also

=C2=A0 =C2=A0cater to reusing of existing code where some domain parameters= may

=C2=A0 =C2=A0have been hardcoded, thereby widening the scope of applicabili= ty.=C2=A0 To

=C2=A0 =C2=A0this end, we specify the short-Weierstrass curves Wei25519.2 a= nd

=C2=A0 =C2=A0Wei25519.-3, with hardcoded domain parameter a=3D2 and a=3D-3 = (mod p),

=C2=A0 =C2=A0respectively; see Appendix G.=C2=A0 (Here, p is the characteri= stic of the

=C2=A0 =C2=A0field over which these curves are defined.)

<mglt>

The text needs here a bit more more explanations. As I understood, we are n= ot

simply changing the representation but also considering the constraint of t= he

NIST curves implementations. My understanding is that NIST curves have hard=

coded a=3D-3, so we need to work around this with the isogeny. The construc= tion

is, in my opinion, a bit different from what simple isomorphism. It might a= lso

be good to have that overview stated in the introduction section.

Annexes are good, but the necessary information for an implementation may b= e

moved up to the main body.

</mglt>

3.=C2=A0 Use of Representation Switches

=C2=A0 =C2=A0The curve Wei25519.-3 (which has hardcoded domain parameter a= =3D-3 (mod

=C2=A0 =C2=A0p)) is not isomorphic to the curve Wei25519, but is related in= a

=C2=A0 =C2=A0slightly weaker sense: the curve Wei25519 is isogenous to the = curve

=C2=A0 =C2=A0Wei25519.-3, where the mapping of Appendix G.2 is an isogeny o= f

=C2=A0 =C2=A0degree l=3D47 that maps the specified base point G of Wei25519= to the

=C2=A0 =C2=A0specified base point G' of Wei25519.-3 and where the so-ca= lled dual

=C2=A0 =C2=A0isogeny (which maps Wei25519.-3 to Wei25519) has the same degr= ee

=C2=A0 =C2=A0l=3D47, but does not map G' to G, but to a fixed multiple = hereof, where

=C2=A0 =C2=A0this multiple is l=3D47.=C2=A0 Consequently, a public-private = key pair

=C2=A0 =C2=A0(k,R:=3Dk*G) for Wei25519 corresponds to the public-private ke= y pair

=C2=A0 =C2=A0(k, R':=3D k*G') for Wei25519.-3 (via the l-isogeny), = whereas the

=C2=A0 =C2=A0public-private key pair (k, R':=3Dk*G') corresponds to= the public-

=C2=A0 =C2=A0private key pair (l*k, l*R=3Dl*k*G) of Wei25519 (via the dual = isogeny).

=C2=A0 =C2=A0(Note the extra scalar l=3D47 here.)

<mglt>

This is just a comment that ascii does not help reading 1=3D47... but there= is no

much we can do. </mglt>

=C2=A0 =C2=A0Alternative curve representations can, therefore, be used in a= ny

=C2=A0 =C2=A0cryptographic scheme that involves computations on public-priv= ate key

=C2=A0 =C2=A0pairs, where implementations may carry out computations on the=

=C2=A0 =C2=A0corresponding object for the isomorphic or isogenous curve and=

=C2=A0 =C2=A0convert the results back to the original curve (where, in case= this

=C2=A0 =C2=A0involves an l-isogeny, one has to take into account the factor= l).

=C2=A0 =C2=A0This includes use with elliptic-curve based signature schemes = and key

=C2=A0 =C2=A0agreement and key transport schemes.

<mglt>I believe we should specify somewhere that changing the represe= ntation

does not ease the ECDLP for a given prime/curve</mglt>

4.=C2=A0 Examples

<mglt>

I do not believe these are example regarding the focus of the document. Of<= br> course, the document could be more generic, but here we focus on 25519, so = I

would rename Example as Implementation. Or move subsection to one level, th= at

is 4.1 -> 4. 4.2->5... </mglt>

8.=C2=A0 Security Considerations

=C2=A0 =C2=A0Elliptic curves are generally used as objects in a broader

=C2=A0 =C2=A0cryptographic scheme that may include processing steps that de= pend on

=C2=A0 =C2=A0the representation conventions used (such as with, e.g., key=C2=A0 =C2=A0derivation following key establishment).=C2=A0 These schemes s= hould

=C2=A0 =C2=A0(obviously) unambiguously specify fixed representations of eac= h input

=C2=A0 =C2=A0and output (e.g., representing each elliptic curve point alway= s in

=C2=A0 =C2=A0short-Weierstrass form and in uncompressed tight MSB/msb forma= t).

<mglt>

I think it might be worth mentioning here that while the scheme used in thi= s

document may be applied for other curves that 25519, not all modules are

isomorphic to Weierstrass. In addition not all Weierstrass representation c= an

be switched to a Montgomery representation. </mglt>

=C2=A0 =C2=A0To prevent cross-protocol attacks, private keys SHOULD only be= used

=C2=A0 =C2=A0with one cryptographic scheme.=C2=A0 Private keys MUST NOT be = reused

=C2=A0 =C2=A0between Ed25519 (as specified in [RFC8032]) and ECDSA25519 (as=

=C2=A0 =C2=A0specified in Section 4.3).

=C2=A0 =C2=A0To prevent intra-protocol cross-instantiation attacks, ephemer= al

=C2=A0 =C2=A0private keys MUST NOT be reused between instantiations of ECDS= A25519.

_______________________________________________

IoT-DIR mailing list

IoT-DIR@ietf.org<= br> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_iot-2Ddir&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRx= pb6__0PomBTQ&r=3DpWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=3DR9= xgGynpGpZuri6EHdEishW9HbS2jbstDEFk6i38v8w&s=3DH5LPk8KFQpEY0jiHVeVBFFvDX= AG_39OKXhO_tyizQUg&e=3D