Re: W3C Web Crypto WG - about the NUMS/25519 curves integration in Web Crypto API

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 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.