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 5:16 PM, Harry Halpin <hhalpin@w3.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> 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.

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/SNVAAoJEPgwUoSfMzqcjr8P/2Heoe0EGJwYy/kUJY4u7huK
> VY0/3pFs/osfWdAdBPwGSbwgmNZKoVTWsZ88WXWaouKsaSZxggWbuOXpJUfH8lPB
> K64QxJQ3Y+FqSJtcvdA4lYWRknIcrUXbESD++nhcQKiruLEAvEBmqcNZa8V66H+f
> A8jt64tSLo6taftEb3dxF9xY+/YE9iJXV9NANS0WKp+xT4EwW32l++tUZOG4kZiG
> Uet4sCBddEayVb1HmSfox7fP576lN1QrFep+iy2Vr5ax5OHNQxKbHH//UWn1dgXn
> HqvShiQ23hPa3JcMrDTi4Xs7gqQNUl5I/3EnT/3aa3RlpZMl240DvxA2dZ/fKk+j
> mho7F7xGjjhH/4Owtgb2ANL5OFkJKTHDLXw/cuOM10rSBMV6cjcdveDDEGncXXzh
> 3Da4JT9HTmhRQGD4kaN3eSZYRcvMMc1GkchF1+b3QcxtnptBVyhytUb709ohrPvf
> E5C82T8AaexqHpgM6HjzyaXCmS35DOIk3KcwF8HCrPvC+fvCTTGyDOoEofpBtIt8
> 7zhPrgLStyPvUHZ9iNogv85iN+/oalPBcaJWjMbwKKZMBuf3dPZJFC8XHuh4zrzR
> HORhVJVPXPHrQpGjmOuoEPCqVfWXMrCjWHAMwln+Xk2EeJVXmZ0V1jCsZ6gHcIE/
> BwpDJg9Nme9Rcq3mKkxe
> =xK4b
> -----END PGP SIGNATURE-----
>