Re: [W3C Web Crypto WG] CfC : Call for Consensus on the integration of curve25519 in WG deliverables (please vote until the 26th of August)

On Tue, Aug 26, 2014 at 6:02 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  I *vehemently* oppose removing the EC and ECDH algorithms.  Virginie
> took that off the table during the last call.  Therefore, please don’t try
> to bring that idea back up.
>

It's true that it was mentioned and then not further considered but ​I
don't recall any consensus to dismiss this idea. ​


>
> Removing these commonly used algorithms would needlessly make our spec
> less useful.
>

​The specification is not going to be much use at all if it doesn't
progress.

It doesn't seem to me that the document (b) proposed below will be
completed any later than a combined specification.

So all opposing this approach appears to achieve is to deny progress to the
rest of the specification, which could advance sooner if it was freed of
this controversial aspect.

As Ryan says, the essential part of the WebCrypto specification is the
machinery that provides the methods and framework for accessing algorithms.
We then have a bag of algorithms that will be extended over time. I don't
see that whether an algorithm is in the main specification or a future one
holds much significance, but it seems to make some people happy if the NIST
curves are not added before non-NIST curves.

...Mark



>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Tuesday, August 26, 2014 5:58 PM
> *To:* Harry Halpin
> *Cc:* Ryan Sleevi; GALINDO Virginie; public-webcrypto@w3.org;
> webcrypto@trevp.net; Wendy Seltzer
> *Subject:* Re: [W3C Web Crypto WG] CfC : Call for Consensus on the
> integration of curve25519 in WG deliverables (please vote until the 26th of
> August)
>
>
>
> Ok, so unless I am mistaken, at least the Ryan, Harry and I could agree to:
>
>
>
> a) Remove EC and ECDH algorithms from the main specification,
>
> b) Start work on a new specification that defines EC and ECDH algorithms
> including NIST curves and whatever other curves the WebCrypto group agrees
> on (likely based on CFRG discussions), and
>
> c) Timeframes for the two specifications are not linked (except that (a)
> should not be later than (b), obviously).
>
>
>
> Timeframes for (b), which curves would be included and whether they would
> be within the EC, ECDH algorithms or separate algorithms (or different
> approaches for different curves) would remain open issues, but they would
> not hold up progression of the main specification.
>
>
>
> We could additionally attempt to gain consensus for the idea that the
> purpose of the above is to enable the inclusion of non-NIST curves in (b).
> Such an agreement can't be given an teeth though, since we can't constrain
> the future Working Group in terms of what it does / does not decide to
> publish. For example, if six months passes and we don't have consensus on
> solid WebCrypto text for non-NIST curves, the group might not want to
> continue to delay the NIST curves. We'd basically be recording a "good
> faith intention", no more.
>
>
>
> ...Mark
>
>
>
>
>
>
>
>
>
> ...Mark
>
>
>
> On Tue, Aug 26, 2014 at 5:27 PM, Harry Halpin <hhalpin@w3.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   On 08/27/2014 02:18 AM, Ryan Sleevi wrote:
> > On Tue, Aug 26, 2014 at 5:16 PM, Harry Halpin <hhalpin@w3.org>
> > wrote:
> >
> >
> >
>
> > On 08/27/2014 02:03 AM, Ryan Sleevi wrote:
> >>>> On Tue, Aug 26, 2014 at 4:57 PM, Harry Halpin
> >>>> <hhalpin@w3.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 08/26/2014 08:39 PM, Ryan Sleevi wrote:
> >>>>>>> On Tue, Aug 26, 2014 at 4:34 AM, Harry Halpin
> >>>>>>> <hhalpin@w3.org> wrote:
> >>>>>>>
> >>>>>>> My opinion is the same as Richard insofar as"We should
> >>>>>>> agree on the principle that we will support the next
> >>>>>>> generation curves that CFRG and TLS agree on, and work
> >>>>>>> to support that once it's decided." But we need to
> >>>>>>> operationalize what we mean by "support".
> >>>>>>>
> >>>>>>> The choices are having that curve in the *extension
> >>>>>>> specs* versus *main spec*.  Given that all major
> >>>>>>> browser vendors I know of will implement the
> >>>>>>> recommended set of curves from CFRG to TLS and so
> >>>>>>> exposing those to WebCrypto makes sense - and given the
> >>>>>>> liaison relationship between the IETF and W3C and our
> >>>>>>> commitment to harmonize as much as possible our specs -
> >>>>>>> it seems that that those recommended curves should be
> >>>>>>> in the main spec text.
> >>>>>>>
> >>>>>>>
> >>>>>>>> I strongly disagree with this, as it ignores quite a
> >>>>>>>> bit about how both browsers and standards work.
> >>>>>>>
> >>>>>>>> Consider that TLS 1.2 was not implemented for years
> >>>>>>>> after it was standardized. Consider that the CFRG
> >>>>>>>> recommendation will be for TLS 1.3, which is
> >>>> growing
> >>>>>>>> in considerable complexity.
> >>>>>>>
> >>>>>>>> Harry, just because a spec (which itself will have
> >>>>>>>> it's own timeline for review and discussion, and may
> >>>>>>>> change at any point) adopts something is
> >>>> not
> >>>>>>>> an argument, at all, for an entirely unrelated spec
> >>>>>>>> to do so.
> >>>>>>>
> >>>>>>>
> >>>>>>> Given that extensibility is still a bit blurry, it's
> >>>>>>> hard to claim we have a good solution for extension
> >>>>>>> specs quite yet. However, I also agree we can't wait
> >>>>>>> around forever for CFRG.
> >>>>>>>
> >>>>>>>
> >>>>>>>> Which is precisely what extension specs are for. We
> >>>>>>>> didn't sit on CSS1 while waiting for VRML or WebGL to
> >>>>>>>> come along.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> This in mind, we can move forward by either:
> >>>>>>>
> >>>>>>> 1) Have a "placeholder" text for it as a "Feature at
> >>>>>>> Risk". The NUMS text could be that placeholder, with a
> >>>>>>> note saying that this may be removed/changed if
> >>>>>>> TLS/CFRG do not recommend NUMS.
> >>>>>>>
> >>>>>>>
> >>>>>>>> This is unacceptable. Placeholders in specs,
> >>>>>>>> particularly ones that
> >>>> favour
> >>>>>>>> any particular solution during ACTIVE DISCUSSION,
> >>>>>>>> are simply grossly inappropriate, especially for a
> >>>>>>>> spec at the maturity of Web Crypto, compared to the
> >>>>>>>> maturity of the discussions going on.
> >>>>>>>
> >>>>>>>> So that it's clear that it's not NUMS specific, the
> >>>>>>>> objection is to
> >>>> ADDING
> >>>>>>>> any new features that are "FEATURES AT RISK".
> >>>>>>>> Anything, including
> >>>> anything
> >>>>>>>> in the spec today, that we believe is still a
> >>>>>>>> "feature at risk" is something we should be actively
> >>>>>>>> working towards moving to an extension
> >>>> spec.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> and/or
> >>>>>>>
> >>>>>>> 2) Go back to "Last Call" and add the recommended
> >>>>>>> non-NIST curve in later in the main spec text.
> >>>>>>>
> >>>>>>>
> >>>>>>>> Or 3), what's been said all along, which is "Add new
> >>>>>>>> curves as they
> >>>> become
> >>>>>>>> available, both in specification and implementation,
> >>>>>>>> and UAs are
> >>>> confident
> >>>>>>>> in the maturity such that they're willing to expose
> >>>>>>>> and support as an indefinite part of the Web
> >>>>>>>> platform"
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> I see no harm in either of these proposals and think
> >>>>>>> either would satisfy the problem. It's not as simple as
> >>>>>>> adding in NUMS or not. What we need is a commitment to
> >>>>>>> support whatever TLS/CFRG recommend.
> >>>>>>>
> >>>>>>> If TLS/CFRG do *not* recommend a set of non-NIST curves
> >>>>>>> by the necessary timeline for WebCrypto (i.e. getting
> >>>>>>> out of CR by end of the year), in the first case we
> >>>>>>> simply drop the "Feature at Risk" and in the second
> >>>>>>> case we simply do not go back to "Last Call" but
> >>>>>>> progress to Rec as normal.
> >>>>>>>
> >>>>>>>
> >>>>>>>> Frankly, a spec intentionally placing something that
> >>>>>>>> is unimplementable
> >>>> AND
> >>>>>>>> unspecifiable ("a placeholder") is unacceptable. A
> >>>>>>>> spec intentionally placing something that is known as
> >>>>>>>> "something we're probably going to rip out" - whether
> >>>>>>>> it be Curve25519 or NUMS - is unacceptable.
> >>>>
> >>>> However, it appears that simply ignoring the issue of
> >>>> non-NIST curves in the main text spec is also unacceptable to
> >>>> Microsoft and a good deal of real-world developers. So let's
> >>>> find a reasonable position we can all agree on that shows
> >>>> that we have a firm commitment to non-NIST curves but allows
> >>>> us to continue progress.
> >>>>
> >>>> My proposal is that the WebCrypto WG make a firm commit to
> >>>> honor the desire for a non-NIST curve in the main spec text
> >>>> *regardless* of our internal timing for transition to Rec.
> >>>>
> >>>>
> >>>>> You're asking the WG to make a firm commitment to something
> >>>>> that is neither standardized nor defined.
> >>>>
> >>>>> That cannot be done, and I hope you realize the sort of
> >>>>> process violation it would be encouraging.
> >
> > It's fairly standard IETF and W3C liaison work to make commitments
> > to each other, which is done quite frequently when IETF and W3C
> > have common concerns. See current work around URLs.
> >
> > Having that commitment on record of such a decision to work with
> > IETF to find the bets possible resolution to the rather contentious
> > ECC curve debate might be one of the ways out of the current
> > legitimate demand for a non-NIST ECC curves.
> >
> > Of course, I'd also be happy to see the NIST ECC curves removed
> > and put in an "extension spec" tied to the main spec that could
> > progress to Rec track at the same time. That would at least put all
> > curves on equal footing in version 1.0 of the Web Crypto spec and
> > prevent this debate.
> >
> >
> >> To be clear, I do not think we can nor should attempt to "rush"
> >> the ECC curves. Your proposal - progress to Rec track at the same
> >> time - is exactly what the objection is about.
>
> No, the proposal was that we do not favour the NIST or non-NIST curves
> in the main text of the spec at this point given the discussion in
> TLS/CFRG and the NUMS proposal from Microsoft. That's why there was
> all the timing options details, which would work regardless of how
> IETF/CFRG progresses (or not).
>
> Again, things can progress on the timing that makes sense. The W3C
> does believe extensibility and fairness around contentious issues is
> important for the API to have a properly global audience.
>
>
> >
> >> When the spec is mature, implementable, and there is consensus,
> >> then it can progress. Otherwise, any votes to rush through -
> >> including "placeholders" - ANY spec - would be an objection.
> >
> >
> > In that regard, it might help then we would also help the WG
> > taking the "extension mechanism" very seriously rather than having
> > it as a "second-class" citizen, which is what I think BAL's concern
> > is re putting NUMS as an extension.
> >
> > Would you agree to that Ryan?
> >
> >
> >>>>
> >>>>
> >>>> In the case that these are *not* ready by the time we get to
> >>>> transition out of CR into PR, then we simply update the main
> >>>> spec to have a non-NIST curve *after* Rec. If somehow they do
> >>>> resolve before we leave CR, then we just go back to Last
> >>>> Call. Having a "feature at risk" in the spec here makes sense
> >>>> so that developers know we are watching the space and are
> >>>> ready to act ASAP, but it is not strictly necessary.
> >>>>
> >>>>
> >>>>> Harry, you know an extension spec is equally viable for
> >>>>> acting ASAP. The WebApps WG is perfectly capable of
> >>>>> demonstrating this if you need historic examples of new
> >>>>> features, such as Service Workers, that can be explored
> >>>>> rapidly.
> >>>>
> >>>>
> >>>>
> >>>> If the spec is past PR and we can't go back to Last Call,
> >>>> then we'd just make it WebCrypto version 1.1 and put the
> >>>> CFRG/TLS non-NIST curve in the main spec text then.
> >>>>
> >>>> Of course, if CFRG/TLS discussion - or if the CFRG/TLS
> >>>> recommendations are such that that browser vendors never
> >>>> implement - never resolves then we never update the spec.
> >>>>
> >>>> I suggest then we inform CFRG and TLS about our formal
> >>>> dependency on their decision with the above plan of action. I
> >>>> believe this would resolve the open issue for support
> >>>> non-NIST curves, although I am not sure if it would resolve
> >>>> BAL's objections.
> >>>>
> >>>>
> >>>>> Let's be clear: I object to this formal dependency. I think
> >>>>> you will be speaking for yourself, and not the consensus of
> >>>>> this WG, precisely because we lack consensus.
> >>>>
> >>>>
> >>>>
> >>>> In lieu of this, an extension spec for Curve 25519 need to
> >>>> go forward as well along with double-checking extensibility.
> >>>> Regarding how this fits in with BAL's objection to the CfC,
> >>>> IMHO a formal vote should be taken on the NUMS proposal and
> >>>> more discussion on the point re the algorithm parameters for
> >>>> curves, where again we have a Google and Microsoft
> >>>> disagreement.
> >>>>
> >>>> cheers, harry
> >>>>
> >>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> I'm happy to check in with TLS/CFRG on the timeline and
> >>>>>>> tell them we are considering an official dependency
> >>>>>>> with them.
> >>>>>>>
> >>>>>>> Note in the long-run having the spec being extensible
> >>>>>>> is exceedingly important, as regardless of the non-NIST
> >>>>>>> curves recommended by CFRG, various governments and
> >>>>>>> other folks will want their own crypto algorithms. In
> >>>>>>> this regard, the only other issue holding us from going
> >>>>>>> out of CR is likely the lack of clarity over extension
> >>>>>>> specs. While the spec does note that "This algorithm
> >>>>>>> must be extensible, so as to allow new cryptographic
> >>>>>>> algorithms to be added" there is little guidance after
> >>>>>>> that.
> >>>>>>>
> >>>>>>> cheers, harry
> >>>>>>>
> >>>>>>>
> >>>>>>> On 08/25/2014 05:32 PM, GALINDO Virginie wrote:
> >>>>>>>>>> Hi all, This is a kind reminder that this thread
> >>>>>>>>>> is still live until tomorrow. If you have some
> >>>>>>>>>> opinion to give, it is now. There was already an
> >>>>>>>>>> objection to that resolution [1], but this is not
> >>>>>>>>>> a reason for not answering to it. Any feedback
> >>>>>>>>>> will help the chair to evaluate
> >>>>>>>>>> endorsement/rejection/alternative to that
> >>>>>>>>>> resolution. Regards, Virginie
> >>>>>>>>>>
> >>>>>>>>>> [1]
> >>>>>>>>>>
> >>>>
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0107.html
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>
> >
> >>>>
> From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com] Sent:
> >>>>>>>>>> mardi 12 août 2014 15:22 To:
> >>>>>>>>>> public-webcrypto@w3.org Cc: webcrypto@trevp.net;
> >>>>>>>>>> hhalpin@w3.org; Wendy Seltzer Subject: [W3C Web
> >>>>>>>>>> Crypto WG] CfC : Call for Consensus on the
> >>>>>>>>>> integration of curve25519 in WG deliverables
> >>>>>>>>>> (please vote until the 26th of August)
> >>>>>>>>>>
> >>>>>>>>>> Dear all,
> >>>>>>>>>>
> >>>>>>>>>> I would like to call for consensus on the way we
> >>>>>>>>>> will move forward with the contribution provided
> >>>>>>>>>> by Trevor Perrin describing Curve25519 operation
> >>>>>>>>>> [1]. We discussed several options and I would
> >>>>>>>>>> like to submit the following resolution to your
> >>>>>>>>>> vote.
> >>>>>>>>>>
> >>>>>>>>>> Proposed resolution : the WG agrees on the
> >>>>>>>>>> principle that Curve25519 will be added to Web
> >>>>>>>>>> Crypto WG deliverables as an extension to the Web
> >>>>>>>>>> Crypto API specification. An extension being here
> >>>>>>>>>> a separate specification having its own
> >>>>>>>>>> Recommendation Track.
> >>>>>>>>>>
> >>>>>>>>>> Deadline : votes have to be expressed expected
> >>>>>>>>>> until 26th of August 23:59 UTC Guideline for
> >>>>>>>>>> voting : reply to all to this mail, indicating,
> >>>>>>>>>> +1 if you agree with the resolution, -1 means if
> >>>>>>>>>> you object, 0 if you can live with it. While
> >>>>>>>>>> silence means implicit endorsement of the
> >>>>>>>>>> resolution, explicit expression of vote is
> >>>>>>>>>> encouraged, to help the chair measuring the
> >>>>>>>>>> enthusiasm of the WG participants.
> >>>>>>>>>>
> >>>>>>>>>> Note the following additional information :
> >>>>>>>>>>
> >>>>>>>>>> -          This extension will be used as a beta
> >>>>>>>>>> test for the extensibility mechanism that we need
> >>>>>>>>>> to address as raised in bug 25618
> >>>>>>>>>>
> >>>>>>>>>> -          The proposed editor is Trevor, as long
> >>>>>>>>>> as Trevor agrees to maintain the document
> >>>>>>>>>>
> >>>>>>>>>> -          This resolution does not imply that
> >>>>>>>>>> the draft submitted by Trevor is endorsed in its
> >>>>>>>>>> current state, as the WG did not have a chance to
> >>>>>>>>>> discuss the content. The discussion about that
> >>>>>>>>>> content can be conducted over the mailing list,
> >>>>>>>>>> or during a dedicated call, where we will invite
> >>>>>>>>>> Trevor.
> >>>>>>>>>>
> >>>>>>>>>> Have a great week ! Virginie Chair of the Web
> >>>>>>>>>> Crypto WG
> >>>>>>>>>>
> >>>>>>>>>> [1]
> >>>>>>>>>>
> >>>>
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0064.html
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>
> >
> >>>>
> ________________________________ 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)
>
> iQIcBAEBAgAGBQJT/SXYAAoJEPgwUoSfMzqclwEP+weW50on54fQHY/ytmNfcwGP
> P6obPdxlDO/G3XIvk2z62h/sSxefwDM0SzVx3NL704nEvwb3wJzwon2wMiYLji3b
> w5ahIgHtc1sK+7hLM0s2uRTE414PnH9pPhsYsHguxKaEtvEeDBnccy09EPXUWiUT
> YarMckas01dBtd9kwZFp0caOx0Xu62Qn0vCZ3fWFUzA+zqhaRwhtjz3r24gN88ON
> m+lwuG/7bMTtuAslh3HxAUMehzByBI63txJUlWkEj9x/FuL3cNsjAHl5aMfcWg51
> bb744c5Mzc2zWqqkGJ5Hek3IIfEmtPNxzMZSK95QpxaU0PwG18Y/QK0K5IG6Lkb4
> tSM/+1+xBtKocLTUyeGGkuL3w8yiPoxQj1JochLq4Nzd21RCdyOb+MDOAOxCeXv7
> d+okyhIHyXQfOdqkOYGbeUBLQMLXCWzdJDWV5YOjLf8QsrrMpLhOCvJmekOG69CC
> mToUpvAKybNvK2SQVKpdpZwzGrCoyGzJAIWWE8kY0VWQbWu3cbsAXn81+g8IwOq0
> sjvmTReEwtFINvURcFwwNL44FC4Z9x6NUL0W4YnvYUYtjebMbeqC1Bh4fP4VPUUG
> rqRMvxEsbTDC/wL6AhZGqWiKaQyb+p3lB6YAeNAYkURwOpBIZ8xT9J5VIv/YAEqY
> zatFxy2mJnkJPLBJqjMd
> =5luX
> -----END PGP SIGNATURE-----
>
>
>