[COSE] (small timeline correction) Re: draft-ietf-lwig-curve-representations-13

[Rene Struik <[e-mail]>]

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 <[e-mail]>
>> *Date: *Wednesday, 13 January 2021 at 15:26
>> *To: *John Mattsson <[e-mail]>, Göran Selander 
>> <goran.selander=[e-mail]>, "[e-mail]" 
>> <[e-mail]>, "[e-mail]" <[e-mail]>
>> *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
>>     <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 <[e-mail]>
>>         <mailto:[e-mail]> on behalf of Rene Struik
>>         <[e-mail]> <mailto:[e-mail]>
>>         *Date: *Friday, 6 November 2020 at 20:37
>>         *To: *Göran Selander
>>         <goran.selander=[e-mail]>
>>         <mailto:goran.selander=[e-mail]>,
>>         "[e-mail]" <mailto:[e-mail]> <[e-mail]>
>>         <mailto:[e-mail]>, "[e-mail]"
>>         <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>>         *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
>>         <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>
>>
>>         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(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?
>>
>>             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
>>
>>             [e-mail]  <mailto:[e-mail]>
>>
>>             https://www.ietf.org/mailman/listinfo/cose  <https://www.ietf.org/mailman/listinfo/cose>
>>
>>         -- 
>>
>>         email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>>
>>         cell: [phone] | US: [phone]
>>
>>         -->
>>
>>     -- 
>>
>>     email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>>
>>     cell: [phone] | US: [phone]
>>
>> -- 
>> email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>> cell: [phone] | US: [phone]
>
>
> -- 
> email:[e-mail]  | Skype: rstruik
> cell: [phone] | US: [phone]


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]