That doesn't mean providing the primitives to implement bad crypto is responsible for the bad crypto.
I think the main benefit of this will be improved speed over existing standard javascript crypto support libraries (sjcl, jsbn).
In this case, it absolutely does. Not only will people most likely put them together incorrectly (which isn't the API's fault), but it doesn't provide any defense against cases where the browser is running code not intended by the server, e.g. MITM and XSS. As soon as the browser is running bad code, this is 99.9% equivalent to existing JS crypto (the exception being the secure RNG). The trust model here just doesn't hold up.
You may ask then, "Well, what's the point of this API if you're not going to solve it?"
The answer is that solution for the trust model issues are being addressed concurrently and, unquestionably, more adequately, in other W3C working groups, the WHATWG, the IETF, and other such standards bodies. For example, the development of Content Security Policy, the hopeful formation of the Sys Apps WG, offline apps that execute in their own origin, the proposed <browser> tag, the formalization of the things as basic as the web origin concept (RFC 6454), Web Intents as a service-agnostic IPC mechanism. There are a number of efforts going on to address and enhance the overall security and utility of the platform. Our WG is providing just one small part of the overall picture.
Every concern about malleability of the run-time applies equally so when you're not doing JS crypto - native or browser-mediated. Storing something in localStorage/IndexedDB? Well, now you've got an opportunity to turn transient XSS into persistent, stored XSS. Does that mean localStorage/IndexedDB are doomed to failure or fundamentally flawed for not addressing that? No. Are cookies complete and utter garbage due to all of their known issues? No (or at least, not /complete/ ;-)
I recognize that there are a variety of security decisions and trade-offs being presented in this API, decisions that will have to be made by site authors. It may be that this is completely unacceptable - and I would hope, by now, that people feeling that way would be sending mail to public-webcrypto-comments@w3.org saying that. However, for the use cases that have been presented and expressed, the trade-offs have been understood and are, thus far, acceptable, which is why this WG has continued the path its on and why the participants have, so far, believed in the utility of the API.
As far as algorithms go, our failure (thus far) to include DSA is hardly going to be the end of SSH (for which many still use DSA keys), just like our failure (thus far) to include ElGamal or MD5 are not going to mean the death of PGP/GPG. However, by not including them, it also means that there's no way to implement such applications, even if all other concerns were controlled for - and that would suggest our API is incomplete and a less-compelling alternative. Suggesting that failing to implement PKCS#1 v1.5 will finally mean the end of it is unrealistic.
So far, our stated goal has been to produce a low-level API that has applicability for a number of situations, as captured both in the use cases of the draft and in the companion use cases wiki. The core functionality starts with "Secure key store. Secure RNG". In order to support "secure key store," it's necessary to define what you can do with these "secure" keys, hence, the specification of certain operations and algorithms.
We're not (thus far) attempting to create an enveloping format - that's something that the IETF JOSE WG is doing, and that various groups and standards ranging from XML DSig to CMS to S/MIME have done or tried to do.
We're not (thus far) attempting to create the one-true-perfectly-safe-full-of-cryptographic-kittens-and-puppies "box" and "unbox" - it's interesting, unquestionably useful, but getting two crypto-geeks, let alone a hundred, to agree on what that operation is composed of is a sisyphean effort. Should it be Sals20 or AES-GCM? Why not Blowfish? Monkey knife-fighting appears more civilized then some of those crypto-political discussions - and makes more progress to boot.
By providing the low-level API, application developers can make an informed decision on what that "box" looks like to them, or relying on cryptographically skilled developers to produce libraries (ala KeyCzar, ala NaCl) to do that for them. Yes, it also means that uninformed developers can start smashing things together and leading to wonderfully painful crypto-explosions. However, you don't see WebGL being lamented for its lack of built-in VRML support (I hope...), and neither do I think this API should include the kitchen sink, bathtub, robe, and matching slippers in order to be useful and applicable for many web developers.
Yes, screwdrivers are wonderfully useful tools, and it's fairly hard to hurt yourself with one. But sometimes you really need a hammer - or a chainsaw, or a level, or a drill - in order to do the right job. This API is merely a toolbox - dangers and all - not the One True Solution to all the Bad Crypto.
By providing the low-level API, application developers
can make an informed decision on what that "box" looks
like to them, or relying on cryptographically skilled
developers to produce libraries (ala KeyCzar, ala NaCl)
to do that for them.
... neither do I think this API should include the
kitchen sink, bathtub, robe, and matching slippers
in order to be useful and applicable for many web
developers.
My experience has shown that to be the exception much more than the rule. Put another way -- I've never reviewed a system implemented by developers experienced with cryptography that hasn't had at least small flaws. The carnage created by validating the practice of novelty crypto protocol design to many developers may be astounding.
I think you're too sanguine about the potential damage to users by this API. That's the problem with externalities. It's not the developers who hurt themselves with this "chainsaw", it's the end-users who are hurt by those developers.
In other words, you're claiming that some few skilled
cryptographers will produce a safe, high-level API
(eventually) and the low-level API is already useful to many
web developers. The implication is that many web
developers can do something that is both useful and safe
with only the low-level API.
However, if we only provide a so-called high-level API (what I've been terming as box/unbox, and which is conceptually similar to what Keyczar, Nacl, or even JOSE offer), then I think there's even an larger number of known and possible use cases that simply cannot be implemented. That's why I believe it's more useful to provide a low-level API.
I think perhaps there are unrealistic expectations on what this is trying to do or who this is trying to serve. It's not trying to save the world from bad crypto. It's attempting to bring to the web platform what has existed in native code for 3+ decades - pitfalls and all.
I'd also be concerned about the argument going the other way - if we only provided a high-level protocol & API, then developers would need to implement whatever protocol specified atop the existing low-level primitives (OpenSSL, PKCS#11, CNG, etc). There, just as well, the risk is that people will get it wrong - or that 'others' will write libraries to do it right. You can't escape from the fact that crypto is hard, and that there is always going to be a segment of developers who will simply not get it right.
You guys are working on something important, for better or worse.
Have you ever arranged to sit down with people who have spent time breaking cryptosystems? You're talking to a couple here (Nate is far more qualified than I am), and I saw on the mailing list you bounced the ball back and forth with Zooko --- who, while more a builder than a breaker, is at least pretty cognizant of real-world attacks.
You also had the RUB critique of the API, which saw no response on the mailing list.
Is this API something that is likely to ACTUALLY HAPPEN? If it is, why can't we just arrange to get people into a room to talk to them about what goes wrong when devs get tools like this?
The most dispiriting thing I see happening here is parties talking past each other. Let's force the issue.
As far as "arrange to get people in a room" - that's exactly what we're trying to do, and exactly why we solicit feedback. While the Hacker News engagement is great, and so is Twitter, I suspect that I'm missing 90% of the discussion because nobody is sending mail to where we asked - public-webcrypto-comments@w3.org - and so no one in the WG is having a chance to engage and discuss.
Again, we're not trying to design a cryptosystem here, as far as a "secure messaging protocol" goes, least of all because no one who submitted feedback during the months of time spent when it was a W3C Community Group and chartering into an actual WG did anyone actually give a use case where their needs would be met with such an API.
Definitely, the best place for concern and criticism will be the mailing list, and that's the whole point of the wide canvas and call for feedback.
You don't really address this issue, but point to what you claim is the greater good: more freedom to implement any protocol the dev pleases. In your opinion, the gain from this is worth the cost of a few million compromised users (story out yesterday: Pandora doesn't manage keys for encrypting cookies properly due to a developer choice).
The only problem with this argument is that there is no limit on browser JS developers' freedom today. They can implement anything they want, plugging in AES ECB blocks wherever they want.
For example, consider Meebo, which sent a JS RSA implementation plus the key itself as a substitute for SSL. There was nothing wrong with their JS implementation of raw RSA (as far as I remember), but the whole problem was that crypto doesn't work if the key and cipher implementation are both modifiable by an attacker.
I find it funny that you agree with me in the end:
You can't escape from the fact that crypto is hard, and
that there is always going to be a segment of developers
who will simply not get it right.
Currently, the W3 API will victimize millions of users via any clever developer who has read Applied Cryptography. With a high-level API, you reduce that set of devs to those who are determined to get it wrong (e.g., post private keys on their website today). I think you agree that's a smaller set (though how much, I don't know).
The W3 low-level API will encourage more flaws while offering no improvement over the current JS security model. The fact that you can do things like Meebo (but with higher performance and cred with managers that "it's the standard"), is a net loss of security, not gain. Too bad.