W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

From: Nico Williams <nico@cryptonector.com>
Date: Fri, 10 Jun 2011 15:41:39 -0500
Message-ID: <BANLkTikLtXS5HmZeU1ytgcbhotM32yNPjA@mail.gmail.com>
To: Brian Smith <bsmith@mozilla.com>
Cc: public-web-security@w3.org, Jarred Nicholls <jarred@sencha.com>, David Dahl <ddahl@mozilla.com>
On Fri, Jun 10, 2011 at 2:54 PM, Brian Smith <bsmith@mozilla.com> wrote:
> Nico Williams wrote:
>> You've sold me on one clever use for JS crypto APIs. Given that I can
>> ignore my concern regarding false sense of security in other uses.
>> I'm still concerned that developers will not use crypto correctly
>> (consider the CBC padding oracle vulnerabilities we've seen in the
>> past), so I'd rather we offer AEAD APIs than, or at least in addition
>> to, say, raw AES APIs.
>
> I think there are many levels to this. One is "give people tools that they could use correctly to do something reasonable and clearly better than what they can do now" and the other is "give people tools that guide them to doing things correctly, and make it difficult to do things incorrectly." Exposing a raw AES operation definitely doesn't fit in the latter category, but it does seem to fit in the former--because a browser-provided AES operation can mitigate some timing attacks that a pure-JS implementation has no hope of mitigating (AFAICT).

We're talking about native JS crypto APIs, so timing attacks can be
addressed by the implementation (in the browser, or platform).  That's
not an issue here.

The issue I was referring to was raw crypto algorithms versus
combinations of algorithms and modes.  For example, AES with GCM
(that's what I was referring to by AEAD).

> I have heard a lot of talk about SJCL being on the edge of being good enough to do something useful. People who are more adventurous than me are already using SJCL (or similar) to try to do real, important, work. Given that, I think it does make sense to have some low-level operations that make the use of SJCL (or similar) "safe enough" for some useful definition of that term, until high-level cross-browser crypto, key-management, and content-firewalling APIs are ready. A cross-platform secure PRNG API is an obvious improvement along those lines.

We're probably talking about high-level crypto APIs that give you AEAD
cipher modes, MACs, hash functions, RSA, DSA, DH, PRNGs, and a
credential store.  Nothing earth-shaking there, nothing really new.
But uses of raw AES because higher-level primitives won't do... it's
possible, for PACE, for example, or EKE, but mostly not likely.

>[...]
> How much of all of that would be the responsibility of the browser? How much of this responsibility can/should the browser pass off to the web app? Should we be focused on the browser enforcing a particular security model, or should we focus on the browser enabling web apps to enforce their own security models?

That's where trust comes in.  If you have scripts putting
authentication methods together in the scripts, I worry that will only
get us a false sense of security.

Nico
--
Received on Friday, 10 June 2011 20:42:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 10 June 2011 20:42:11 GMT