Re: Recommended Algorithms and Registry issue

On Tue, Sep 10, 2013 at 1:12 PM, Harry Halpin <hhalpin@w3.org> wrote:

>  On 09/09/2013 08:47 PM, Ryan Sleevi wrote:
>
>
>
>
> 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.
>
>
> 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.
>

Harry,

I feel like this is rehashing the "Tell people how to write secure
protocols" discussion, in which the answer is "Don't write your own
protocols in the first place".

This is more or less the exact same discussion we had with AES-ECB, and is
identical to AES-CTR, which equally doesn't provide integrity protection.

Your original message suggested "in light of recent developments", as if
there had been new information. In this respect, there has not, so I would
like to suggest we keep the issue closed, as the WG previously agreed upon
at great length and discussion.

The issue is not convincing me, or anyone, that AES-CBC without integrity
is bad - that's obvious to anyone familiar with basic cryptographic
constructions, much in the same way using AES-ECB beyond a block sizes'
worth of data (eg: the AES-KW case) or using AES-CTR without integrity
protection that includes the counter value.

I'm fully in favour of characterizing "recommended" as "recommended for
implementations", with a split between "Recommended to support existing
applications" and "Recommended to support new applications" dichotomy, but
we simply must avoid rehashing the "Security Considerations" section that
previously (after great discussion) we closed, unless you can point to
compelling new information.



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

It's "reactionary" to try to re-open a topic that the WG spent considerable
time discussing and reached closure on, on the basis that something
crypto-y is in the news - even though it's unrelated.


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

Right - if we find ourselves to the point where we've completed our charter
and see the WG closing, let's talk about how to shut down cleanly then. But
doing so now feels not only premature, but also dangerous towards 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
>>>
>>>
>>>
>>
>>
>
>