Subject: Re: [COSE] draft-ietf-lwig-curve-representations-13

From: John Mattsson <[email-masked]>
Date: Sun, 14 Feb 2021 21:08:00 +0000

Hi Rene,

True, Jim used to be one the experts. My comment that you did not talk to any of the experts is not true.

The only IANA history I know of started on 6 Nov 2020 when Göran (one of the experts) followed the procedure and sent a mail to the COSE mailing list commenting and asking about the COSE registrations. I and several other people in COSE WG seem to share Göran’s concerns. You cannot expect COSE WG to read your draft before somebody send it to the list. If I had written the draft I would personally had sent in to COSE a long time ago. I wish someone would have helped you with that.

You need to ask Göran and the other two experts on the status but to me it seems like the COSE WG is aligning on the technical aspects of the IANA registrations:

https://mailarchive.ietf.org/arch/browse/cose/?gbt=1&index=IEx4C67-IGkQ9BpI8DUFxhElcwA

Cheers,
John

From: Rene Struik <[email-masked]>
Date: Sunday, 14 February 2021 at 20:11
To: John Mattsson <[email-masked]>, Göran Selander <goran.selander=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: (small timeline correction) Re: [COSE] draft-ietf-lwig-curve-representations-13

Correction: LWIG WGLC was in August 2019 and not August 2020, as I mistakenly put in my previous note (i.e., already 18 1/2 months or more than 1 1/2 years ago).
See https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/history/

On 2021-02-14 2:04 p.m., Rene Struik wrote:
Hi John:

I did have a brief look at my past correspondence on iana-cose code points, where I discussed this with Jim Schaad (designated iana cose expert over the relevant time period):
- email correspondences {March 27, 2019; April 12, 2019; April 15, 2019};
- f/u. discussions w/ Jim Schaad (triggered by trying to help out Pascal Thubert on his ap-nd Editor queue draft): phone call {Thu March 16, 2020}; email correspondence {April 6/7/22/25, 2020}

History of iana sections in curve-draft document:
- iana/cose section has been in there since April 14, 2019 (v04 of the draft). See https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/04/
- WGLC LWIG group: August 6, 2019;
- IETF Last-Call: August 24, 2020 (two-week);
- your comment: Nov 9, 2020
- your (nontechnical) email below: today, Feb 14, 2021 (32 days after my last email to the list).

Contrary to what you seem to suggest below, my records above indicate I have reached out to the relevant people already almost two (!) years ago, in good conscience (where email and phone conversations with Jim Schaad were productive, with 1-2 days feedback loop). I have trouble understanding why during all this time the technical points you seem to take issue with have not been narrowed down (as I repeatedly suggested offline and which is good engineering practice). Please note that even something as simple an uncontroversial as registering Wei25519 and Wei448 has not been stricken off the list since the November 2020 note. I think one should reflect why this (in an Internet *Engineering* Task Force).

Best regards, Rene

On 2021-02-14 3:13 a.m., John Mattsson wrote:
Hi Rene,

>I value your feedback, even though you brought up your points more than two months after the
>IETF Last-Call.

All the comments has been purely regarding the IANA registrations for COSE. To my understanding you did not discuss these registrations with the dedicated IANA experts or the COSE WG beforehand. The suggested COSE registration are quite strange. Any delay is purely due to you not discussing and anchoring these registrations. I have suggested that that this issue is discussed at the interim on Tuesday, but it is not my job to drive your registrations. I am just commenting on the questions from the dedicated IANA experts.

You can always remove the COSE registrations, but I think that would be sad. I agree with you that a registration for Wei25519 is good to have. Another alternative is to move the registration to a separate draft.

>I uploaded a new version of the lwig curve draft [1], changing the intended status to "standards track". I hope
>this helps.

You cannot just change the status from “informational” to “standards track”. They are very different things. Informational is just general information, while standards track means IETF consensus and recommendation. Changing the status would (I assume) require wg consensus and then redoing the last calls.

/John

From: Rene Struik <[email-masked]><mailto:[email-masked]>
Date: Wednesday, 13 January 2021 at 15:26
To: John Mattsson <[email-masked]><mailto:[email-masked]>, Göran Selander <goran.selander=[email-masked]><mailto:goran.selander=[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [COSE] draft-ietf-lwig-curve-representations-13

Hi Goran, John:

Please let me know if my response to the COSE mailing list (Dec 19th) works for you. If you have comments, please suggest constructive improvements.

I really would like to get closure on this.

I value your feedback, even though you brought up your points more than two months after the IETF Last-Call. I hope we can move forward without undue delays.

Thanks for your help, Rene
On 2020-12-19 11:01 a.m., Rene Struik wrote:

Dear John:

Based on your review and other feedback received, I slightly updated the draft and posted the latest revision as [1].

Your review below (of Nov 6, 2020) seems to bring up three topics, viz.: (1) definition of Wei25519 and Wei448 vs. verbiage in NIST docs; (2) need for iana registrations for ECDSA25519 and ECDSA448; (3) need for iana registrations ECDH25519 and ECDH448.

Please find below some feedback.

General feedback:

Please bear in mind that the specifications of ECDSA25519 and ECDH25519 in the lwig curve document aim to yield schemes that are strictly NIST-compliant (i.e., these would allow FIPS 140-2 accreditation if the curves would be in the "NIST recommended" set). See also Note 2 of Section 4.1 of [1]. A similar remark applies to ECDSA448 and ECDH448.

Detailed feedback:

(1) Definition of Wei25519 and Wei448 vs. verbiage in NIST docs.

Draft NIST SP 800-186 indeed defines a short-Weierstrass version of Curve25519 [dubbed W-25519] and FIPS 186-5 allows its use; similar for Curve448 [dubbed W-448 there]). I have now added references to these draft specifications in the lwig-curve draft. I have double-checked all domain parameters, mappings between curve models, tables of isogeny details in the lwig draft and provided Sage scripts for the CFRG crypto panel review at the time. I do anticipate that NIST will arrive at the same values in their final publication when they decide to publish this. (I am happy to share Sage scripts for this purpose.)

(2) Need for iana registrations for ECDSA25519 and ECDSA448.

ECDSA is determined by an instantiation of hash function, curves, and representation conventions for inputs and outputs (i.e., message representation, curve point representation, and signature representation).
a) ECDSA448 uses SHAKE256 under the hood, which is currently not defined with COSE. Hence, my request to register ECDSA w/ SHAKE256 and Wei448 as "ECDSA448".
b) ECSA25519 uses SHA256 and Wei25519 under the hood. I thought to request to register "ECDSA25519" since this would allow referencing the quite careful write-up (Section 4.3), including bit/byte ordering, checks, and nondeterministic behavior (and, thereby, keeping this concise). Please note that this is very similar to the COSE IANA registry for "ES256k1" (ECDSA w/ SHA256 and Bitcoin curve secp256k1).

(3) Need for iana registrations ECDH25519 and ECDH448.

ECDH25519 and ECDH448 are co-factor Diffie-Hellman key establishment schemes and can, therefore, not be based on (cofactorless) Diffie-Hellman, as defined in RFC 8152. (Please note that there is no difference for the NIST curves, which all of co-factor h=1, but in our case one has h=8 and h=4, respectively). Here, one should note that the ECDH25519 and ECDH448 write-ups (Section 4.1 and 4.3) quite carefully cross-reference co-factor ECDH in a NIST-compliant way. Apart from the co-factor ECDH vs. ECDH issue and objective to comply with all strict NIST validation checks, the objective was also to make sure that ECDH25519 and ECDH448 can be used in settings where either or both parties uses ephemeral keys (which is more flexible than what RFC 8152 allows).  Hence, the request to register "ECDH25519" and "ECDH448", to make sure this covers the intent of these schemes accurately and with precise description.

It is possible that I overlooked something in this assessment. If so, any constructive suggestions are welcome.

Ref: [1] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19

Best regards, Rene
On 2020-11-06 5:04 p.m., John Mattsson wrote:

Hi,

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.

I find it strange that the IANA registration has not been coordinated with COSE WG at all. I am a bit surprised to see IANA registrations for COSE/JOSE/PKIX/CMS at all in a LWIG draft (is that in charter?). If LWIG wants to register new algorithms, I think LWIG at a minimum should coordinate with COSE WG and other groups. I think this draft should be presented at the next COSE WG meeting.

I support registration of W-25519 and W-448 curves as long they agree with NIST. I would like answers to the questions why ECDSA25519 and ECDH25519 are needed at all. There is no ECDSAP256 and no ECDHP256, so why are specific algorithm registration needed for W-25519?  It makes no sense to me that a special signature registration is needed for COSE but not for PKIX? If PKIX can use ecdsa-with-SHA256 why cannot COSE use ES256?

I don't think ANSI X9.62 is an acceptable normative reference. NIST just removed the normative reference to ANSI X9.62 in SP 186-5.

Cheers,
John

From: COSE <[email-masked]><mailto:[email-masked]> on behalf of Rene Struik <[email-masked]><mailto:[email-masked]>
Date: Friday, 6 November 2020 at 20:37
To: Göran Selander <goran.selander=[email-masked]><mailto:goran.selander=[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [COSE] draft-ietf-lwig-curve-representations-13

Hi Goran:

Please find below some brief feedback on your note:
- the naming wei25519 has been around since the first draft (Nov 13, 2017, i.e., 3 years minus 1 week ago), see [1]. NIST indeed produced two draft documents, viz. Draft NIST SP 800-186 and Draft FIPS Pub 186-5 (on October 31, 2019), which generated lots of (to my knowledge still unresolved) comments during public review. It is hard to refer to that document, since it is only a draft and unfortunately has quite a few errors.
- earlier versions of the lwig draft have received reviews by the crypto review panel (Stanislavslav Smyshlyaev), iotdir early-review (Daniel Migault); the sections on COSE/JOSE code point assignments resulted from a phone call and various email exchanges with Jim Schaad; the section on PKIX/CMS was suggested during IETF Last-Call secdir-review (Russ Housley) and reviewed by him. The document had IETF Last-Call Aug 24, 2020. See, e.g., the status pages [1].
- ECDSA has been around since 1999, has been widely standardized, and has seen lots of analysis, where ECDSA25519 is simply yet another instantiation. Signature generation and verification times for ECDSA25519 should be similar to those of Ed25519 (since timing is dominated by scalar multiplication, where one could simply use Montgomery arithmetic [3]). In my personal view, ECDSA25519 may be more secure than Ed25519 (if only because it is non-deterministic, see Security section [6]); similar side-channel care has to be taken in either case.
 - As mentioned in the draft, one can easily switch between Wei25519 and Curve25519 (which requires a single field addition or subtraction only, i.e., <.01%, see Appendix E.2 [7]). As mentioned in the draft, one could use Wei25519.-3 with an existing generic implementation that hardcodes the domain parameter a=-3, but needs to compute an isogeny and dual isogeny for this (adding 5-10% cost, see Appendix G.2 [8]]) and a ~9.5kB table (see Section 5.3 [4]). However, if one already has generic hardware support, one may still have a significant win (see Section 6 [5]).
- The isogeny for Wei25519.-3 has odd degree l=47, which is co-prime with the order of the curve, so is in fact invertible. With Wei448.-3, the isogeny has degree l=2, so is not invertible; however, this does not really matter, since it is invertible with correctly generated public-private key pairs (which have prime/odd order) and the factor two is absorbed with co-factor ECDH, where h=4 then.

I hope this helps.

(*) For ease of tracking, it would help if iana related comments are flagged in the subject line (e.g., include (iana) in the beginning hereof).

Best regards, Rene

Ref with hyperlinks:
[1] https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00
[2] https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/
[3] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3
[4] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-5.3
[5] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-6
[6] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-8
[7] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.2
[8] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-G.2

On 2020-11-06 11:19 a.m., Göran Selander wrote:
Hi,

Apologies for cross-posting LWIG and COSE. I had a brief look at draft-ietf-lwig-curve-representations-13 and noticed it registers a lot of new COSE (and JOSE, PKIX, and CMS) algorithms. Has this draft been discussed in COSE (JOSE/CURDLE)? If not, perhaps it should be before being progressed?

1.       The draft needs to manage the overlap with NIST SP 800-186, which should be referenced and mappings, name of curves, etc. aligned. The draft defines Wei25519 and Wei448. It is unclear if these are identical to W-25519, W-448 as defined in NIST SP 800-186. We probably would not want two slightly different definitions and/or names, multiple COSE code points, etc.

1.       The draft registers the COSE algorithm "ECDSA25519" as "ECDSA with SHA-256 and curve Wei25519". That is not how the other COSE signature algorithms work. They work like PKIX where the curve is given by the public key. Also, why cannot W-25519 be used with the existing ES256 signature algorithm?

2.       The draft registers the COSE algorithm "ECDH25519". There are no COSE ECDH algorithms for P-256, why is an ECDH algorithm for W-25519 be needed?

Other questions. I may have missed it, but

2.       is it described what are the expected security properties of ECDSA25519 (including mapping) compared to Ed25519? For example w.r.t. side channel attacks?

3.       has any performance measurements been made comparing ECDSA25519 (including mapping) and Ed25519?

4.       similar questions on security and performance with Wei25519.-3 instead of Wei25519. If I understand right, the former mapping is not reversible, but could benefit from optimized code with hardcoded domain parameters.

5.       ANSI X9.62-2005 was withdrawn in 2015 and is behind a paywall, is this reference necessary?

Göran

_______________________________________________

COSE mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/cose

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
-->

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Rene Struik <[email-masked]>
Date: Sun, 14 Feb 2021 16:56:54 -0500

Hi John:

To my knowledge, I followed the steps described in Section 16.11 [1] 
(Expert Review Instructions), already in April 2019 (almost 2 years ago):

    16.11. Expert Review Instructions
    All of the IANA registries established in this document are defined
    as expert review. This section gives some general guidelines forwhat
    the experts should be looking for, but they are being designated as
    experts for a reason, so they should be given substantial latitude.

    Expert reviewers should take into consideration the following points:

    [snip (enumeration of four aspects to consider)]

I could not find the procedure you seemingly had in mind below in RFC 
8152 (a search in RFC 8152 on the term "email" also did not yield this 
info). Isn't this all described in Section 16.11 [1]? If you could point 
me to what I am apparently missing, please let me know!

In all fairness, I think you would have to agree that I did reach out to 
the relevant actors at the time, in good conscience, in a timely manner 
(in contrast to the language you used in your forelast email).

Best regards, Rene

Ref: [1] https://tools.ietf.org/html/rfc8152#section-16.11

On 2021-02-14 4:08 p.m., John Mattsson wrote:
> The only IANA history I know of started on 6 Nov 2020 when Göran (one 
> of the experts) followed the procedure and sent a mail to the COSE 
> mailing list commenting and asking about the COSE registrations. I and 
> several other people in COSE WG seem to share Göran’s concerns. You 
> cannot expect COSE WG to read your draft before somebody send it to 
> the list. If I had written the draft I would personally had sent in to 
> COSE a long time ago. I wish someone would have helped you with that.
>
> You need to ask Göran and the other two experts on the status but to 
> me it seems like the COSE WG is aligning on the technical aspects of 
> the IANA registrations:
>
> *From: *Rene Struik <[email-masked]>
> *Date: *Sunday, 14 February 2021 at 20:11
> *To: *John Mattsson <[email-masked]>, Göran Selander 
> <goran.selander=[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *(small timeline correction) Re: [COSE] 
> draft-ietf-lwig-curve-representations-13
>
> Correction: LWIG WGLC was in August 2019 and not August 2020, as I 
> mistakenly put in my previous note (i.e., already 18 1/2 months or 
> more than 1 1/2 years ago).
>
> See 
> https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/history/ 
> <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/history/>
>
>     I did have a brief look at my past correspondence on iana-cose
>     code points, where I discussed this with Jim Schaad (designated
>     iana cose expert over the relevant time period):
>
>     - f/u. discussions w/ Jim Schaad (triggered by trying to help out
>     Pascal Thubert on his ap-nd Editor queue draft): phone call {Thu
>     March 16, 2020}; email correspondence {April 6/7/22/25, 2020}
>
>     - iana/cose section has been in there since April 14, 2019 (v04 of
>     the draft). See
>     https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/04/
>     <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/04/>
>
>     Contrary to what you seem to suggest below, my records above
>     indicate I have reached out to the relevant people already almost
>     two (!) years ago, in good conscience (where email and phone
>     conversations with Jim Schaad were productive, with 1-2 days
>     feedback loop). I have trouble understanding why during all this
>     time the technical points you seem to take issue with have not
>     been narrowed down (as I repeatedly suggested offline and which is
>     good engineering practice). Please note that even something as
>     simple an uncontroversial as registering Wei25519 and Wei448 has
>     not been stricken off the list since the November 2020 note. I
>     think one should reflect why this (in an Internet *Engineering*
>     Task Force).
>
>     Best regards, Rene
>
>         All the comments has been purely regarding the IANA
>         registrations for COSE. To my understanding you did not
>         discuss these registrations with the dedicated IANA experts or
>         the COSE WG beforehand. The suggested COSE registration are
>         quite strange. Any delay is purely due to you not discussing
>         and anchoring these registrations. I have suggested that that
>         this issue is discussed at the interim on Tuesday, but it is
>         not my job to drive your registrations. I am just commenting
>         on the questions from the dedicated IANA experts.
>
>         You can always remove the COSE registrations, but I think that
>         would be sad. I agree with you that a registration for
>         Wei25519 is good to have. Another alternative is to move the
>         registration to a separate draft.
>
>         >I uploaded a new version of the lwig curve draft [1], changing the
>         intended status to "standards track". I hope
>
>         >this helps.
>
>         You cannot just change the status from “informational” to
>         “standards track”. They are very different things.
>         Informational is just general information, while standards
>         track means IETF consensus and recommendation. Changing the
>         status would (I assume) require wg consensus and then redoing
>         the last calls.
>
>         /John
>
>         *From: *Rene Struik <[email-masked]>
>         <mailto:[email-masked]>
>         *Date: *Wednesday, 13 January 2021 at 15:26
>         *To: *John Mattsson <[email-masked]>
>         <mailto:[email-masked]>, Göran Selander
>         <goran.selander=[email-masked]>
>         <mailto:goran.selander=[email-masked]>,
>         "[email-masked]" <mailto:[email-masked]> <[email-masked]>
>         <mailto:[email-masked]>, "[email-masked]" <mailto:[email-masked]>
>         <[email-masked]> <mailto:[email-masked]>
>         *Subject: *Re: [COSE] draft-ietf-lwig-curve-representations-13
>
>         Hi Goran, John:
>
>         Please let me know if my response to the COSE mailing list
>         (Dec 19th) works for you. If you have comments, please suggest
>         constructive improvements.
>
>         I value your feedback, even though you brought up your points
>         more than two months after the IETF Last-Call. I hope we can
>         move forward without undue delays.
>
>             Based on your review and other feedback received, I
>             slightly updated the draft and posted the latest revision
>             as [1].
>
>             Your review below (of Nov 6, 2020) seems to bring up three
>             topics, viz.: (1) definition of Wei25519 and Wei448 vs.
>             verbiage in NIST docs; (2) need for iana registrations for
>             ECDSA25519 and ECDSA448; (3) need for iana registrations
>             ECDH25519 and ECDH448.
>
>             Please bear in mind that the specifications of ECDSA25519
>             and ECDH25519 in the lwig curve document aim to yield
>             schemes that are strictly NIST-compliant (i.e., these
>             would allow FIPS 140-2 accreditation if the curves would
>             be in the "NIST recommended" set). See also Note 2 of
>             Section 4.1 of [1]. A similar remark applies to ECDSA448
>             and ECDH448.
>
>             Detailed feedback:
>
>             Draft NIST SP 800-186 indeed defines a short-Weierstrass
>             version of Curve25519 [dubbed W-25519] and FIPS 186-5
>             allows its use; similar for Curve448 [dubbed W-448
>             there]). I have now added references to these draft
>             specifications in the lwig-curve draft. I have
>             double-checked all domain parameters, mappings between
>             curve models, tables of isogeny details in the lwig draft
>             and provided Sage scripts for the CFRG crypto panel review
>             at the time. I do anticipate that NIST will arrive at the
>             same values in their final publication when they decide to
>             publish this. (I am happy to share Sage scripts for this
>             purpose.)
>
>             ECDSA is determined by an instantiation of hash function,
>             curves, and representation conventions for inputs and
>             outputs (i.e., message representation, curve point
>             representation, and signature representation).
>             a) ECDSA448 uses SHAKE256 under the hood, which is
>             currently not defined with COSE. Hence, my request to
>             register ECDSA w/ SHAKE256 and Wei448 as "ECDSA448".
>             b) ECSA25519 uses SHA256 and Wei25519 under the hood. I
>             thought to request to register "ECDSA25519" since this
>             would allow referencing the quite careful write-up
>             (Section 4.3), including bit/byte ordering, checks, and
>             nondeterministic behavior (and, thereby, keeping this
>             concise). Please note that this is very similar to the
>             COSE IANA registry for "ES256k1" (ECDSA w/ SHA256 and
>             Bitcoin curve secp256k1).
>
>             ECDH25519 and ECDH448 are co-factor Diffie-Hellman key
>             establishment schemes and can, therefore, not be based on
>             (cofactorless) Diffie-Hellman, as defined in RFC 8152.
>             (Please note that there is no difference for the NIST
>             curves, which all of co-factor h=1, but in our case one
>             has h=8 and h=4, respectively). Here, one should note that
>             the ECDH25519 and ECDH448 write-ups (Section 4.1 and 4.3)
>             quite carefully cross-reference co-factor ECDH in a
>             NIST-compliant way. Apart from the co-factor ECDH vs. ECDH
>             issue and objective to comply with all strict NIST
>             validation checks, the objective was also to make sure
>             that ECDH25519 and ECDH448 can be used in settings where
>             either or both parties uses ephemeral keys (which is more
>             flexible than what RFC 8152 allows).  Hence, the request
>             to register "ECDH25519" and "ECDH448", to make sure this
>             covers the intent of these schemes accurately and with
>             precise description.
>
>             It is possible that I overlooked something in this
>             assessment. If so, any constructive suggestions are welcome.
>
>             Ref: [1]
>             https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19
>             <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19>
>
>             Best regards, Rene
>
>                 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.
>
>                 I find it strange that the IANA registration has not
>                 been coordinated with COSE WG at all. I am a bit
>                 surprised to see IANA registrations for
>                 COSE/JOSE/PKIX/CMS at all in a LWIG draft (is that in
>                 charter?). If LWIG wants to register new algorithms, I
>                 think LWIG at a minimum should coordinate with COSE WG
>                 and other groups. I think this draft should be
>                 presented at the next COSE WG meeting.
>
>                 I support registration of W-25519 and W-448 curves as
>                 long they agree with NIST. I would like answers to the
>                 questions why ECDSA25519 and ECDH25519 are needed at
>                 all. There is no ECDSAP256 and no ECDHP256, so why are
>                 specific algorithm registration needed for W-25519? 
>                 It makes no sense to me that a special signature
>                 registration is needed for COSE but not for PKIX? If
>                 PKIX can use ecdsa-with-SHA256 why cannot COSE use ES256?
>
>                 I don't think ANSI X9.62 is an acceptable normative
>                 reference. NIST just removed the normative reference
>                 to ANSI X9.62 in SP 186-5.
>
>                 Cheers,
>
>                 John
>
>                 *From: *COSE <[email-masked]>
>                 <mailto:[email-masked]> on behalf of Rene
>                 Struik <[email-masked]>
>                 <mailto:[email-masked]>
>                 *Date: *Friday, 6 November 2020 at 20:37
>                 *To: *Göran Selander
>                 <goran.selander=[email-masked]>
>                 <mailto:goran.selander=[email-masked]>,
>                 "[email-masked]" <mailto:[email-masked]> <[email-masked]>
>                 <mailto:[email-masked]>, "[email-masked]"
>                 <mailto:[email-masked]> <[email-masked]>
>                 <mailto:[email-masked]>
>                 *Subject: *Re: [COSE]
>                 draft-ietf-lwig-curve-representations-13
>
>                 Hi Goran:
>
>                 - the naming wei25519 has been around since the first
>                 draft (Nov 13, 2017, i.e., 3 years minus 1 week ago),
>                 see [1]. NIST indeed produced two draft documents,
>                 viz. Draft NIST SP 800-186 and Draft FIPS Pub 186-5
>                 (on October 31, 2019), which generated lots of (to my
>                 knowledge still unresolved) comments during public
>                 review. It is hard to refer to that document, since it
>                 is only a draft and unfortunately has quite a few errors.
>
>                 - earlier versions of the lwig draft have received
>                 reviews by the crypto review panel (Stanislavslav
>                 Smyshlyaev), iotdir early-review (Daniel Migault); the
>                 sections on COSE/JOSE code point assignments resulted
>                 from a phone call and various email exchanges with Jim
>                 Schaad; the section on PKIX/CMS was suggested during
>                 IETF Last-Call secdir-review (Russ Housley) and
>                 reviewed by him. The document had IETF Last-Call Aug
>                 24, 2020. See, e.g., the status pages [1].
>
>                 - ECDSA has been around since 1999, has been widely
>                 standardized, and has seen lots of analysis, where
>                 ECDSA25519 is simply yet another instantiation.
>                 Signature generation and verification times for
>                 ECDSA25519 should be similar to those of Ed25519
>                 (since timing is dominated by scalar multiplication,
>                 where one could simply use Montgomery arithmetic [3]).
>                 In my personal view, ECDSA25519 may be more secure
>                 than Ed25519 (if only because it is non-deterministic,
>                 see Security section [6]); similar side-channel care
>                 has to be taken in either case.
>
>                  - As mentioned in the draft, one can easily switch
>                 between Wei25519 and Curve25519 (which requires a
>                 single field addition or subtraction only, i.e.,
>                 <.01%, see Appendix E.2 [7]). As mentioned in the
>                 draft, one could use Wei25519.-3 with an existing
>                 generic implementation that hardcodes the domain
>                 parameter a=-3, but needs to compute an isogeny and
>                 dual isogeny for this (adding 5-10% cost, see Appendix
>                 G.2 [8]]) and a ~9.5kB table (see Section 5.3 [4]).
>                 However, if one already has generic hardware support,
>                 one may still have a significant win (see Section 6 [5]).
>
>                 - The isogeny for Wei25519.-3 has odd degree l=47,
>                 which is co-prime with the order of the curve, so is
>                 in fact invertible. With Wei448.-3, the isogeny has
>                 degree l=2, so is not invertible; however, this does
>                 not really matter, since it is invertible with
>                 correctly generated public-private key pairs (which
>                 have prime/odd order) and the factor two is absorbed
>                 with co-factor ECDH, where h=4 then.
>
>                 I hope this helps.
>
>                 (*) For ease of tracking, it would help if iana
>                 related comments are flagged in the subject line
>                 (e.g., include (iana) in the beginning hereof).
>
>                 Best regards, Rene
>
>                 Ref with hyperlinks:
>
>                 [1]
>                 https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00
>                 <https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00>
>
>                 [2]
>                 https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/
>                 <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/>
>
>                 [3]
>                 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3
>                 <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3>
>
>                 [4]
>                 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-5.3
>                 <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-5.3>
>
>                 [5]
>                 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-6
>                 <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-6>
>
>                 [6]
>                 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-8
>                 <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-8>
>
>                 [7]
>                 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.2
>                 <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.2>
>
>                 [8]
>                 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-G.2
>                 <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-G.2>
>
>                     Apologies for cross-posting LWIG and COSE. I had a
>                     brief look at
>                     draft-ietf-lwig-curve-representations-13 and
>                     noticed it registers a lot of new COSE(andJOSE,
>                     PKIX, and CMS) algorithms. Has this draft been
>                     discussed in COSE(JOSE/CURDLE)? If not, perhaps it
>                     should be before being progressed?
>
>                     1.The draft needs to manage the overlap with NIST
>                     SP 800-186, which should be referenced and
>                     mappings, name of curves, etc. aligned. The draft
>                     defines Wei25519 and Wei448. It is unclear if
>                     these are identical to W-25519, W-448 as defined
>                     in NIST SP 800-186. We probably would not want two
>                     slightly different definitions and/or names,
>                     multiple COSE code points, etc.
>
>                     1.The draft registers the COSE algorithm
>                     "ECDSA25519" as "ECDSA with SHA-256 and curve
>                     Wei25519". That is not how the other COSE
>                     signature algorithms work. They work like PKIX
>                     where the curve is given by the public key. Also,
>                     why cannot W-25519 be used with the existing ES256
>                     signature algorithm?
>
>                     2.The draft registers the COSE algorithm
>                     "ECDH25519". There are no COSE ECDH algorithms for
>                     P-256, why is anECDH algorithm for W-25519 be needed?
>
>                     2.is it described what are the expected security
>                     properties of ECDSA25519(including mapping)
>                     compared to Ed25519? For example w.r.t. side
>                     channel attacks?
>
>                     3.has any performance measurements been made
>                     comparing ECDSA25519 (including mapping) and Ed25519?
>
>                     4.similar questions on security and performance
>                     with Wei25519.-3 instead of Wei25519. If I
>                     understand right, the former mapping is not
>                     reversible, but could benefit from optimized code
>                     with hardcoded domain parameters.
>
>                     5.ANSI X9.62-2005 was withdrawn in 2015 and is
>                     behind a paywall, is this reference necessary?
>
>                     Göran
>
>
>
>
>
>                     [email-masked]  <mailto:[email-masked]>
>
>                     https://www.ietf.org/mailman/listinfo/cose  <https://www.ietf.org/mailman/listinfo/cose>
>
>                 -- 
>
>                 email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>
>             email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>
>         email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>
>     email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Rene Struik <[email-masked]>
Date: Mon, 15 Feb 2021 14:13:15 -0500

Hi John:

I would be eager to have an answer to the question I posed earlier:

    /I could not find the procedure you seemingly had in mind below in
    RFC 8152 (a search in RFC 8152 on the term "email" also did not
    yield this info). Isn't this all described in Section 16.11 [1]? If
    you could point me to what I am apparently missing, please let me know!/

Since you seem to know much more about IETF processes than I do, any 
timely help much appreciated! {I am sure it would also help others more 
verses into technical matters than procedural questions.}

Best regards, Rene

On 2021-02-14 4:56 p.m., Rene Struik wrote:
>     All of the IANA registries established in this document are
>     defined as expert review. This section gives some general
>     guidelines forwhat the experts should be looking for, but they are
>     being designated as experts for a reason, so they should be given
>     substantial latitude.
>
> info). Isn't this all described in Section 16.11 [1]? If you could 
> point me to what I am apparently missing, please let me know!
>
> In all fairness, I think you would have to agree that I did reach out 
> to the relevant actors at the time, in good conscience, in a timely 
> manner (in contrast to the language you used in your forelast email).
>
> Best regards, Rene
>
>> mailing list commenting and asking about the COSE registrations. I 
>> and several other people in COSE WG seem to share Göran’s concerns. 
>> You cannot expect COSE WG to read your draft before somebody send it 
>> to the list. If I had written the draft I would personally had sent 
>> in to COSE a long time ago. I wish someone would have helped you with 
>> that.
>>
>>     - iana/cose section has been in there since April 14, 2019 (v04
>>     of the draft). See
>>     been narrowed down (as I repeatedly suggested offline and which
>>     is good engineering practice). Please note that even something as
>>         more than two months after the
>>
>>         >IETF Last-Call.
>>
>>         discuss these registrations with the dedicated IANA experts
>>         or the COSE WG beforehand. The suggested COSE registration
>>         are quite strange. Any delay is purely due to you not
>>         discussing and anchoring these registrations. I have
>>         suggested that that this issue is discussed at the interim on
>>         Tuesday, but it is not my job to drive your registrations. I
>>         am just commenting on the questions from the dedicated IANA
>>         experts.
>>
>>         You can always remove the COSE registrations, but I think
>>         that would be sad. I agree with you that a registration for
>>         <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>>         (Dec 19th) works for you. If you have comments, please
>>         suggest constructive improvements.
>>
>>             Your review below (of Nov 6, 2020) seems to bring up
>>             three topics, viz.: (1) definition of Wei25519 and Wei448
>>             vs. verbiage in NIST docs; (2) need for iana
>>             registrations for ECDSA25519 and ECDSA448; (3) need for
>>             iana registrations ECDH25519 and ECDH448.
>>
>>             and provided Sage scripts for the CFRG crypto panel
>>             review at the time. I do anticipate that NIST will arrive
>>             at the same values in their final publication when they
>>             decide to publish this. (I am happy to share Sage scripts
>>             for this purpose.)
>>
>>             has h=8 and h=4, respectively). Here, one should note
>>             that the ECDH25519 and ECDH448 write-ups (Section 4.1 and
>>             4.3) quite carefully cross-reference co-factor ECDH in a
>>             NIST-compliant way. Apart from the co-factor ECDH vs.
>>             ECDH issue and objective to comply with all strict NIST
>>                 will bring up this draft for discussion in the LAKE
>>                 WG at IETF 109.
>>
>>                 charter?). If LWIG wants to register new algorithms,
>>                 I think LWIG at a minimum should coordinate with COSE
>>                 WG and other groups. I think this draft should be
>>                 long they agree with NIST. I would like answers to
>>                 the questions why ECDSA25519 and ECDH25519 are needed
>>                 at all. There is no ECDSAP256 and no ECDHP256, so why
>>                 are specific algorithm registration needed for
>>                 W-25519?  It makes no sense to me that a special
>>                 signature registration is needed for COSE but not for
>>                 PKIX? If PKIX can use ecdsa-with-SHA256 why cannot
>>                 COSE use ES256?
>>
>>                 "[email-masked]" <mailto:[email-masked]>
>>                 <[email-masked]> <mailto:[email-masked]>,
>>                 "[email-masked]" <mailto:[email-masked]>
>>                 review. It is hard to refer to that document, since
>>                 it is only a draft and unfortunately has quite a few
>>                 errors.
>>
>>                 Smyshlyaev), iotdir early-review (Daniel Migault);
>>                 the sections on COSE/JOSE code point assignments
>>                 resulted from a phone call and various email
>>                 exchanges with Jim Schaad; the section on PKIX/CMS
>>                 was suggested during IETF Last-Call secdir-review
>>                 (Russ Housley) and reviewed by him. The document had
>>                 IETF Last-Call Aug 24, 2020. See, e.g., the status
>>                 pages [1].
>>
>>                 where one could simply use Montgomery arithmetic
>>                 [3]). In my personal view, ECDSA25519 may be more
>>                 secure than Ed25519 (if only because it is
>>                 non-deterministic, see Security section [6]); similar
>>                 side-channel care has to be taken in either case.
>>
>>                 dual isogeny for this (adding 5-10% cost, see
>>                 Appendix G.2 [8]]) and a ~9.5kB table (see Section
>>                 5.3 [4]). However, if one already has generic
>>                 hardware support, one may still have a significant
>>                 win (see Section 6 [5]).
>>
>>                     Apologies for cross-posting LWIG and COSE. I had
>>                     a brief look at
>>                     discussed in COSE(JOSE/CURDLE)? If not, perhaps
>>                     it should be before being progressed?
>>
>>                     in NIST SP 800-186. We probably would not want
>>                     two slightly different definitions and/or names,
>>                     why cannot W-25519 be used with the existing
>>                     ES256 signature algorithm?
>>
>>                     "ECDH25519". There are no COSE ECDH algorithms
>>                     for P-256, why is anECDH algorithm for W-25519 be
>>                     needed?
>>
> email:[email-masked]  | Skype: rstruik

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 15 Feb 2021 11:17:59 -0800

Hi Rene,

Section 16.11 discusses what the IANA Designated Experts should do upon
receipt of a registration request, which is a distinct step from what
someone making a registration request of IANA should do.

I further note that the final bullet of the section says that "Algorithms
that do not meet the security requirements of the community and the
messages structures should not be registered"; it seems natural to me that
a Designated Expert would choose to consult the COSE WG email list in order
to get feedback from the community.

-Ben

> [email-masked]

---

From: Rene Struik <[email-masked]>
Date: Mon, 15 Feb 2021 14:31:01 -0500

Questions/point of information:
a) where is the distinct step for "someone making a registration request 
of iana" described?
b) which algorithms for which I requested iana cose code points do not 
meet the security requirements?
c) which message structure requirements for said requested code points 
are not met?

{here, message structure refers to syntax, whereas security also deals 
with robust security properties}

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 15 Feb 2021 12:08:58 -0800

Hi Rene,

My understanding is that for the registration requests contained in
draft-ietf-lwig-curve-representations, the IANA registration request
process was implicitly started by the IETF Last Call announcement.  It
would also be possible to request assignment in the COSE registries via the
general assignments form linked from https://www.iana.org/protocols/apply .

Since I am currently in the process of performing my own IESG Evaluation of
the draft, I will not comment on (b).  My understanding is that for (c),
the various COSE message structures (e.g., COSE_Sign) include an
'alg'orithm parameter that determins the rest of the processing of the
message.  The various algorithms (e.g., ECDSA) in turn are used with
specific keys, and a given (EC) key will indicate the curve that it is on.
The ECDSA algorithm codepoints are associated with the ECDSA signature
algorithm and a hash function to pre-digest the signature input, and the
curve to use is dependent on the specific key.

In particular, the signature algorithm does *not* also specify a curve
(since the key is supposed to specify the curve), with the sole exception
of ES256K.  ES256K, in turn, is a special case due to (1) the desire to
limit the use of the curve in COSE to just the legacy case for
compatibility with existing signing hardware, and (2) the scope of risk due
to misinterpreting secp256k1 points with secp256r1 points.

So, I would say that the attempt to specify a new ECDSA25519 signature
algorithm that is specific to the curve Wei25519 is not consistent with the
existing structure requirements for COSE signature algorithms; the existing
ES256 signature algorithm can easily be applied to keys on a new Wei25519
curve type, without limiting the signature algorithm to the single curve.
As far as I know, no exceptional circumstances akin to the ES256K case have
been presented that would justify a deviation from the existing practices.

-Ben

P.S. It also seems weird to me that the proposed Wei25519 registration
allows both EC2 and OKP key types; the curves listed in
draft-ietf-cose-rfc8152bis-algs all have a single key type for each curve.
But I only just noticed that as I went to write this mail and haven't
finished reviewing that part of the draft yet...

---

From: Rene Struik <[email-masked]>
Date: Tue, 16 Feb 2021 11:50:01 -0500

Hi Ben:

I am interested in getting a carefully crafted technical document out of 
the door. The only area where I needed to get external ietf help with 
was the iana section, for which I reached out to the designated iana 
expert of the time (Jim Schaad), where we quickly reached consensus over 
the phone and a few email exchanges. The last change to this was April 
2020, almost a year ago.

The iana cose "bickering" is about the value of 6 one-word character 
strings, in an otherwise quite voluminous, since 137 pages, document, 
where the value could be "new" or "reuse existing" (i.e., at most six 
bits of entropy). The current iana cose request may not be perfect. If 
it requires improvement, I can write some text to accommodate this *in 
parallel* to the IESG review.

What has to stop is the political posturing, which is not productive. I 
have been trying to chase people who volunteered to serve the ietf in 
various capacities for months now, but have trouble seeing the "serve" 
element in their roles come to fruition.

If reusing existing RFC 8152 text was so easy, why is co-factor ECDH and 
the unwisdom of deterministic ECDSA policy advice then suddenly on the 
menu? I think these topics are not uncorrelated. Please note that 
writing the iana pkix/cms section was easy, so perhaps one should 
reflect on what makes it easy or hard to reuse things or make progress.

Let us all look in the mirror and see whether we like what we see. We 
are supposed to be a community of technical people who want to 
collaborate to get something done, so let us act this way.

Rene