- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 04 Aug 2014 22:45:54 +0200
- To: public-webcrypto@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/2014 10:36 PM, Ryan Sleevi wrote: > On Mon, Aug 4, 2014 at 1:31 PM, Harry Halpin <hhalpin@w3.org> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> >> >> On 08/04/2014 10:08 PM, Ryan Sleevi wrote: >>> On Mon, Aug 4, 2014 at 12:57 PM, Harry Halpin <hhalpin@w3.org> >>> wrote: >>> >>>> 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. >>>> >>> >>> This is not true for a second. >>> >>> It does the Web community a great disservice to have a variety >>> of algorithms at a variety of maturities included within the >>> spec. The spec - and this WG - would benefit greatly from >>> focusing on developing and resolving the issues of the current >>> algorithms, without being distracted by another algorithm or >>> set of algorithms with known maturity issues. >>> >>> This has nothing to do with me preferring NIST ECC curves, and >>> everything to do with me preferring that we actually focus on >>> developing a half-decent spec that can be reasonably >>> implemented, rather than needlessly going in circles on adding >>> in everything and the kitchen sink, and using the excuse "It's >>> at risk" to avoid having to make the real and hard decisions >>> that "perfect is the enemy of the good". >>> >>> In either event, I cannot support your proposal, because even >>> though I would love to see both NUMS and Curve25519 developed >>> and mature, it's unquestionably bad for the spec and bad for >>> the web development community to encourage such an addition. >> >> Quick question - is that your opinion as an individual or the >> opinion of Google as a company? Just noting that AGL and others >> are using Curve25519 in the encrypted email Chrome extension >> [1]. >> >> Again, note some web developers want non-ECC curve and a major >> browser vendor. If some browser, such as Chrome, does not want >> to implement the recommended non-NIST ECC curve, this will simply >> be a lack of support in CR phase by that browser. If there are >> not two browsers supporting a feature, then it will removed by >> the exit of CR. That's why "features at risk" exist. >> >> Again, we have objections, comments, and a number of non-NIST >> ECC curve specifications being developed, both in this WG and in >> a number of other WGs in the IETF. Brian has already outlined the >> needed changes for inclusion in the main spec of NUMS, and these >> changes could easily be adopted to be Curve 25519 or another ECC >> curve. >> >> I have attempted to clarify both the publication of extension >> specs (i.e. was Working Group Notes, indexed by a wiki) and a way >> to keep a non-NIST curves in the spec. These are all perfectly >> operationalizable edits and the WG should try to get consensus on >> them. Without clarification on at least *one* of the above, we >> will have a number of open bugs that will prevent us from getting >> through Last Call. >> >> cheers, harry >> >> > Harry, > > As per usual, you've misinterpreted my concerns, either willfully > or unintentionally. I don't know how many ways I can try to spin > this for you, since I am unclear as to what point you're missing. I sympathize with your concerns are that these curves aren't mature. The response by CFRG's work with the TLS WG, Trevor, BAL, and others is that there seems to be momentum to mature them. Thus, my proposal is we give them a chance. That's not letting inertia win IMHO, that's being fair to the web developers who want these curves. The proposal has clear deadlines for inclusion, testing, and maturity before exiting CR. In general, a spec is not mature until it has exited CR. The point of Last Call is to let the public comment on the spec, which we got quite a lot of and it is our responsibility to try to address those comments in sensible ways rather than ignoring them. If there was consensus in the WG and the wider cryptographic community that non-NIST curves proposals were not mature, I think we'd all agree. Unfortunately, we don't have agreement. Thus, this seems a sensible way to give the community more time to reach consensus while not holding up spec progress. As BAL's proposed edits showed, this can be clearly separated from the rest of the spec as a "feature at risk." I am not drawing conclusions, I am pointing out one viable route forward for resolving this bug. However, not having a clear extension spec process *and* not having non-NIST ECC curve options in the spec do not seem to be likely to resolve the issue. > > I would merely encourage you to re-read my reply, and see, again, > that this objection has nothing to do with NIST or non-NIST, has > nothing to do with any "grudges" against Curve25519 or NUMS, and > has everything to do with ensuring our specification is mature and > responsibly developed. > > As such, I don't think it'd benefit the group or the discussion to > continue to belabor these points, as I suspect that your > conclusions on the position have already been (inaccurately) > drawn. > > This has everything to do with spec maturity. It has nothing to do > with the algorithm. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT3/EBAAoJEPgwUoSfMzqctyUQAIaucWJpL8hG35uVnBk1gYtz o5jOW2KI6cLVxjHweJJazlUNflEF4fIY8Rs7gFTp1iwPqEadTjO/5aIZ5qZqkiyG qVHcL620kg+EywFClmB8phj6YDZeAyocyeXpYRa2p8kbw697dFGCxdS8LWoHTIb/ rGqOxVeRcHlrSGHEFWks+VASrXMXXTZAIWpM8EdL91XkOrDHrX3/+VBfgSEXo6PC LHivuCoTgSrc3BT8udbXIgnkqfbZaZ/yZ/lMpjuOrGKpTCfavhAlK52KJvW5rhdq U/QPCiTy48NGBAJSAUeEursBDh7hW+ifhI63gPDOdnbVb1jN85XeyhVS/kaTS7BY Jjz74uElze1Qc2yxO90q6YBcTqZOzzpMwiyT5+fr3CaXphGKgEQphy5edvMpvpt/ JTHTx68okhA6x08IhKi6bp3cyp3tNaeL81zklAKfAy9Jh6PScb4mT+GU7QfV6vRF UOIJyykN2fkUC5x54qrIFMS5G/Jpol6uSaPXM483NlRHffyaUraUGjf8yLopvG/o CN+FwmDgv4qqXlBm7YDc/7tcBW/3KMTds+qAeWE/pUbWXkSV8RTC+0u9blVRFuQD Y/z9WgifRVz/N8e0Ox0ka/PU71RfiiuFEqY7b5OjioK8CxHbn4fdM5itA9Dvu/Bo aWYl5bnGSqNpUNehBI5b =faiM -----END PGP SIGNATURE-----
Received on Monday, 4 August 2014 20:46:06 UTC