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 protected]>
*Date: *Sunday, 14 February 2021 at 20:11
*To: *John Mattsson <[email protected]>, Göran Selander
<[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>
*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/>
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/
<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 protected]>
<mailto:[email protected]>
*Date: *Wednesday, 13 January 2021 at 15:26
*To: *John Mattsson <[email protected]>
<mailto:[email protected]>, Göran Selander
<[email protected]>
<mailto:[email protected]>,
"[email protected]" <mailto:[email protected]> <[email protected]>
<mailto:[email protected]>, "[email protected]"
<mailto:[email protected]> <[email protected]> <mailto:[email protected]>
*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 <[email protected]>
<mailto:[email protected]> on behalf of Rene
Struik <[email protected]>
<mailto:[email protected]>
*Date: *Friday, 6 November 2020 at 20:37
*To: *Göran Selander
<[email protected]>
<mailto:[email protected]>,
"[email protected]" <mailto:[email protected]>
<[email protected]> <mailto:[email protected]>,
"[email protected]" <mailto:[email protected]>
<[email protected]> <mailto:[email protected]>
*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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
<https://www.ietf.org/mailman/listinfo/cose>
--
email:[email protected] <mailto:[email protected]> |
Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
-->
--
email:[email protected] <mailto:[email protected]> |
Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
email:[email protected] <mailto:[email protected]> | Skype:
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
email:[email protected] <mailto:[email protected]> | Skype:
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
email:[email protected] <mailto:[email protected]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
