Re: Comments on last call

On May 5, 2014 1:21 AM, "Salz, Rich" <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
>
>