RE: Comments on last call

Ø  You make a number of arbitrary choices seemingly borne out of hostility, rather than technical reason

I seem to have pissed you off, sorry about that. I am sure that I made some errors in my list of suggestions. As I said, I’m not a cryptographer and I only did a few quick searches for “xxx attack.”  I was certainly wrong about HMAC/SHA-1. But I’ll hold firm about CBC-mode being bad and refer, again, to Paterson’s notes.  One wrong,

I don’t understand how my comments can be seen as complaints about a putative messaging API, when you say it’s a toolbox for protocols. First, that wasn’t my intent and I don’t see how you came to that conclusion; and second, I don’t understand the difference between messaging and protocols. Do you mean data structures?

Yes, there is a large legacy base out there, and the crypto-using world is, fortunately, much richer than must TLS. I don’t understand the use-cases that require browsers to *generate*, as opposed to *verify* PKCS#1v1.5 signatures. Can you point me to an  email thread, or did all that happen only on concall?

> The biggest complaint here seems to be we don't hold peoples hands (although, that's generous - what's being proposed is outright handcuffs), ignoring the real use cases for *an API* to support these.
Is there a link to the real uses cases that I can read about?  The only document I could find on the WG page was fairly rough and many of the use-cases (banking and video) can be addressed, and already are, by using TLS.

But yes, if you are going to put out an immutable API then people should have to do Houdini-like tactics before they expose themselves.

On twitter, you said that the intent was to enable JS to do everything that native code can do.  Like the old ActiveX days?  At least back then it was only Windows machines. This API could let any website weaken or expose any web device.  I wouldn’t call that unalloyed progress.

                /r$

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me<mailto:rsalz@jabber.me>; Twitter: RichSalz

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Monday, May 05, 2014 10:42 AM
To: Salz, Rich
Cc: public-webcrypto-comments@w3.org
Subject: Re: Comments on last call


On May 5, 2014 1:21 AM, "Salz, Rich" <rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote:
>
> 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?
>

If you're writing a specific protocol, these are all great things to consider. Good for TLS 1.3. But let's not forget for a second that TLS 1.2, 1.1, and yes, even 1.0 will be here for a while, and they use and do things that some find 'distasteful'. Let's not forget that more than TLS exists - DNSSEC, GPG, S/MIME/CMS, and countless other protocols exist.

This is an API - a low-level API that provides a necessary toolbox to implement a variety of protocols, with a variety of security considerations and tradeoffs.

You make a number of arbitrary choices seemingly borne out of hostility, rather than technical reason. There is no technical argument for insisting AES-CBC only be used in the draft-mcgrew construction, as opposed to securely composed (as it can be). There is no present technical argument for forbidding HMAC-SHA1, given the independence of HMAC from the known attacks on SHA-1 (or, for that matter, HMAC-MD5, as the IETF has readily acknowledged and documented).

The biggest complaint here seems to be we don't hold peoples hands (although, that's generous - what's being proposed is outright handcuffs), ignoring the real use cases for *an API* to support these.

We are not idly dismissing your concerns - they have indeed been considered, debated, alternatives explored, tradeoffs weighed. At the end of the day, this is and remains a tool to implement a variety of protocols, under a variety of JS environments (the Web and SysApps remain two chief examples), and with a variety of security considerations. This is not, and has never been (at least since the days of DOMCrypt), an attempt to formalize a one-size-fits-all cryptographic *messaging* API, which it seems that such feedback is directed towards pointing out how we have failed to do so.

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