Comments on last call

I am not a cryptographer, but I have worked with real-world applications of it for more than 20 years. I am a recognized contributor to HTTP, XML Signature and Encryption, and WS-Security among others.  I am writing to comment on http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/ .

I am very concerned that this specification just "throws everything out there" with absolutely no guidance as to which algorithms to use, and which ones to avoid, and the circumstances which would influence a choice. This is a tragic mistake.

I understand the desire to leave guidance for a separate document. There are many rationalizations for that, from "mechanism not policy" through to the claim that a separate document makes us more flexible to policy changes when new attacks are found. This may be true, but when the W3C and IETF official consider that the Internet is under attack from pervasive monitoring, you are shirking your responsibilities if you provide millions of Javascript programmers API's that will create cryptographically weak objects. As a gedanken experiment, suppose a member of the working group wanted inclusion of the classic Usenet "rot-13" cipher. By what rationale could, or would, that be exluded from this document?  Similarly, why isn't triple-DES specified?

At a minimum, there should be an open review for attacks against the defined mechanisms. Those which have well-known attacks, and those which have been superceded by better mechanisms, should either be withdrawn, or have a "read-only" interface available. An argument can be made that interoperability with a deployed base requires the ability to read such items; the case for being able to *create* them is a much weaker one, and should be available, if at all, only under duress.

For example, any RSA-based signature except OAEP should be in this "legacy" category.  So should AES-CBC.  So should SHA-1 and anything that uses it, such as an HMAC. Any CTR-based mode is weak against chosen-ciphertext, which I believe is a  particularly likely use-case for Javascript applications.  As TLS evolves to only support "AEAD" cipher methods, why is anything other than AES-GCM not in the "legacy" category?

You are about to unleash a toolbox filled with very sharp instruments to a very large community, with the likely possibility that many of those users will end up foolishly deluded into thinking their private data is now secure.  Please, don't.

                /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA