From nobody Tue Aug 11 06:38:12 2020 Return-Path: X-Original-To: lwip@ietfa.amsl.com Delivered-To: lwip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB81A3A1082; Tue, 11 Aug 2020 06:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZHqRWuGsrVa; Tue, 11 Aug 2020 06:38:06 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2056.outbound.protection.outlook.com [40.107.93.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673C33A107F; Tue, 11 Aug 2020 06:38:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pof/loZqj9KBOmftcx7tq1VLFjeJFszvaqyk/Hjs8P4tmbax0gEZ1zZ31vD7BRJexXB/lcRfdlGjeRiEqkWH2/wVPaDkTGjYH8k3aZortjMeLPoLFFrF3fbwRSvrfPAuG78GnglOZ+j3VckV6Z7vDA/xLpjdz8fYSQke5SuYiW/JjtNMBFz8StnTBpatLlwpRUpH5RMJ5JHhxkw7UhKh7f6x1593bkQB2NPjnIH0ihH/qJekXkGWeSgVMKslbAcIN6QwyTAWC0Tjt4fZcmphAXW7kI/SWWUp4cOeWM7R79eNKNOVr9ofiVJfszRJVH6a0uAxLlhZGpWztkkqaPZd8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J0doEI1AP6COOrNPDB0+bxPf9tBsn3KHFj5Dp8L/KVk=; b=hR72/bb5h95Dv2THKtFn+ykPSv8hKvDJAeUA7qFKOcQcOSbuINKhmzalTsWxiuGnAG+9rbomGkVDknBEPphq9i58I5vRx5fTzo99jFXGCX2Z+3sVdmSs0L+pG+QEfDckJCOV1XUZe1F14gKcl69MImLZfO6DvdqPAI5EuEAVkkznaMaNlTCdK9ff4nho6luNTZQCYy0lt/+3UjY6NH6+JcnDj3tUMrd2UB3FoSO1Hgb3LoRB9GtOInYoBfJIqp0CvSqGXZaQtSFQOQAKoo2YYYsY++ZHkYwpq3nJSmt9HQC62ucVPwX4MthQfsc0ob9cOBU4okjGN1oyS5ho9GUfkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J0doEI1AP6COOrNPDB0+bxPf9tBsn3KHFj5Dp8L/KVk=; b=eA0k94oAWCqHFG/6PJN9RIgkD/pLVYkXYPeaQFC2XScoHgH+TceO6hRPbmIrjR0ex5GwbSPAFEgL9wBPHChYUXIbqePM3XlXbnyy3WTJgSan/YBdpAV52b2/2Y5Mdjhsm+07NoNkG43LzcAHFguOf73WN+eelO+mgGr54aLTnxM= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SN6PR15MB2511.namprd15.prod.outlook.com (2603:10b6:805:24::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.22; Tue, 11 Aug 2020 13:38:03 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1%4]) with mapi id 15.20.3261.025; Tue, 11 Aug 2020 13:38:03 +0000 From: Daniel Migault To: Rene Struik , Daniel Migault CC: "Iot-dir@ietf.org" , "lwip@ietf.org" , "draft-ietf-lwig-curve-representations.all@ietf.org" Thread-Topic: [Lwip] Iotdir early review of draft-ietf-lwig-curve-representations-08 Thread-Index: AQHVi3J7Lmzro2cHwE6y+8IEsxw+T6hC010AgMYiWgCACStunoAhDvYAgABNuYCAATNu/A== Date: Tue, 11 Aug 2020 13:38:03 +0000 Message-ID: References: <157202868751.4563.7383848744505767056@ietfa.amsl.com> <1d89b784-ea57-5c70-2d36-e7eb41134295@gmail.com> <4f2a6e12-6fb4-4ed2-122d-5916c4094ddb@gmail.com> , <9b287678-58a7-85a7-e5de-1f612a308b46@gmail.com> In-Reply-To: <9b287678-58a7-85a7-e5de-1f612a308b46@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 754edee7-1a69-4901-8ef2-08d83dfbc5a5 x-ms-traffictypediagnostic: SN6PR15MB2511: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SWC52ZEvIJE+YpM3MNJ5TYZAAt8ZNRn4MnT+rCxmglSq2UKqG9QtflQ4W/4pENWWUvbXXA2kClibkP5kPdtakjjY3MBWkUpVZI+Zn0okt3+L4hcct8T98iX56lp+bTxGmDPMVUgU2EM8bNfhI/rMCM54QRCfpdXC0fsQXPEqNOnNP3XvEx+I2vR2YKNzQWrV60aHMkD0I3mQCizaz4MC/BgQekdZng8hSCpGK3A3rvfQxlw5m897FKBzK3fw/3FQt/ZQ/12Cyj9PMWQKTWebHvNA2lMgNjYJIhckp2B5BjvggYrsq3ns2gSq/JDTdWJv3Pwzr61kwIqJrPoUNp93+UU/gTdXN4NG9rX0wC1vfszyRis+i/913IuxyoOM7iH52nshPPE9bAadT/71dj0JJA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(376002)(346002)(39860400002)(186003)(86362001)(19627405001)(4326008)(8936002)(55016002)(52536014)(9686003)(316002)(110136005)(66574015)(26005)(83080400001)(478600001)(2906002)(7696005)(44832011)(54906003)(30864003)(33656002)(166002)(71200400001)(66476007)(6506007)(64756008)(66556008)(966005)(76116006)(83380400001)(5660300002)(91956017)(66946007)(53546011)(8676002)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: OVBK/L4+yUh8OZE/LGQMTJKfyMhgEs7KVp9u7V4HFX/hPI1pzm4JK8OXvJtR02LoyppWSsN7Q+JA5DbxHAYq3/gafKuN2vyrnRT68Tfn16K2Pm0Cx8iFzHHKvm5nJF4rC+X1pI275DAbT+1Vcj9bx5E4GTD08JRGzmABDZaEI9lwvzqNcph/NM2Vadt4mNvYhV3n4wnTrHD2GOsn/VXyDiW4C8Mj3XQf8p5+NmgUFPZq3rd95oQaIwGbH6W20NJMHmVMDPmbZAYsdHNRiLFhbizhFS/x2JTXxFxKAlSHBqdj89MHZJK8y+Iuc69mGiBDCxTfCmQ6UStrX7iPPUJ4MpFxs3uXEIt01YWdQkSH04ZlAqe9Eaqu49n4djJyxxnUNdSTKlVqr+GIZYVEaQAJ1lE1m9GTIE0u5/bEOLqN+sKjoNylBOXnN3kAviYIBQft5GngsiJqf5Md+r+RvuHTjfWW7X8IUUmnapLEGfLvP2thFIc8mgujt73RjPl3JM8ap0w41p40jtuHF1R77Vok+0lggcFC9lTNsBNYyUsWBOSC+tbjQpMdeAgBdbqH87a9OL9RFa3G1W8UCRe+aBehNt2jnsc1YJ2Jy6EWBH9xT1JQid91akZikjTcR8bH/C+lTZ6UzAIg5gCDJMDJWW1quQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR15MB3791606022768ADD17734AE2E3450SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR15MB3791.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 754edee7-1a69-4901-8ef2-08d83dfbc5a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 13:38:03.3150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tqYRzmuNoQZQuppb4HuDJ4VJ2zj+N8gqLLgNpYBJxpWNdPj8Dl9qjkC7xWYn8GFDJ3DtYPqRLXtHsXhMo7AJV5dWdMk38QRvu0XC6yGcmi0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2511 Archived-At: Subject: Re: [Lwip] Iotdir early review of draft-ietf-lwig-curve-representations-08 X-BeenThere: lwip@ietf.org 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: Tue, 11 Aug 2020 13:38:11 -0000 --_000_SA0PR15MB3791606022768ADD17734AE2E3450SA0PR15MB3791namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rene, Thanks, that seems much clearer - at least to me. Note that for the last nit, I can live with it and I am fine with whatever = you believe is best. My comment wanted mostly to emphasise that these secti= ons were very instructive - to me! Yours, Daniel ________________________________ From: Rene Struik Sent: Monday, August 10, 2020 3:13 PM To: Daniel Migault ; Daniel Migault Cc: Iot-dir@ietf.org ; lwip@ietf.org ; dra= ft-ietf-lwig-curve-representations.all@ietf.org Subject: Re: [Lwip] Iotdir early review of draft-ietf-lwig-curve-representa= tions-08 Hi Daniel: Thanks for your additional feedback. To address your nits (except the last one), I slightly reworded the first s= ection as below. I suggest I incorporate this in an official new upload onc= e this document moves along further (just to avoid a proliferation of tiny = deltas). {I will then also try and rethink your last nit.} I hope this work= s. BTW - all switches between curve models work equally well for any curve in = any of the models (as long as the mathematical object does exist). In parti= cular, it works equally well for Curve25519 and Curve448 flavors and with p= rotocols that use these as building blocks. {It also works for pairing-base= d crypto and, e.g., supersingular curves used with isogeny-based post-quant= um schemes. (No need to worry about the latter: I simply wanted to express = that the exposition in the draft is general enough to cover all of those, e= ven if one only cares about traditional elliptic curves.)} Slightly reworded first section: 1. Fostering Code Reuse with New Elliptic Curves Elliptic curves can be represented using different curve models. 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 curve model. These so-called CFRG curves [RFC7748] use the Montgomery curve model and the model of twisted Edwards curves. In this document, we specify these curves using the traditional "short" Weierstrass model and also define how to efficiently switch between representations in these different curve models. In particular, we specify Wei25519, which allows an alternative representation of points of Curve25519 (a Montgomery curve) and of points of Edwards25519 (a twisted Edwards curve), as points of a corresponding "short" Weierstrass curve. Similarly, we specify Wei448, which allows an alternative representation of points of Curve448 (a Montgomery curve) and of points of Ed448 (an Edwards curve), as points of a corresponding "short" Weierstrass curve. Use of Wei25519 and Wei448 allows easy definition of new instantiations of 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). To illustrate this, we specify how to use Wei25519 and Wei448 with co-factor ECDH and with ECDSA, thereby giving rise to the key agreement schemes ECDH25519 and ECDH448 and the signature schemes ECDSA25519 and ECDSA448. In all these cases, implementors may use the curve arithmetic for the curve model of their choosing (where they can efficiently switch between representations in different curve models, if required). For ease of exposition, we consider Wei25519 first and introduce Wei448 simply as an illustration of how to create other "offspring" objects and protocols (see Section 4.4). We also provide extensive background material that we hope may be useful for implementors of elliptic curve cryptography or for cross-referencing with future specification work. On 2020-08-10 10:35 a.m., Daniel Migault wrote: Hi, I expected to provide additional comments after the IETF but I happened to = be sick last week which explains the slow response. I apology for it. The document seems to me very clear and nicely written. This version addre= sses my earlier comments. Some nits: In the Introduction I think it would be nice to specify that the document provides guideline to= do similar work for 448 curves or if it also specifies Wei448. >From the current text it seems not. A nit the sentence "This document ... " is pretty long and it maybe would b= e clearer to say "This document specifies Wei25519, an alternative ...." bu= t that is very personal ;-) ECDSA25519 is also not mentioned at all in the introduction. It seems to me= important to position it briefly. More specifically, - at least this is my= understanding of it - Wei25519 was motivated to enable the implementation= of Montgomery curve Curve25519 operations, re-using implementations for th= e NIST curves while ECDSA25519 enables the implementation of ECDSA with Mon= tgomery curve Curve25519. This seems to me slightly different. just before section 10.2.1: s/scheme scheme/scheme I have the impression section 4.1 - 4.4 are more than Examples ;-) Yours, Daniel On Mon, Jul 20, 2020 at 9:54 AM Daniel Migault > wrote: Hi Rene, Thank you for the feed back - I am just back from vacation. As far as I rem= ember, my comments mostly concerned some clarifications and should not be s= een as preventing the document to move forward - especially for an early re= view. I did appreciated the way you handled the comments and believe your a= re the best person to know and decide how to handle these comments. I have not reviewed the latest version, but I can commit to review the draf= t in August. I hope that does not prevent the document to be moved forward. Yours, Daniel ________________________________ From: Rene Struik > Sent: Tuesday, July 14, 2020 1:43 PM To: Daniel Migault >; Iot-dir@ietf..org > Cc: lwip@ietf.org >; draft-ietf-lwig-curve-representations.all@ietf.org > Subject: Re: Iotdir early review of draft-ietf-lwig-curve-representations-0= 8 Hi Daniel: It has been a while that you provided your early IoTDir review comments. I = do not know whether such early reviews are a gate keeper for sealing off th= e lwig curve draft. Nevertheless, it may be good to know if you are reasona= bly happy for this to move forward. For some details on how I tried to take your comments into account, please = see my March 10th email below, where the mailing list link is https://mailarchive.ietf.org/arch/msg/lwip/KbJDWtpenYPNDuzVI05ZR4XGLhY/ For the current draft, see https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ I am looking forward hearing back from you.. Best regards, Rene On 2020-03-10 12:01 p.m., Rene Struik wrote: Hi Daniel: I tried to take into account your comments with draft-ietf-lwig-curve-repre= sentations-09. I will send out a separate email to the list highlighting main changes. Below, I will explain how I tried and accommodate your previous comments on= the 08-draft, now that the new draft is out. Important note: Based on offline communications with SecDir people, I did include Curve448-= related material with the 09 version. I tried to do this in a way that woul= d create the least editorial upheaval and would not take away from the main= objectives of the document: to this end, I only introduced Curve448-relate= d material in Section 4.4 [thereby avoiding having to sprinkle in curve448-= related language in each section and blurring the message of the document].= The only other sections where Curve448 plays a role is IANA Section 10 and= the appendices that give the parameters and test vectors for the Curve448 = family members. {Note: I probably should have added a note on ECDSA448 in t= he security consideration section, though (I made a note on this and will f= ix).} On 10/25/2019 4:26 PM, Rene Struik wrote: Hi Daniel: Thanks very much for your constructive review. I provided brief feedback on some of your comments - see below (RS>> < Overall I have the impression the document's intent is to define Wei25519 f= or 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 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 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. 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. RS>> Elliptic-curve and Finite Field-related notation is introduced in Anne= x B, see https://tools.ietf.org/id/draft-ietf-lwig-curve-representations-08= .html#rfc.appendix.B This notation is well-aligned with conventions in ANSI, NIST, SECG, and BSI= specifications. It is also in line with RFC 6090. <> I did revisit notational convention, also based on reviewing the draf= t NIST SP 800-186 and draft FIPS Pub 186-5 documents (out for public review= Oct 31, 2019 till Jan 29, 2020; closed now). Based on this, I slightly edi= ted Appendix B (backgrounder on curve terminology and finite fields). I did= decide not to align with some recent cfrg notation, since - frankly - I be= lieve it is a mess and the only outlier w.r.t. ANSI, NIST, SECG,and BSI spe= cs. < nits: It might be preferred to remain factual and simply say "Elliptic curv= es can be represented using different models." 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. 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. RS>> The reason to use the word "claimed" is that, from my perspective, it= is unclear that the claim actually holds. {My opinion on the matter is irr= elevant for this document, though.} As to performance, this depends on implementation details, see, e.g., remar= ks on existing hardware implementations (see the forelast para of https://= tools.ietf.org/id/draft-ietf-lwig-curve-representations-08.html#rfc..sectio= n.6). As to robustness, see the second para of https://tools.ie= tf.org/id/draft-ietf-lwig-curve-representations-08.html#rfc..section.8). As to different perspectives on performance vs. robustness, see a= lso Item 1.3b of p. 77 of https://csrc.nist.gov/CSRC/media/Publications/fip= s/186/4/final/documents/comments-received-fips186-4-december-2015.pdf. To my knowledge, Weierstrass curves, such as the NIST prime curves are stil= l very much prevalent to-date (so "were widely deployed" is probably someth= ing that actually still is). <> I kept the language as is, based on assessment above. < 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. 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). 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. RS>> New refers to a new instantiation, e.g., ECDSA with the Wei25519 curve= simply defines a new curve to be used with an existing generically specifi= ed ECDSA specification. <> I tried and accommodate this with the following text in Section 4.3 (= with [...] deleted from this email): FIPS Pub 186-4 [FIPS-186-4] specifies the signature scheme ECDSA and can be= instantiated not just with the NIST prime curves, but also with other Weie= rstrass curves (that satisfy additional cryptographic criteria). In particu= lar, one can instantiate this scheme with the Weierstrass curve Wei25519 an= d the hash function SHA-256 [FIPS-180-4], [...] We denote by ECDSA25519 the instantiation of ECDSA with SHA-256 and with cu= rve Wei25519, where the signature (r,s) is represented as the right-concate= nation of the integers r and s, each represented as fixed-size strings with= tight MSB/msb ordering (see Appendix I). < 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. 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=3D2 and a=3D-3 (mod p), respectively; see Appendix G. (Here, p is the characteristic of the field over which these curves are defined.) 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. RS1>> I reflected on this and investigated the impact on the integrity and= editorial cohesion of the document. Main problem with moving the actual do= main parameters of Wei25519 to the main body is that one still would have t= o understand where these come from, thereby requiring a look at the mapping= s from Montgomery to Weierstrass curves and vice-versa (Annex D), their ins= tantiation in this particular case (Annex E), where for isogenies one would= have to delve into Annex F (general informative text) and Annex G (instant= iation in this particular case). With the added Curve448-related material, = this would become even messier, esp. since - in Annex M.3 - I had to add a = note that some parameters in RFC7748 and some mappings in there are actuall= y incorrect. Since the main body focuses on benefit of switching between di= fferent curve models, even if one does not care about a particular curve in= question, I thought it best to stick to emphasizing that point (see Sectio= n 3 - Use of Representation Switches) and not drive potential readers away = with long parameter lists and minutiae in the main body. If there is one th= ing I would like to stick with readers of the draft, it is how representati= on switches work in general and how these could help in code reuse of speci= fication reuse. < This is just a comment that ascii does not help reading 1=3D47... but there= is no much we can do. RS1>> Agreed. However, lots of variables already have a connotation, so sti= cking to l (length or degree) seemed best. <I believe we should specify somewhere that changing the representatio= n does not ease the ECDLP for a given prime/curve RS>> This is a good observation. I captured this generally in the Security = Considerations section (see first para of https://tools.ietf.org/id/draft-i= etf-lwig-curve-representations-08.html#rfc..section.8) and also= reminded the reader of this when introducing each isomorphism discussed in= the document. See https://tools.ietf.org/id/draft-ietf-lwig-curve-represen= tations-08.html#rfc..appendix.D, where I added this remark for= the isomorphic mapping from twisted Edwards to Montgomey (Annex D.1, end o= f first para), Montgomery to Weierstrass (Annex D.2, end of first para). I = did not repeat this for the twisted Edwards to Weierstrass mapping (Annex D= .3) or with the low-degree isogenies (Annex F), but could certainly sprinkl= e this in there as well, if so desired. <> If you feel I should add more than I did with rev-09 already, please = let me know and I can sprinkle this in. < 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, th= at is 4.1 -> 4. 4.2->5... RS1>> I kept the header "examples" in (sorry), since these are examples of = how representation switches can be used to define what in Section 4.4 I cal= l "offspring protocols". That is only a section heading, though. < 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. RS>> As you suggested above, not all curves can be expressed in Montgomery = or twisted Edwards format (see also the 6th para of Appendix B.1: https://t= ools.ietf.org/id/draft-ietf-lwig-curve-representations-08.html#rfc.appendix= .B.1). This being said, all [non-binary] curves *are* isomorphic to one in = short-Weierstrass format, so that the short-Weierstrass format can be thoug= ht of as a "catch all" representation format. <> As explained above. < | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip -- Daniel Migault Ericsson -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 --_000_SA0PR15MB3791606022768ADD17734AE2E3450SA0PR15MB3791namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rene, 

Thanks, that seems much clearer - at least to me. 
Note that for the last nit, I can live with it and I am fine with whatever = you believe is best. My comment wanted mostly to emphasise that these secti= ons were very instructive - to me!

Yours, 
Daniel
From: Rene Struik <rstru= ik.ext@gmail.com>
Sent: Monday, August 10, 2020 3:13 PM
To: Daniel Migault <mglt.ietf@gmail.com>; Daniel Migault <d= aniel.migault@ericsson.com>
Cc: Iot-dir@ietf.org <Iot-dir@ietf.org>; lwip@ietf.org <lwi= p@ietf.org>; draft-ietf-lwig-curve-representations.all@ietf.org <draf= t-ietf-lwig-curve-representations.all@ietf.org>
Subject: Re: [Lwip] Iotdir early review of draft-ietf-lwig-curve-rep= resentations-08
 
Hi Daniel:

Thanks for your additional feedback.

To address your nits (except the last one)= , I slightly reworded the first section as below. I suggest I incorporate t= his in an official new upload once this document moves along further (just = to avoid a proliferation of tiny deltas). {I will then also try and rethink your last nit.} I hope this works.

BTW - all switches between curve models wo= rk equally well for any curve in any of the models (as long as the mathemat= ical object does exist). In particular, it works equally well for Curve2551= 9 and Curve448 flavors and with protocols that use these as building blocks. {It also works for pairing-based crypto= and, e.g., supersingular curves used with isogeny-based post-quantum schem= es. (No need to worry about the latter: I simply wanted to express that the= exposition in the draft is general enough to cover all of those, even if one only cares about traditional ell= iptic curves.)}

Slightly reworded first section:
1.  Fostering Code Reuse with New Elliptic Curve=
s

   Elliptic curves can be represented using different curve models.
   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 curve model.  These so-called CFRG curves [RFC7748] use
   the Montgomery curve model and the model of twisted Edwards curves.

   In this document, we specify these curves using the traditional
   "short" Weierstrass model and also define how to efficiently s=
witch
   between representations in these different curve models.  In
   particular, we specify Wei25519, which allows an alternative
   representation of points of Curve25519 (a Montgomery curve) and of
   points of Edwards25519 (a twisted Edwards curve), as points of a
   corresponding "short" Weierstrass curve.  Similarly, we specif=
y
   Wei448, which allows an alternative representation of points of
   Curve448 (a Montgomery curve) and of points of Ed448 (an Edwards
   curve), as points of a corresponding "short" Weierstrass curve=
.

   Use of Wei25519 and Wei448 allows easy definition of new
   instantiations of 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).  To ill=
ustrate
   this, we specify how to use Wei25519 and Wei448 with co-factor ECDH

   and with ECDSA, thereby giving rise to the key agreement schemes
   ECDH25519 and ECDH448 and the signature schemes ECDSA25519 and
   ECDSA448.  In all these cases, implementors may use the curve
   arithmetic for the curve model of their choosing (where they can
   efficiently switch between representations in different curve models,
   if required).

   For ease of exposition, we consider Wei25519 first and introduce
   Wei448 simply as an illustration of how to create other "offspring&=
quot;
   objects and protocols (see Section 4.4).  We also provide extensive
   background material that we hope may be useful for implementors of
   elliptic curve cryptography or for cross-referencing with future
   specification work.


On 2020-08-10 10:35 a.m., Daniel Migault w= rote:
Hi, 

I expected to provide additional comments after the IETF but I happene= d to be sick last week which explains the slow response. I apology for it.<= /div>

The document seems to me very clear and nicely written.  This ver= sion addresses my earlier comments. 

Some nits:

In the Introduction

I think it would be nice to specify that the document provides guideli= ne to do similar work for 448 curves or if it also specifies Wei448.
>From the current text it seems not.

A nit the sentence "This document ... " is pretty long and it may= be would be clearer to say "This document specifies Wei25519, an alter= native ...." but that is very personal ;-)

ECDSA25519 is also not mentioned at all in the introduction. It s= eems to me important to position it briefly. More specifically, - at least = this is my understanding of it -  Wei25519 was motivated to enable the= implementation of Montgomery curve Curve25519 operations, re-using implementations for the = NIST curves while ECDSA25519 enables the implementation of ECDSA with = Montgomery curve Curve25519. This seems to me slightly different. 

just before section 10.2.1:  s/scheme scheme/scheme

I have the impression section 4.1 - 4.4 are more than Examples ;-)

Yours, 
Daniel

On Mon, Jul 20, 2020 at 9:54 AM Dan= iel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote:
Hi Rene, 

Thank you for the feed back - I am just back from vacation. As far as I rem= ember, my comments mostly concerned some clarifications and should not be s= een as preventing the document to move forward - especially for an early re= view. I did appreciated the way you handled the comments and believe your are the best person to  kno= w and decide how to handle these comments. 

I have not reviewed the latest version, but I can commit to review the draf= t in August. I hope that does not prevent the document to be moved forward.=  

Yours, 
Daniel 
Fr= om: Rene Struik <rstruik.ext@gmail.com>
Sent: Tuesday, July 14, 2020 1:43 PM
To: Daniel Migault <daniel.migault@ericsson.com>; I= ot-dir@ietf..org <Iot-dir@ietf.org>
Cc: lwip@ietf.org= <lwip@ietf.org>; draft-ietf-lwig-curve-representations.all@ietf.org <dra= ft-ietf-lwig-curve-representations.all@ietf.org>
Subject: Re: Iotdir early review of draft-ietf-lwig-curve-representa= tions-08
 
Hi Daniel:

It has been a while that you provided your early IoTDir review comment= s. I do not know whether such early reviews are a gate keeper for sealing o= ff the lwig curve draft. Nevertheless, it may be good to know if you are re= asonably happy for this to move forward.

For some details on how I tried to take your comments into account, pl= ease see my March 10th email below, where the mailing list link is

For the current draft, see

I am looking forward hearing back from you..

Best regards, Rene

On 2020-03-10 12:01 p.m., Rene Struik wrote:
Hi Daniel:

I tried to take into account your comments with draft-ietf-lwig-curve-repre= sentations-09.

I will send out a separate email to the list highlighting main changes.
Below, I will explain how I tried and accommodate your previous comments on= the 08-draft, now that the new draft is out.

Important note:
Based on offline communications with SecDir people, I did include Curve448-= related material with the 09 version. I tried to do this in a way that woul= d create the least editorial upheaval and would not take away from the main= objectives of the document: to this end, I only introduced Curve448-related material in Section 4.4 [ther= eby avoiding having to sprinkle in curve448-related language in each sectio= n and blurring the message of the document]. The only other sections where = Curve448 plays a role is IANA Section 10 and the appendices that give the parameters and test vectors for the Cu= rve448 family members. {Note: I probably should have added a note on ECDSA4= 48 in the security consideration section, though (I made a note on this and= will fix).}

On 10/25/2019 4:26 PM, Rene Struik wrote:
Hi Daniel:

Thanks very much for your constructive review.

I provided brief feedback on some of your comments - see below (RS>= > <<RS). Where I did not provide a comment yet, I will reflect on = these later (and this may benefit from looking at the results from the pend= ing SecDir review, once ready, at the same time).

Best regards, Rene

On 10/25/2019 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 th=
e
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 mo=
ved
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 f=
or
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 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 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>

RS>> Elliptic-curve and Finite Field-related notation is introduce= d in Annex B, see https://tools.i= etf.org/id/draft-ietf-lwig-curve-representations-08.html#rfc.appendix.B=

This notation is well-aligned with conventions in ANSI, NIST, SECG, and = BSI specifications. It is also in line with RFC 6090.

<<RS

RS1>> I did revisit notational convention, also based on reviewing= the draft NIST SP 800-186 and draft FIPS Pub 186-5 documents (out for publ= ic review Oct 31, 2019 till Jan 29, 2020; closed now). Based on this, I sli= ghtly edited Appendix B (backgrounder on curve terminology and finite fields). I did decide not to align with so= me recent cfrg notation, since - frankly - I believe it is a mess and the o= nly outlier w.r.t. ANSI, NIST, SECG,and BSI specs. <<RS1

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 cur=
ves
with Weierstrass model were widely deployed and implemented. </mglt><=
/pre>

RS>>  The reason to use the word "claimed" is that,= from my perspective, it is unclear that the claim actually holds. {My opin= ion on the matter is irrelevant for this document, though.}

As to performance, this depends on implementation details, see, e.g., re= marks on existing hardware implementations (see the forelast para of  https://tools.ietf.org/id/draft-ietf-lwig-curve-representations-08.html#rfc= ..section.6). As to robustness, see the second para of https://tools.ietf.org/id/draft-ietf-lwig-curve-representations-08.html#rfc= ..section.8). As to different perspectives on performance vs. robustnes= s, see also Item 1.3b of p. 77 of https://csrc.nist.gov/CSRC/media/Publications/fips/186/4/final/documents/co= mments-received-fips186-4-december-2015.pdf.

To my knowledge, Weierstrass curves, such as the NIST prime curves are s= till very much prevalent to-date (so "were widely deployed" is pr= obably something that actually still is).

<<RS

RS1>> I kept the language as is, based on assessment above. <<R= S1
   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 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>

   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 fo=
rm (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&g=
t;
RS>> New refers to a new instantiation, e.g., ECDSA with the Wei25519= curve simply defines a new curve to be used with an existing generically s= pecified ECDSA specification. <<RS

RS1>> I tried and accommodate this with the following text in Sect= ion 4.3 (with [...] deleted from this email):

FIPS Pub 186-4 [FIPS-186-4] specifies the signature scheme ECDSA and can= be instantiated not just with the NIST prime curves, but also with other W= eierstrass curves (that satisfy additional cryptographic criteria). In part= icular, one can instantiate this scheme with the Weierstrass curve Wei25519 and the hash function SHA-256 [= FIPS-180-4], [...]

We denote by ECDSA25519 the instantiation of ECDSA with SHA-256 and with= curve Wei25519, where the signature (r,s) is represented as the right-conc= atenation of the integers r and s, each represented as fixed-size strings w= ith tight MSB/msb ordering (see Appendix I).

<<RS1

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 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>

   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=3D2 and a=3D-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 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>

RS1>>  I reflected on this and investigated the impact on the= integrity and editorial cohesion of the document. Main problem with moving= the actual domain parameters of Wei25519 to the main body is that one stil= l would have to understand where these come from, thereby requiring a look at the mappings from Montgomery to Weierstr= ass curves and vice-versa (Annex D), their instantiation in this particular= case (Annex E), where for isogenies one would have to delve into Annex F (= general informative text) and Annex G (instantiation in this particular case). With the added Curve448-related= material, this would become even messier, esp. since - in Annex M.3 - I ha= d to add a note that some parameters in RFC7748 and some mappings in there = are actually incorrect. Since the main body focuses on benefit of switching between different curve models, = even if one does not care about a particular curve in question, I thought i= t best to stick to emphasizing that point (see Section 3 - Use of Represent= ation Switches) and not drive potential readers away with long parameter lists and minutiae in the main body. If t= here is one thing I would like to stick with readers of the draft, it is ho= w representation switches work in general and how these could help in code = reuse of specification reuse.

<<RS1

3.  Use of Representation Switches

   The curve Wei25519.-3 (which has hardcoded domain parameter a=3D-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=3D47 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=3D47, but does not map G' to G, but to a fixed multiple hereof, where
   this multiple is l=3D47.  Consequently, a public-private key pair
   (k,R:=3Dk*G) for Wei25519 corresponds to the public-private key pair
   (k, R':=3D k*G') for Wei25519.-3 (via the l-isogeny), whereas the
   public-private key pair (k, R':=3Dk*G') corresponds to the public-
   private key pair (l*k, l*R=3Dl*k*G) of Wei25519 (via the dual isogeny).
   (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>
RS1>> Agreed. However, lots of variables already have a connotation, = so sticking to l (length or degree) seemed best. <<RS1
   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 represe=
ntation
does not ease the ECDLP for a given prime/curve</mglt>

RS>> This is a good observation. I captured this generally in the = Security Considerations section (see first para of https://tools.ietf.org/id/draft-ietf-lwig-curve-representations-08.html#rfc= ..section.8) and also reminded the reader of this when introducing each= isomorphism discussed in the document. See https://tools.ietf.org/id/draft-ietf-lwig-curve-representations-08.html#rfc= ..appendix.D, where I added this remark for the isomorphic mapping from= twisted Edwards to Montgomey (Annex D.1, end of first para), Montgomery to= Weierstrass (Annex D.2, end of first para). I did not repeat this for the twisted Edwards to Weierstrass = mapping (Annex D.3) or with the low-degree isogenies (Annex F), but could c= ertainly sprinkle this in there as well, if so desired.

<<RS

RS1>> If you feel I should add more than I did with rev-09 already, p= lease let me know and I can sprinkle this in. <<RS1
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, th=
at
is 4.1 -> 4. 4.2->5... </mglt>
RS1>> I kept the header "examples" in (sorry), since these = are examples of how representation switches can be used to define what in S= ection 4.4 I call "offspring protocols". That is only a section h= eading, though. <<RS1
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 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>
RS>> As you suggested above, not all curves can be expressed in =
Montgomery or twisted Edwards format (see also the 6th para of Appendix B.1=
: https://tools.ietf.org/id/dra=
ft-ietf-lwig-curve-representations-08.html#rfc.appendix.B.1). This bein=
g said, all [non-binary] curves *are* isomorphic to one in short-Weierstras=
s format, so that the short-Weierstrass format can be thought of as a "=
;catch all" representation format.=20
<<RS
RS1>> As explained above. <<RS1
   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.





--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867


--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


--
Daniel Migault
Ericsson


--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--_000_SA0PR15MB3791606022768ADD17734AE2E3450SA0PR15MB3791namp_--