- From: Harry Halpin <hhalpin@w3.org>
- Date: Tue, 10 Sep 2013 22:42:00 +0200
- To: Ryan Sleevi <sleevi@google.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <522F8418.9010706@w3.org>
On 09/10/2013 10:27 PM, Ryan Sleevi wrote: > > > > On Tue, Sep 10, 2013 at 1:12 PM, Harry Halpin <hhalpin@w3.org > <mailto: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 >> <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. > > > 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. Yes, and AES-ECB isn't in "recommended". That's why we need to clarify what we mean by "recommended". > > 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. So, it seems to me just a quick note warning people about that "recommended" does not mean "recommended for security properties" in any way would be sufficient. I think the text you and I suggested could be added to that section and address that issue. Dividing up I'm also fine with, given that the only caveat would be "recommended for new applications" might change on "new developments", as we earlier discussed. > > >> >> 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. Again, we are receiving renewed interest in review from cryptographers due to the "news" around standards bodies - and I'm all for more review. :) Again, the "new" in the the news is that there is a much higher chance I think of people trying to write their own secure protocols (regardless if whether this is a good idea) and we can expect more scrutiny around this API from the general public. > >> >> >> 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. OK, the timing issue is that we *should* have this decided before exiting Last Call in order to assure proper lock-in of patent commits going forward. We should not add algorithms after PR stage (and really, CR stage), and thus would have to start a Web Crypto 1.1 if new algorithms come up that we want to add while in PR stage. Which means a new Working Draft, etc. etc. I'm happy to do that if the WG actually thinks this is the best way forward. I suggest we discuss more in person at TPAC, but I would be interested if folks want to make this a long-running Working Group ala WebApps (even if just for keeping algorithms open) or close it. > > >> >>> >>> 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 >>> >>> >>> >> >> > >
Received on Tuesday, 10 September 2013 20:42:12 UTC