Re: Recommended Algorithms and Registry issue

On 09/09/2013 08:47 PM, Ryan Sleevi wrote:
>
>
>
> On Mon, Sep 9, 2013 at 11:35 AM, Harry Halpin <hhalpin@w3.org 
> <mailto: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
>>     <mailto: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.

Agreed, but do you object to the warning text as written below, in 
particular the warning around AES-CBC? That would help buffer against 
developers naively using some of these primitives.  I'm happy for you to 
add a text saying "Developers who are not cryptographers are not 
recommended to invent their own protocols."

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

Yes, but the issue around integrity being not provided AES-CBC is not 
FUD, of course, but well-known. We are using that as example, thus the 
"For example," in the suggested text.
>
> 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".

I am not asking the API to be inhibited or AES-CBC to be removed from 
the algorithm (although I'd be happy for it to be removed from 
"recommended" if we don't also add an option with integrity). Given that 
the use of the term "recommended" is causing confusion, I suggest we add 
an alternative and add appropriate warning text re security properties 
of recommended. It's *natural* for people to think "recommended" means 
"recommended for security properties" rather than "recommended due to 
compatibility with existing deployment."  I'm happy to get some 
well-respected cryptographers to join a telecon to discuss the AES-CBC 
case in particular.
>
>
>     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.

What is "reactionary" about warning developers to be careful with 
security properties and noting the landscape may change (and again, 
AES-CBC not providing integrity and the general move towards increased 
usage of ECC in the future does not seem speculative)? We will probably 
have lots of developers looking at and trying to use this API, and some 
may be trying to design their own new protocols. I suggest we provide at 
least a warning to them to not design their own protocols and not 
encourage them to "cut and paste" examples using AES-CBC for symmetric 
key exchange.

>
>
>     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.
In general, using URIs for extensibility or have a registry for strings 
is a W3C preference *if* the WG is closed. However, if we want to 
propose now that we keep the Web Cryptography Working Group open beyond 
its charter in order to maintain the algorithms, that's a fair point.  
If so bring that up with the membership in our next chartering change. 
As long as it can be extended, I'm happy. But I also think *if* we move 
to a situation where close the Working Group, then yes, we'd want a way 
to keep people extending the algorithms while distinguishing extensions 
from the RFF and W3C process verified algorithms that have been tested 
in CR stage for interop.

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