Re: Recommended Algorithms and Registry issue

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

>  On 09/09/2013 07:58 PM, Ryan Sleevi wrote:
>
>
>
>
> 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.
>
> Yes, so if we're having lots of people notice this let's fix it. The
> problem is people are confusing "recommended to implement" with
> "recommended to use in new protocols".
>

I would rather solve this by doing the much more sensible and secure text:
You are NOT recommended to invent your own new protocols!

As much as I hate ideas of a crypto priesthood, the only people who should
be "designing new protocols" are the people who understand HOW to design
new protocols and what the security risks are. If you're having Joe
Developer design a new protocol, no matter how secure the primitives are,
*they're going to get it wrong*. Full stop.

This is no different than the security issues attendant on jsonp (eg: you
think "while (1)" is adequate security), XSS, or XSRF.

The argument that "the protocol needs to be secure" is irrelevant, because
we're talking JS in a hostile environment. *everything* needs to be secure.


>
> Case in point: I think you misinterpreted the issue with AES-CBC. While it
> is highly deployed,  AES-CBC does not provide integrity. So at least put a
> "warning" next to that recommendation and include also AES-GCM in the
> recommended case. That can be done by adding the following sentence
> "However, in order to promote interoperability for developers, there are a
> number of recommended algorithms. *Note that these algorithms are not
> recommended for security reasons, but due to deployment. For example,
> AES-CBC does not provide integrity and thus for many use-cases an
> alternative that did allow integrity such as AES-GCM would be preferred
> from a security standpoint*.  The recommended algorithms are:"
>
> Likewise, I'd recommend we not use AES-CBC in our example code in 20.2,
> but use AES-GCM.
>

You realize my above message was highlighting that there is already
circulating FUD re: AES-GCM, correct? If we're going to wave our arms on
ECC, are we really comfortable we know enough about the design of AES-GCM
not to similarly flail our arms here?

My point being is that I strongly oppose reactionary measures that lack
more information. I'm fully sympathetic to the security concerns - we've
beat that horse to death, I hope - but I would remind you that we're in a
very *different* situation than what you're seeing on the news. We're
specifically *not* designing protocols, but we're talking about an API
surface to allow the implementation of such protocols.

We should ensure the API itself is robust (eg: opaque key material), but we
should not arbitrarily inhibit the API "just because".


>
> It may also behoove us to try to get Dan Boneh and like-minded folks on
> the phone before we hit Last Call to do a quick review.
>
>
>  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.
>
>
> As noted earlier (and I would not call the iSEC Partners observations
> FUD), there is a higher than zero chance that there may be some changes in
> preferred defaults in crypto in the near-term future (such as a movement
> towards ECC), even if those changes happen only in particular countries due
> to policy reasons rather than clearly technical reasons (such as divergence
> in ECC defaults).
>

Fear, Uncertainty, Doubt. Is that not the essence of what these
observations are? Even if rightfully deserved, let's at least recognized
that what we know, right now, is *very* little, and so what we have is
rampant speculation.

I strongly oppose a reactionary move just because people are
"uncomfortable" - that can and will do much more harm in the long term.



> Thus, its I think reasonable to guess there may have to be a quick
> change/addition on the algorithm level -  change that UAs will implement -
> and this may happen after the WG goes into CR. Rather than face a repeat of
> the vendor-prefix issues around CSS, a lightweight registry maintained by
> the WG with adequate warnings make sense.
>

> HTML does have a registry for link rel values, BTW.
>
> http://wiki.whatwg.org/wiki/RelExtensions
>
> Other WGs have had registries (although it is rare), such as XPointer:
>
> http://www.w3.org/2005/04/xpointer-schemes/
>
> Again, I'd prefer it if such as registry was used rarely, if at all, but
> leaving the door open helps, and poses I see no harm if it is correctly
> described as a registry without the RFF and not covered in the test-cases.
>


Again, unlike both link-rel and xpointer, the algorithm parameters are
programatically-visible API surface. This is no different than
window.fooObject. We should not confuse the fact that because there is a
string involved, it somehow becomes something different or
automagically-extensible.

I would much rather see this be a point of discussion when we talk about
this hypothetical shuttering of the WG - since it's clear from our charter
and our members that there's still significant interest in continuing the
activities of this WG.


>
>
>  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
>> [2]
>> http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security
>>
>>
>>
>
>