Re: Comments on last call

On Mon, May 5, 2014 at 8:52 AM, Salz, Rich <rsalz@akamai.com> wrote:

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

You're wrong about CBC mode as well. Nothing prevents CBC mode from being
used securely. draft-mcgrew is proof of that. You can construct an AEAD
from CBC and HMAC. There are protocols that have done this - although as
AE, not AEAD, since they had (and have) no need for the AD. Insisting that
the only way to access CBC is through an AEAD like draft-mcgrew is an
arbitrary choice - suitable for protocols, but entirely unsuitable for APIs
- especially ones that wish to bring equivalence to the web platform.


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

It's a toolbox for implementing protocols - it is not a protocol itself.
That is, there was and is remains much debate about so-called "high-level"
APIs in which all the cryptographic choices are made. However, when you
start making opinionated design decisions, you no longer have an API
toolbox - you have an API for a specific protocol / data structure (such as
JOSE).

This API is not and does not try to be that JOSE API.


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

I suspect you're confused again here. The objections are primarily on the
matter of RSAES - that is, encryption/decryption via PKCS#1 v1.5 - not
RSASSA (sign/verify). While RSA-PSS has stronger guarantees, the use of
RSA-SSA remains key to a vast number of protocols - from S/MIME to TLS.

If you want to see examples of why APIs would wish to *generate* PKCS#1
v1.5 signatures (which itself should be obviously a use case, judging by
how much 'native' code does so), you can look at work that people are
already developing, such as PKI.js - https://github.com/GlobalSign/PKI.js

As for encryption/decryption - there's certainly a use case for encryption
via RSAES: interoperating with any protocols that use encryption (TLS is
one such example). The decryption case is tricky - and that's already being
tracked in our bug tracker.


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

That's certainly a valid opinion, but not one the WG shares. Note that I'm
not suggesting you deploy WebCrypto over HTTP - I think deploying or using
WebCrypto over anything but an authenticated transport (eg: TLS, signed
extensions) is a foolish task doomed for failure. However, there are plenty
of reasons - even when talking over TLS - to wish to add additional layers
of transport security, or to recognize that the intermediary nodes between
the server you're talking to and the server your peer is talking to (both
over TLS) may not be secure, and may not be appropriate to secure with TLS.

Consider, for example, how SMTP over TLS buys *nothing* for E2E email
security, in a land of MX relays. You can trust your mail server, your peer
could trust theirs, but in the world of MX and SMTP, that doesn't mean
anything.


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

And this is, again, where we disagree.

Houdini tactics last for all of about 30 seconds - the 30 seconds it takes
for someone to post on StackOverflow the solution that everyone apes. Your
proposal for exceptions will just result in everyone writing the same
boiler plate

subtle.encrypt(...).catch(e => return subtle.weak.encrypt(...)).then(result
=> stuff);

Which is the Promise-equivalent to
try {
  return subtle.encrypt(...)
} catch (e) {
  return subtle.weak.encrypt(...)
}

The list archives are littered with discussions about how and why this
dance is pure theatre and does nothing to ensure the outcome you're
attempting.


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

I cannot grok your threat model here. JS can already do crypto - but
without safe key storage or assurances of the constant-time
nature/correctness of implementation. Every major native platform provides
such APIs - either directly (CryptoAPI, CNG, Security.framework) or
indirectly (libraries like OpenSSL/NSS, key storage like KWallet/Gnome
Keyring). Why should such a thing be denied or artificially crippled?

Conflating with ActiveX is... inaccurate, to say it politely.


>
>
> --
>
> Principal Security Engineer
>
> Akamai Technologies, Cambridge, MA
>
> IM: 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> 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
> >
> >
>