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

On Mon, Aug 4, 2014 at 1:45 PM, Harry Halpin <hhalpin@w3.org> wrote:
>
> > 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.


There is maturity in specification of the curves, and maturity of the API
specification within WebCrypto. There is no question on the latter point
that things are immature (to the point of not being written).

Again, everyone will keep coming with their own algorithms - some mature
(GOST, SEED), some not (Goldilocks and, unquestionably-but-respectfully,
NUMS). The cut-off point for "When things make reasonable sense to be put
in the spec" and "When things belong in a separate spec" has unquestionably
been crossed - and it was crossed many, many months ago.

Every algorithm, every change to every algorithm, tangibly alters the
security surface and requires re-review. Every specification, once
implemented, becomes an immutable part of the Web Platform, one that cannot
be changed without the dreaded issue of "Breaking compatibility", and thus
by all means should be avoided.

This is exactly why a separate specification - with a clearly defined
maturity (or lack thereof) is wholly appropriate.


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

Harry, "giving algorithms a chance" is exactly how we end up three years
later from now, still haggling over the details. By the time we finish
discussion of one set of algorithms, another comes up, and "fairness"
dictates we continue to allow it.

We need to have a point where the very shape of the API - the thing we
spend our time fixing and resolving issues - is fixed. I absolutely oppose
introducing ANY new algorithms, as it's clear from the discussions of both
Curve25519 and NUMS that they can, will, and do detract significant
technical and editorial investment to discuss, review, and refine.

A far, far greater use of everyone's energy is to proceed independently.


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

Harry, a separate spec as REC track fully accomplishes that, and ALSO
resolves the concerns you're hearing regarding maturity.


>
> As BAL's proposed edits showed, this can be clearly separated from the
> rest of the spec as a "feature at risk."
>

And as my response showed, there are a ton of issues with that. And as this
(continued) discussion shows, it's continuing to detract significant energy
and effort from actually resolving the other spec issues.


>
> I am not drawing conclusions, I am pointing out one viable route
> forward for resolving this bug.
>

And we already have a viable route, that was minutted on our last call as
being acceptable, which was an extension spec on REC track.


>
> However, not having a clear extension spec process


Let's not sling FUD. If you have a bug on extension spec process, you owe
it to the WG to file it. We don't have any such bugs on extension spec
process, and the only "extensibility" concerns raised so far have been with
respect to a registry, which stems from a misunderstanding.


> *and* not having non-NIST ECC curve options in the spec do not seem to be
> likely to
> resolve the issue.
>

Let's not conflate two different bugs. The bug on "provide a non-NIST ECC
curve" was already closed, as WONTFIX. That's a bug that doesn't exist on
technical merits, merely political, and unquestionably stems from a
misunderstanding about what the spec means.

The bugs on "Support NUMS, a non-NIST ECC curve suite" or "Support
Curve25519, a non-NIST ECC curve" do not require specification alongside
the NIST curves. You've already heard from the proposed editor from one
such draft that they would, intentionally, not be extending such.