Re: Recommended Algorithms and Registry issue

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

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.

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

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