Re: Recommended Algorithms and Registry issue

On Mon, Sep 9, 2013 at 9:28 AM, Harry Halpin <hhalpin@w3.org> wrote:

> When we first started the Crypto API, we assumed cryptography was going to
> be fairly stable in at least the short-term. However, the topic of new
> developments around RSA [1] and now NSA influence on standards bodies [2]
> has the possibility of leading some instability in recommended algorithms
> and algorithms in general. In particular, we can imagine various people
> legitimately wanting custom ECC curves for example. How does this change
> the spec?
>
> Not much, but I'd suggest the two points:
>
> 1) Right now we recommend
>
> • RSASSA-PKCS1-v1_5 using SHA-1
> • AES-CBC
>
> Given latest developments, I and some others at W3C would prefer to remove
> "AES-CBC" but keep RSASSA-PKCS1-v1_5 using SHA-1.
>

"Given latest developments" does not provide a rational explanation. At
best, it strikes at FUD. If we're going to go down the whole FUD route,
let's throw out AES-GCM (GHASH is easier to implement in hardware,
therefore there must be some spooks with special hardware), all of Suite B
ECC (NIST chose the curves, they must have compromised it), and while we're
at it, throw out support for DH (NIST defined the common parameters! Ooo).

I'm very much aware of the discussions going on and the significant FUD
that correctly, naturally emerges from having redacted documents and seeing
the extent of "recent developments". However, I would prefer we discuss the
merits on technical grounds, rather than whether someone slept on the wrong
side of the bed or had a greasy breakfast and thus an upset stomach.

*Both* are currently recommended because of the *significant* amount of
existing deployed infrastructure that relies on these, and the desire to
see the ability to implement in JS what can be done in native.

I've never, since day one, suggested by any means that these are the BEST
for security. We've received comments to the same.

The fundamental question is "Are we in the business of trying to dictate
security policy", and that's always been a position I've strongly opposed,
because it's directly in opposition to developer flexibility.


>
> 2) The topic of a registry led to massive debates before. I think it
> seemed that the one reason was the administrative overhead of IANA. In
> particular, we can imagine various people wanting custom ECC curves for
> example. It seems like a wiki is too lightweight, but we could either have
> the WebCrypto WG (and W3C staff, with help of a public mailing list)
> maintain a web-page after the end of the life of the WG. The spec could
> then point to the web-page and then warn about the lack of RFF policy and
> lack of interoperability testing.
>

Strongly opposed to this. We don't have a registry for CSS. We don't have a
registry for HTML tags. We don't have a registry for every object that
hangs off the "Window" or "Document" global objects exposed via JS. These
are all things that MUST be implemented by UAs to have any value. Having
"various people" wanting to use custom ECC curves is *useless* until a UA
implements that.

That's not to say people can't discuss, bring use cases, propose APIs, etc,
but at the end of the day, it's something that UAs will need to implement.
Having a registry of "ideas" that were arbitrarily registered, but never
implemented, does nobody any good.




>
> Any opinions?
>
> cheers,
> harry
>
> [1]http://www.slideshare.net/**astamos/bh-slides<http://www.slideshare.net/astamos/bh-slides>
> [2]http://www.theguardian.com/**world/2013/sep/05/nsa-gchq-**
> encryption-codes-security<http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security>
>
>
>