[Bug 26080] Remove unsafe named curves from Web Crypto API

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26080

--- Comment #4 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Greg Slepak from comment #3)
> Inter-operability should be broken for crypto that is insecure (this is not
> a comment about the security of the NIST-curves, but a general remark).

It's hard to see how you're not making it a comment on the NIST-curves, since
you're arguing they should be removed. The only reason for removing would be if
you view them as insecure.

If you do view them as insecure, well, that's an opinion that is still highly
subjective within the cryptographic community, [1] aside.

> > > 3. Should any Named Curves be discovered to be unsafe in the future, that
> > > they be deprecated and eventually removed from the spec.
> > 
> > That's not going to happen, for the reasons captured (at great length) on
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 . That's not how the
> > web works.

As noted on that thread, removing APIs from the web (which breaks sites) is
far, far more troubling and difficult.

Referencing SSL 2.0 is entirely orthogonal to the discussion. This would be
akin to the next draft of HTML removing support for the canvas tag entirely.
Just because you removed it from your spec doesn't magically make it stop
existing, nor does it remove browsers' need to support it, as pages live on.

The history of HTML - and in the Web in general - is that APIs are not
deprecated. Period. And so far, it's been a good story.

> To take one of the unsafe curves currently specified, secp256r1 has a
> questionable history [1]. What if it's found to be brute-forceable by
> a supercomputer within a small time frame? Will you still keep supporting
> it in your spec and thereby endangering the security of the net?

Let's keep the excitement to a minimum, and the objectivity at a balanced
level.  "Thereby endangering the security of the net" is a statement that can
be shown to be demonstrably false, and is at best an emotional appeal. It is
application developers, not user agents, that are best capable of evaluating
their appropriate requirements for security and interoperability. Web Crypto
simply provides those tools.

The statements about backdoors have so far shown to be without merit, but are
equally unquestionable a matter of subjectivity within the cryptographic
community. We can appeal to experts on either side - those that view they are
backdoored, and those that are not. Generally speaking, the claims of backdoors
have been significantly overstated, as it relates to the DLP.

However, if we set that aside for a second, there are clearly a number of use
cases, today, right now, for the use of the NIST curves. The fact that every
standards-based system uses them is chief among them. Stating these use cases
are invalid for WebCrypto is a subjective opinion, and one that does no one -
user agent vendors, authors, or users - any favors.

If you still truly believe that the use of these curves endangers the security
of the net (an opinion I would strongly disagree with you), even if you feel
these use cases are out of luck (which would go against our charter, arguably),
you'd be far better protecting the net by getting them out of TLS and X.509,
since that's the basis of all the user agent security promises to begin with.
If they are insecure, then NOTHING built on WebCrypto can be secure, since
they'd be on an insecure transport.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 12 June 2014 22:20:54 UTC