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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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.

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.

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.

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/R78AAoJEPgwUoSfMzqcossP/1cqJOQikGlWirV0lgoJSp+b
eJV1/1o8CYGjh8w31COgnOmtONUh3uoHQPZQJp8RzwWik1RWjqB7g1ZecKVTX0NX
1cdsEmvNwboxCz3TYRU/eXLkGWzXlUT6Mtx8EufwAvk6UAvSGai9ISZUgoKwGFsI
HLAS3qIC/mUqhOHc86+LNaFFgiSH8kKvECOw6zf99QaE4NEuC8ankjNId2KpYcqy
/k4mKbAkpIw2naMzlXsQUJnV+nBwZ37ZXN5l1RNTL8tJkEFmspvoTbA3cHveRtLO
wck09qzpycFsgJrchVuH28oyy8+Zca8Bm2vLrWa0Lr/tbD5TQEZOxw44cSp4OJ7c
ClX7SLncoWy1B/g+ynHEPnMQr6MIVnUG4Sh6AAGlEWD3VhrMD9tj8ItdSMJqfPgK
QykBFEhYXz60h5C3CMQWBIe54qV9ulKqZ4ETHx4k6rWNXXzAdyj8SURLJPiz/+rX
MxbKNpuhtXmoJY7aE9QrxSWPCkJzT81zjxPQ0mLjEyVzYdh+TDjMC9t78BtxIDvn
UQvCDsANcQw8fKekAkd/TwbvpuVvwh7r84UfQ9mpevzKFXBfhozDdb8kATH5QjcF
Nol10nR+aBYqJwrpdGmkt8eJ2YWIlmNnBWV2fqBbuULKFmBkKUv0xkgRpSr8sqvb
BN420K4WX+pAwc0bXIW0
=ugxI
-----END PGP SIGNATURE-----

Received on Tuesday, 26 August 2014 23:57:57 UTC