RE: Comments on last call

Hi Rich,

As chair of the web crypto WG, let me have a very general answer to your comments.
When we started to edit that specification, the working group decided that we would build a toolbox (yes) relying on the minimum algorithms that all the platforms were providing. We decided as a group not to mandate any specific algorithm to avoid forcing the browser to implement them.
At the same time, off course we were sensitive to the fact that using crypto without education could be a problem in some cases. But we are a group of 10 regular contributors, and trying to maintain guidelines for security state of the art in our spec seemed to be a large task we could not hold on our shoulders.

Would that be an item for which Akamai would be ready to invest, you are more than welcome to join and contribute. We have an open task to write this security guideline, on hold since few months, see https://www.w3.org/2012/webcrypto/wiki/Main_Page#WG_Deliverables


Regards,
Virginie
Chair of the web crypto
Gemalto

========================

From: Salz, Rich [mailto:rsalz@akamai.com]
Sent: jeudi 1 mai 2014 22:25
To: public-webcrypto-comments@w3.org
Subject: 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


This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus

Received on Monday, 5 May 2014 12:44:39 UTC