RE: [W3C Web Crypto WG] status on bug 25618 related to NUMS/25519 curves and proposed way forward

Mike, and all,

I meant to express what Brian mentioned in our previous call
=== Extract
BAL: I want to make everyone in the WG aware that this was the topic of extensive discussion at last week's IETF
... both NUMS, 25519, and others at higher level
... No resolution yet from CFRG
... Requirements-gathering for a few more weeks, then 4-week comment period
... When I wrote the doc, I put in 6 curves
... There does not seem to be much interest in the Weirstrass curves, more interest in the performant versions
... If I were rewriting it now, I'd probably include only twisted-Edwards
... prefer to see a non-NIST optiom in the main spec

I should have said
Option 1 : integration of NUMS curve as an extension to the Web Crypto API specification, based on what was proposed by Brian LaMacchia (potentially only keeping twisted Edwards ones)

Virginie

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: lundi 11 août 2014 17:12
To: GALINDO Virginie; public-webcrypto@w3.org
Cc: Harry Halpin; webcrypto@trevp.net
Subject: RE: [W3C Web Crypto WG] status on bug 25618 related to NUMS/25519 curves and proposed way forward

I vehemently disagree with the “potentially removing NIST curves” possibility.  These are standards and are used in practice in many application areas.  We need to leave them in (as well as provide extension points so other algorithms can also be used with WebCrypto as they are developed).

I don’t have a problem with extension specs being written for either NUMS or 25519.  In fact, it would be good to have these written before we’re done, as they will test parts of our extension mechanisms in the main spec.

                                                            -- Mike

From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com]
Sent: Monday, August 11, 2014 3:02 AM
To: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Cc: Harry Halpin; webcrypto@trevp.net<mailto:webcrypto@trevp.net>
Subject: [W3C Web Crypto WG] status on bug 25618 related to NUMS/25519 curves and proposed way forward

Dear all,

A status on the bug 259839 related to integration of NUMS and 25519 curves in our deliverables : https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839


There were some discussions about the possible options to move forward to integrate the new curves (see below).
Here is again the possible options for each of the curves. Note that by extension, we mean here a specification, which has its own Recommendation Track and that will be following the W3C Recommendation process.


•         Dealing with NUMS curves
Algorithm description is attached to http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0041.html , editor Brian LaMacchia.
Note : that contribution was submitted on time to be considered by the WG as included in our deliverable [1].
Option 1 : integration of NUMS curve as an extension to the Web Crypto API specification, based on what was proposed by Brian LaMacchia (potentially removing NIST curves)
Option 2 : agreement as a principle to integrate the NUMS curves into the WG deliverables, but expect Candidate Recommendation to make decision to integrate the algorithm in the main spec or as an extension, final set of algorithm would align with IETF/CFRG recommendations for TLS deployment
Option 3 :  integration of NUMS Non-NIST curves in the main spec as a feature at risk and remove it at Candidate Recommendation, if it happens that no interoperable implementation is demonstrated.



•         Dealing with Curve25519
Algorithm description http://htmlpreview.github.io/?https://github.com/trevp/curve25519_webcrypto/blob/master/Curve25519_WebCrypto.html, editor Trevor.
Note : that contribution was submitted lately to the WG.
Option 1 : integration of curve 25519 as an extension to the Web Crypto API specification based on what was proposed by Trevor Perrin
Option 2 : agreement as a principle to integrate the curve25519 curves into the WG deliverables, but expect Candidate Recommendation to make decision to integrate the algorithm in the main spec or as an extension, taking into account IETF/CFRG recommendations for TLS deployment
Option 2 : integration of curve25519 in the main spec as a feature at risk, and remove it at Candidate Recommendation, if it happens hat no interoperable implementation is demonstrated.

I have the feeling that the WG consensus would be to go for *NUMS curve option 1* and *Curve 25519 option 1*, based on feedback I heard (see below).
Anyone unhappy with that possible way to move forward ?
Anyone having another idea ?
(again a formal call for consensus will be made this week, but I am trying to test options acceptance, and alternatives).

Regards,
Virginie

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839#c39




From: Brian LaMacchia [mailto:bal@microsoft.com]
Sent: mardi 5 août 2014 04:16
To: Richard Barnes; GALINDO Virginie
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>; Harry Halpin
Subject: RE: W3C Web Crypto WG - about the NUMS/25519 curves integration in Web Crypto API

No, your point (b) below is not quite correct.  Since no Curve25519 proposal was received by the deadline set by Virginie, Curve25519 is off the table for consideration for the main spec and would have to be presented in an extension spec.  However, the WG has not yet made a decision about whether the NUMS curves would go into the main spec or an extension spec – that’s been pushed out to the next call (along with other issues).

                                                                                --bal

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Monday, August 4, 2014 3:02 PM
To: GALINDO Virginie
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>; Harry Halpin
Subject: Re: W3C Web Crypto WG - about the NUMS/25519 curves integration in Web Crypto API

I'm still catching up on the thread, but I think I'm generally on the same page as Ryan here.

I thought that we came out of our last call with pretty clear agreement that (a) the base spec needs to have sufficient extension points to support whatever comes out of IETF/CFRG, and (b) any WebCrypto support for new curves would be implemented using those extension points, *not* in the main spec.

As to all this worry that TLS/CFRG will not come to resolution, I estimate that probability to be quite small.  There is good momentum for *some* decision to be made there.  So I would oppose any complications to W3C process to hedge against that.

--Richard



On Mon, Aug 4, 2014 at 4:25 PM, GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>> wrote:
Any other opinion from WG participants ?
Virginie

---- Harry Halpin a écrit ----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/04/2014 09:44 PM, Ryan Sleevi wrote:
> Will happily endorse Option 1 (separate spec), but would object to
> Harry's option / any options that promote Feature at Risk / main
> spec inclusion.
>
> I don't feel there has been significant review from the
> cryptographic community or from implementors to make any reasonable
> assessments about NUMS, either in implementation or in API surface,
> thus would not want to include on the main track. I think features
> at risk are a copout that tries to kick decision making down the
> curb until inertia wins, and do a disservice to everyone. We should
> not be throwing everything into a spec with the label "At Risk"at
> this point - that is, at best, poor leadership from the W3C, and at
> worst, detrimental towards security and the viability of the spec.
> The only reason this was done with respect to the algorithms
> selected was due to the incredibly limited feedback from the WG,
> particularly UAs, on the shape of the API, and thus was necessary
> to reverse engineer the shape, as it were.

Note again it's that it's not letting inertia win. It's letting the
CFRG and TLS WG decide, and then a proposal that we include that TBD
non-NIST curve in the main spec.

As noted by BAL and Wendy, these groups have a schedule and lots of
active discussion. Since their schedule may slip, we should have a
final deadline for ourselves. That deadline I specified was out was
our exit from CR.

I think we all understand that you do not want a non-NIST ECC curve in
the spec. However, there seems to be a vocal group of developers and
at least one browser vendor that does want this, so we need to reach
some sort of consensus to resolve their concerns and exit Last Call,
while recognizing the validity of your concerns about whether or not
any non-ECC curve is specified well enough to be widely implemented. I
believe the CFRG and TLS WG could make that decision.

> On Aug 4, 2014 12:31 PM, "GALINDO Virginie"
> <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>> wrote:
>
>> Harry,
>>
>> Thanks for reminder about non-NIST curves mentionned by Brian. I
>> understand that your proposal is a new option.
>>
>> Lets call it OPTION 3 : we can decide to integrate Non-NIST
>> curves ( because we bet on their attractivity for IETF) in the
>> main specification,  with a mention 'feature at risk', and we
>> drop it if it happens that there is no implementation nor
>> requirement from IETF.
>>
>> To all, What I am trying to get is a direction where the WG want
>> to go. I dont want to enter into the details of the way the
>> option 1 or 2 or 3 will be implemented. So please state your
>> favorite option, the one you could live with, the one you would
>> object to. This is an informal vote, take it as a mean to prepare
>> consensus...
>>
>> Virginie
>>
>>
>> Copying other options as a reminder OPTION 1 : - We can decide to
>> have an extension for NUMS and already have an editor for it - We
>> can decide to have an extension for curves 25519 and have a
>> potential draft with an editor coming on 10th of august - We can
>> decide to have that/those extension(s) mandatory in the future
>> browser profile Or OPTION 2 : - We can decide ‘not to choose
>> between extension and main spec’ but decide on the principle to
>> develop the NUMS/curve 25519 descriptions and put it into the
>> spec once it is tested and proven it is available
>>
>>
>> ---- Ryan Sleevi a écrit ----
>>
>>
>>
>> On Aug 4, 2014 9:00 AM, "Harry Halpin" <hhalpin@w3.org<mailto:hhalpin@w3.org>> wrote:
>>>
>
>
> On 08/04/2014 05:52 PM, Ryan Sleevi wrote:
>>>>> Harry,
>>>>>
>>>>> Is this an official endorsement of a third proposal? It
>>>>> seemed that for the entirity of discussion, it has
>>>>> specifically been two proposals, precisely so that we could
>>>>> avoid your third proposal.
>
> This is an argument for Virginie's third proposal and a way to
> operationalize it.
>
> "We can decide ‘not to choose between extension and main spec’ but
> decide on the principle to develop the NUMS/curve 25519
> descriptions and put it into the spec once it is tested and
> proven"
>
> It seemed to reflect the sentiment in the last telecon that while
> BAL has provided text for NUMS and Trevor has promised 25519 text,
> deciding now might be a bad idea as though it was pretty clear that
> at least one non-NIST curve would be recommended by TLS/CFRG
> eventually, it was unclear about the timeline or which precise
> curve.
>
> Again, it's easy to add "features at risk" and take them out
> sensibly if the decision by TLS/CFRG never resolves. It seems as if
> it does resolve, it would be a good idea to keep open the
> possibility of adding that TBD non-NIST curve in the spec without
> going back to Last Call.
>>>
>>> OK. I don't think this proposal is practical nor realistic, in
>>> as much as it fails to address the issues, and presumes a
>>> non-trivial amount of editing work at some later point that
>>> will meaningfully alter the spec in surprising ways, but sure,
>>> at least it's out there.
>>>
>
> I've added suggestions on the monkey-patching bug to
> operationalize how we can deal with extension specs formally in the
> spec.
>
> cheers, harry
>
>
>
>>>>> On Aug 4, 2014 7:14 AM, "Harry Halpin" <hhalpin@w3.org<mailto:hhalpin@w3.org>>
>>>>> wrote:
>>>>>
>>>>> The problem, as BAL pointed on the call, is that we do
>>>>> *not* have resolution on a single curve from TLS or CFRG.
>>>>> It is unclear when those decisions will be made, although a
>>>>> decision is likely I would say before we exist CR. However,
>>>>> chosing between NUMS and 25519 may be premature
>>>>> optimization at this point. Nonetheless, as BAL noted on
>>>>> the call and was backed up on the Bugzilla, there is a real
>>>>> demand for non-NIST ECC curve support in Web Crypto.
>>>>>
>>>>> In general, in W3C process it is *more* difficult to add
>>>>> features than to subtract them when going into CR. Thus,
>>>>> the "feature at risk" mechanism.
>>>>>
>>>>> So, I'd like to add another proposal.  I suggest that we
>>>>> simply add a "feature at risk", using a modification of
>>>>> BAL's edits, for a "TBD non-NIST" curve in the main spec.
>>>>> This TBD curve, if not resolved and supported by CFRG/TLS
>>>>> by the time we exit from CR, is then to be removed from the
>>>>> main spec. If it is later resolved after we have exited CR,
>>>>> then we propose to add these curves using the standard
>>>>> extension mechanism.
>>>>>
>>>>> cheers, harry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 08/04/2014 03:40 PM, GALINDO Virginie wrote:
>>>>>>>> Hello Web Crypto participants,
>>>>>>>>
>>>>>>>> Following our call last week [1], I have listed the
>>>>>>>> different ideas/directions that were raised about the
>>>>>>>> way to proceed on the integration of NUMS and 25519
>>>>>>>> curves, as discussed in bug
>>>>>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

>>>>>>>>
>>>>>>>> ** Two possible options to handle NUMS and 25519
>>>>>>>> curves integration OPTION 1 : - We can decide to have
>>>>>>>> an extension for NUMS and already have an editor for
>>>>>>>> it - We can decide to have an extension for curves
>>>>>>>> 25519 and have a potential draft with an editor
>>>>>>>> coming on 10th of august - We can decide to have
>>>>>>>> that/those extension(s) mandatory in the future
>>>>>>>> browser profile Or OPTION 2 : - We can decide ‘not to
>>>>>>>> choose between extension and main spec’ but decide on
>>>>>>>> the principle to develop the NUMS/curve 25519
>>>>>>>> descriptions and put it into the spec once it is
>>>>>>>> tested and proven it is available
>>>>>>>>
>>>>>>>> ** Other requirements : - We have to stay
>>>>>>>> synchronized with IETF/CFRG - TLS requirements, which
>>>>>>>> may require new algorithms → this is in favor of
>>>>>>>> delaying the decision, expecting IETF decision -
>>>>>>>> Learning loop : We have to decide how to make our
>>>>>>>> spec extensible → this is favor to make early choice
>>>>>>>> and beta test extension addition
>>>>>>>>
>>>>>>>> I would like to have your views on the preferred path
>>>>>>>> to progress, option 1 or option 2. If you have
>>>>>>>> another option, feel free to suggest.
>>>>>>>>
>>>>>>>> Note that we have a call scheduled next Monday 11th
>>>>>>>> of August to discuss that question, but early opinion
>>>>>>>> are helping to make calls efficient.
>>>>>>>>
>>>>>>>> Regards, Virginie Chair of the web crypto WG
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>> http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0144.html

>>>>>>>>
>>>>>>>>
>>>>>>>>
>
>>>
(please ignore statement below)
>>>>>>>>
>>>>>>>> ________________________________ This message and
>>>>>>>> any attachments are intended solely for the
>>>>>>>> addressees and may contain confidential information.
>>>>>>>> Any unauthorized use or disclosure, either whole or
>>>>>>>> partial, is prohibited. E-mails are susceptible to
>>>>>>>> alteration. Our company shall not be liable for the
>>>>>>>> message if altered, changed or falsified. If you are
>>>>>>>> not the intended recipient of this message, please
>>>>>>>> delete it and notify the sender. Although all
>>>>>>>> reasonable efforts have been made to keep this
>>>>>>>> transmission free from viruses, the sender will not
>>>>>>>> be liable for damages caused by a transmitted virus.
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>> ------------------------------ This message and any attachments
>> are intended solely for the addressees and may contain
>> confidential information. Any unauthorized use or disclosure,
>> either whole or partial, is prohibited. E-mails are susceptible
>> to alteration. Our company shall not be liable for the message if
>> altered, changed or falsified. If you are not the intended
>> recipient of this message, please delete it and notify the
>> sender. Although all reasonable efforts have been made to keep
>> this transmission free from viruses, the sender will not be
>> liable for damages caused by a transmitted virus.
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


iQIcBAEBAgAGBQJT3+WRAAoJEPgwUoSfMzqcFDYP/RIelB1EOPTNKdtdanNZoWHU
bFCqa+78zVxlxIip/6T9jhdT62LRzAWFxzojjEng2FdCHbdPTGsyeVIdN4N8VHbS
MopwEYHUiGjzD4VKcd6ob9OEd+Pyp0Uzl6PwJXlUysnbsCrJkHd7OKTebBIcFppL
/6cXm9ViILc1Zx1lfnDJ0NotlKeV+KaLxSG8DMKVIwpCObVA4hXqceG7d/5KJZ89
SlSdH+GgTZDUwj5UAnSAmpE2A0cIoQpu9B2FCLCTYXjx4TLmfk7InX08MNIXlDbP
4wBaQe5WxersnAClXzU9vmNy4ipABNH+rQPo+l8nvymOWNO6g/pY9fTbRjRpjDNF
V/5gZQwBV1VNCtGiT+1rMXsRdIE7Rxo2xu0e3lDz0JjrZul0WXKXQZpzkvASH8+c
ZNF4Mb1Y58TU+cP/Ia9FBgX+LiBkDQ+S3jaCZtyDFR20AwYMw/Kq0WWI3OZWrkZo
sqgs69uvr6HACzbjdZNAvb2/KAejHlOI3f5Hi/eP2fipOFs4PQboyBIF6jr6KC1R
h65r5gbqt9sRt1MComODq9/qak1wk2djBfN8d6tttLZ2G17smaQldt6Ho69DleRy
w/Jdbbyw0TYhbXK023WcsWTOlM0/B17Cs+LKVz2U7cP+84dP5z8Dt3zKnT/Sp6Rg
LoRtGyPMzuomn8OG5b2f
=dhOJ
-----END PGP SIGNATURE-----

________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.