Re: [Lwip] Iotdir early review of draft-ietf-lwig-curve-representations-08

Suresh Krishnan <> Fri, 25 October 2019 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19054120047; Fri, 25 Oct 2019 14:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fpShLtWpDn3u; Fri, 25 Oct 2019 14:06:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA3B7120013; Fri, 25 Oct 2019 14:06:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=LVYsabjXDBJBPdYmKHdJQyEQNu1mUjDkB17LGf1Sa6nu7OVIuIgPBbdHhmYVD0IDId/1po92J9Muxj6U3CV6Dyw16ik3QNSv8ZFViknWgCcvHK7xB+AkHnhzZCwT31GcoRHsrsxKKgps2jJ9eOxqRgqRTw4qWVVVWGebFyOWCGDRjMS34fPsoARypQvUGUJuGsFHUhIgtWDS5OvpdiZslA1ij48rgO9q3Teis2Zff1NcrGP3qqWKkX44SQGFuWolboXZXAw2Kpdk8F8n4h/GXn8hI+OUELGsSi/UaPDOU/Boqc1HeRwA0KedfntHNDBpZLpnoaypBqe71XLpcySRVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gDiCdVCPTMJ7VX5rM4o2rPfseqlO3YXpksmpHWXpQ4I=; b=kQaYQR5DdSoFIqGNx0dAU0kZfFEHVu76v4ne9y/PK/i1GrrYU8F5d9pZB0R9wnIsWlQ5Ih24bN5gMsqy4wo7cJC4qv6wNQ0gv5ZM0eMO0q6q533Uz6Zcf+T0O09tDsI0+ZJwf6K1bjNg1Any/V/YLUIO+gEIyjmNF7WB9WxRIMFD4dpbLq2S5t2D/ilg07sZ2vrZC28DxSBloxOChXZwrT6APYbdu/DWbtNUpfDK9eT0JdHDZQF+S37/E84/JEtCMlsKU4RPT3wZGPQ85mu9QFR5gC9aqsyHuqaYW3NhgnQX1WoaiCS6MmB/mnnShper3MwuFB6cxt9RXOPCEn7KTg==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gDiCdVCPTMJ7VX5rM4o2rPfseqlO3YXpksmpHWXpQ4I=; b=Yph9AY/KFeijc6odGWJiUbtxwUqBlYB2Bcq6D/Q2X7mw0soqoNhEhIUCMGlRNemG4YSNLnKYI2vdb4RBnQnNZOSiEUw8V6YrAZu+4ciw2Fs0NMoTU63RuGnxKz6jZMex3t6CV77EZI14xLhDZSzkw2JAfioGIQAfXo3bP33dvek=
Received: from YT1PR01MB3642.CANPRD01.PROD.OUTLOOK.COM ( by YT1PR01MB3146.CANPRD01.PROD.OUTLOOK.COM ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Fri, 25 Oct 2019 21:06:08 +0000
Received: from YT1PR01MB3642.CANPRD01.PROD.OUTLOOK.COM ([fe80::c00b:23f0:4c61:f412]) by YT1PR01MB3642.CANPRD01.PROD.OUTLOOK.COM ([fe80::c00b:23f0:4c61:f412%6]) with mapi id 15.20.2387.021; Fri, 25 Oct 2019 21:06:08 +0000
From: Suresh Krishnan <>
To: Daniel Migault <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Iotdir early review of draft-ietf-lwig-curve-representations-08
Thread-Index: AQHVi2NbRAC6dEs8Qkqfo4S/fx944Kdr2UQA
Date: Fri, 25 Oct 2019 21:06:08 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d792ed29-f2bb-4936-e0f9-08d7598f283f
x-ms-traffictypediagnostic: YT1PR01MB3146:
x-microsoft-antispam-prvs: <YT1PR01MB31466DF6D9564B0258D0E6F5B4650@YT1PR01MB3146.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02015246A9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(396003)(346002)(39840400004)(189003)(199004)(26005)(186003)(6512007)(66066001)(4326008)(25786009)(316002)(6246003)(2616005)(486006)(446003)(11346002)(476003)(2906002)(80792005)(91956017)(64756008)(66556008)(66446008)(66476007)(66946007)(76116006)(36756003)(229853002)(30864003)(5660300002)(66574012)(14454004)(6916009)(8936002)(6436002)(508600001)(33656002)(86362001)(6506007)(53546011)(102836004)(71190400001)(3846002)(256004)(6116002)(54906003)(8676002)(14444005)(71200400001)(99286004)(305945005)(7736002)(81166006)(76176011)(81156014)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:YT1PR01MB3146; H:YT1PR01MB3642.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: v0eg1jSsZDYTlWm9olYfgOApoi7WZzwosHFkA7FZo12LFvzzQcykBtBWeGZha8NO3qeF8pZG8tyIU8Tu5i/IEZ1SbW3N1GgMhqMLCBq7OGvbKW7hQprOLDaquCY8dHkUFuN3sQIBW6++MDV/+9AHtZvlwfoI+cjq3rV7/Sg1VJi40TMV133XLC9hpshLEgEqu1/9zBy0KsqGXUbFgZ/MEUvjVy5wNs7ESzYTtq6aFz9C5zIVaLdSj3mFL7LchZoBZqae8U7ewO1u6k0kH62U0MU/0HHHkwCXoGc52d5YkpBSxu1bEo9x1rP0ne3ta+V402ZvjiI9NWN/8BWatZ0C9UVnaX1p/A6W+TPuZc0/T0lULtHWt0PXm0ywBxr/QirvHZFkxY8tmCmM1mg5qbRS1g9231O6n79ggTmiUB/03LjGtvDxvfxRFvJR6TPu5QdF
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d792ed29-f2bb-4936-e0f9-08d7598f283f
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 21:06:08.5275 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ipsy0TDEZPBqmzHWwOJTmqOOqKe8U8I1+1Q5ziroihjjETnDoKsr/r7tRNDt3b88Gr5CownFD+jKCWWML7ZWSA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB3146
Archived-At: <>
Subject: Re: [Lwip] Iotdir early review of draft-ietf-lwig-curve-representations-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Oct 2019 21:06:14 -0000

Thank you very much for the review Daniel. Greatly appreciated. I see that Rene has sent a partial response pending the Sec Dir review. I will add you into the loop when that comes in.


> On Oct 25, 2019, at 2:38 PM, Daniel Migault via Datatracker <> 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.  These comments were written primarily for the benefit of the
> internet area directors.  Document editors and WG chairs should treat
> 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 the
> document could be re-organized to  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 moved
> forward.
> Yours,
> Daniel
> Abstract
>   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.
> <mglt>
> Overall I have the impression the document's intent is to define Wei25519 for
> COSE. The current document is very well documented and nicely written on the
> generic methodology used, that is using the Weierstrass models of curves using
> other models that is in our case twisted-Edward/Montgomery curves. My reading
> of the document is that it might benefit by being re-focused on Wei25519 and
> provide the necessary details in the main body - that is not the annex to
> implement: * 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 implementation
> 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 generic
> 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.  Fostering Code Reuse with New Elliptic Curves
>   It is well-known that elliptic curves can be represented using
>   different curve models.
> <mglt>
> nits: It might be preferred to remain factual and simply say "Elliptic curves
> can be represented using different models." </mglt>
>   Recently, IETF standardized elliptic curves
>   that are claimed to have better performance and improved robustness
>   against "real world" attacks than curves represented in the
>   traditional "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 curves
> with Weierstrass model were widely deployed and implemented. </mglt>
>   This document specifies an
>   alternative representation of points of Curve25519, a so-called
>   Montgomery curve, and of points of Edwards25519, a so-called twisted
>   Edwards curve, which are both specified in [RFC7748], as points of a
>   specific so-called "short" Weierstrass curve, called Wei25519.  We
>   also define how to efficiently switch between these different
>   representations.
> <mglt>
> I understand the switch can be performed in two ways, it might help the reader
> to distinguish two scenario one with a being a parameter and one with a being
> 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 detail.
> This would justify the need to add code points for Wei25519. </mglt>
>   Use of Wei25519 allows easy definition of new signature schemes and
>   key agreement schemes already specified for traditional NIST prime
>   curves, thereby allowing easy integration with existing
>   specifications, such as NIST SP 800-56a [SP-800-56a], FIPS Pub 186-4
>   [FIPS-186-4], and ANSI X9.62-2005 [ANSI-X9.62], and fostering code
>   reuse on platforms that already implement some of these schemes using
>   elliptic curve arithmetic for curves in "short" Weierstrass form (see
>   Appendix 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>
> 2.  Specification of Wei25519
>   For the specification of Wei25519 and its relationship to Curve25519
>   and Edwards25519, see Appendix E.
> <mglt>
> If we are defining Wei25519, it seems that at least the definition of Wei25519
> 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 add
> the necessary domain parameters that are needed to instantiate Wei25519. </mglt>
>   For further details and background
>   information on elliptic curves, we refer to the other appendices.
>   The use of Wei25519 allows reuse of existing generic code that
>   implements short-Weierstrass curves, such as the NIST curve P-256, to
>   also implement the CFRG curves Curve25519 and Edwards25519.  We also
>   cater to reusing of existing code where some domain parameters may
>   have been hardcoded, thereby widening the scope of applicability.  To
>   this end, we specify the short-Weierstrass curves Wei25519.2 and
>   Wei25519.-3, with hardcoded domain parameter a=2 and a=-3 (mod p),
>   respectively; see Appendix G.  (Here, p is the characteristic of the
>   field over which these curves are defined.)
> <mglt>
> The text needs here a bit more more explanations. As I understood, we are not
> simply changing the representation but also considering the constraint of the
> NIST curves implementations. My understanding is that NIST curves have hard
> coded a=-3, so we need to work around this with the isogeny. The construction
> is, in my opinion, a bit different from what simple isomorphism. It might also
> be good to have that overview stated in the introduction section.
> Annexes are good, but the necessary information for an implementation may be
> moved up to the main body.
> </mglt>
> 3.  Use of Representation Switches
>   The curve Wei25519.-3 (which has hardcoded domain parameter a=-3 (mod
>   p)) is not isomorphic to the curve Wei25519, but is related in a
>   slightly weaker sense: the curve Wei25519 is isogenous to the curve
>   Wei25519.-3, where the mapping of Appendix G.2 is an isogeny of
>   degree l=47 that maps the specified base point G of Wei25519 to the
>   specified base point G' of Wei25519.-3 and where the so-called dual
>   isogeny (which maps Wei25519.-3 to Wei25519) has the same degree
>   l=47, but does not map G' to G, but to a fixed multiple hereof, where
>   this multiple is l=47.  Consequently, a public-private key pair
>   (k,R:=k*G) for Wei25519 corresponds to the public-private key pair
>   (k, R':= k*G') for Wei25519.-3 (via the l-isogeny), whereas the
>   public-private key pair (k, R':=k*G') corresponds to the public-
>   private key pair (l*k, l*R=l*k*G) of Wei25519 (via the dual isogeny).
>   (Note the extra scalar l=47 here.)
> <mglt>
> This is just a comment that ascii does not help reading 1=47... but there is no
> much we can do. </mglt>
>   Alternative curve representations can, therefore, be used in any
>   cryptographic scheme that involves computations on public-private key
>   pairs, where implementations may carry out computations on the
>   corresponding object for the isomorphic or isogenous curve and
>   convert the results back to the original curve (where, in case this
>   involves an l-isogeny, one has to take into account the factor l).
>   This includes use with elliptic-curve based signature schemes and key
>   agreement and key transport schemes.
> <mglt>I believe we should specify somewhere that changing the representation
> does not ease the ECDLP for a given prime/curve</mglt>
> 4.  Examples
> <mglt>
> I do not believe these are example regarding the focus of the document. Of
> 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, that
> is 4.1 -> 4. 4.2->5... </mglt>
> 8.  Security Considerations
>   Elliptic curves are generally used as objects in a broader
>   cryptographic scheme that may include processing steps that depend on
>   the representation conventions used (such as with, e.g., key
>   derivation following key establishment).  These schemes should
>   (obviously) unambiguously specify fixed representations of each input
>   and output (e.g., representing each elliptic curve point always in
>   short-Weierstrass form and in uncompressed tight MSB/msb format).
> <mglt>
> I think it might be worth mentioning here that while the scheme used in this
> document may be applied for other curves that 25519, not all modules are
> isomorphic to Weierstrass. In addition not all Weierstrass representation can
> be switched to a Montgomery representation. </mglt>
>   To prevent cross-protocol attacks, private keys SHOULD only be used
>   with one cryptographic scheme.  Private keys MUST NOT be reused
>   between Ed25519 (as specified in [RFC8032]) and ECDSA25519 (as
>   specified in Section 4.3).
>   To prevent intra-protocol cross-instantiation attacks, ephemeral
>   private keys MUST NOT be reused between instantiations of ECDSA25519.