On Thu, May 10, 2012 at 11:11 AM, Eric Rescorla <email@example.com> wrote:
On Thu, May 10, 2012 at 7:56 AM, Jarred Nicholls <firstname.lastname@example.org> wrote:Yes, this is the case people raise most often. I see a number of
> Where the private key is directly accessible by script loaded from
> Compromised server injects hostile script into a page response, grabs the
> private key, posts it to a foreign server, and now the private key has been
> stolen and used to decrypt any data between the server and its clients
problems with this
line of argument.
To take the specific example of encrypted data where the key pair used to
decrypt it is stored in the browser, it has bad interactions with:
(a) Any time the user somehow wipes his client-side state. I don't have data
on this to hand, but last time I looked this happened quite often.
(b) Any time the user switches browsers, with sync thus becoming a critical
path item opening a whole new can of worms.
Imagine how I would build an encrypted version of gmail with this design,
Right. Not to mention that the same argument can be made regarding stealing the unencrypted data and posting it to a foreign assailant, where obtaining the key means little to nothing when it is just a means to an end, i.e. stealing a particular client's encrypted data. Whether this is a use case to solve or not is to be determined, officially. Keeping things truly secured on the client would probably amount to a much wider scope to the API, e.g. a combination of signed JS code and a secured JS execution context.
For both these reasons, it seems likely that any Web app that uses this API will
want to favor designs that don't require long-term browser-side persistence of
keys, or at least can auto-refresh them, the way that BrowserId does now.
Of course, for any interactive protocol, you should be using crypto
PFS, so this kind of key theft is an issue would have much less salience.
Most vendors have secure sync protocols already that would be fairly easy to enhance to sync stored keys. While it is a consideration in terms of adoption and practical usage, I believe this is a problem that's out of scope of the API and WG.