Re: Protection of decrypted data from malicious servers?

On Tue, Mar 25, 2014 at 3:52 PM, James Marshall <james@jmarshall.com> wrote:

> On Tue, Mar 25, 2014 at 2:24 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>> On Tue, Mar 25, 2014 at 1:57 PM, James Marshall <james@jmarshall.com>wrote:
>>
>>> New here... glad to see work happening on this.  I've wanted client-side
>>> encryption for a while.
>>>
>>> In the current draft, is there any protection against a compromised or
>>> malicious server learning decrypted content, e.g. by having JS that
>>> decrypts data and then sends that back to the server?  Ideally, client-side
>>> encryption can protect data from a malicious server.  For example, I'd like
>>> to see a webmail site with full end-to-end encryption, without making us
>>> trust the server at all.  CSP helps, but is not a full solution.
>>>
>>
>> No. This is impossible. This is not a valid threat, and not something in
>> scope for this WG.
>>
>
> Well, fair enough if it's not in scope, but I think it leaves a
> significant problem unaddressed.  Is secure webmail impossible then?  It's
> definitely something many people want.
>

And I want usable cryptography... Er, a pony :)

Is "Secure webmail where you don't trust your webmail provider at all but
use a security program provided by them" impossible? Yes.

Is "Secure webmail where you trust your webmail provider, but don't trust
all of the SMTP nodes along the way" impossible? No.
Is "Secure webmail where you use a WebApp/Extension to keep the Key
separate from your Webmail provider" impossible? No.


>
>
> You're running executable code you just downloaded from an arbitrary
>> server. If you don't trust that server, no amount of machine learning magic
>> is going to help you determine whether this code is safe or not.
>>
>
> We use all kinds of sandboxes for different kinds of code.  JS itself has
> many restrictions for security's sake.  Tainting is already supported in
> some languages.
>
>
>
>> If you don't want to trust a server to deliver your code, you can use an
>> extension/webapp/whatever your UA vendor of choice calls their particular
>> version of SysApps ( http://www.w3.org/2012/sysapps/ ). These apps are
>> delivered out of bands, using a form of code-signing, and don't require
>> trust in any particular server. They do require trust in the entity
>> delivering the code, though. Which has been well understood for a Very Long
>> Time ( http://cm.bell-labs.com/who/ken/trust.html )
>>
>> It is quickly turtles all the way down. Can the browser protect against
>> the OS? Can the OS protect against the hardware? It's a layering issue, and
>> fundamentally, you must trust the server.
>>
>
> In the case of open-source (including hardware), I don't believe they
> require trust in the entity delivering the code (sorry Ken T.).  I can
> hypothetically trust my hardware, OS, and browser if the source code is
> audited, and because they live in my home under lock and key.  (Yes, it has
> to be audited all the way down, including compiler, microcode, etc.-- not
> saying it's easy.)  Auditing every website I might use is a much larger
> task.
>

I don't think we'll be able to have a reasonable debate on this, because in
the same sentence where you suggest it's entirely reasonable to audit your
hardware, OS, browser down to the microcode level, you cannot audit
Javascript for sites you browse.

I don't know how your economies-of-time work there, but there's no way we
can rationally engage here under that model.


>
>
>  If this hasn't been addressed, I think of two possible solutions, neither
>>> one very good:
>>>
>>> 1) Use a kind of "taint", where decrypted data and all data derived from
>>> it is prevented from being sent back to a server.
>>>
>>
>>> 2) Use HTML to define an element to display decrypted data, without
>>> allowing JS to access the content of that element.  Something like
>>>
>>>     <div id="mysecret" type="encrypted" algorithm="..." ...></div>
>>>
>>> ... and something similar for an input field that is to be encrypted
>>> before JS can access its data.
>>>
>>> Am I missing something, and has this been addressed?
>>>
>>> Thanks,
>>> James
>>>
>>>
>> This fundamentally does not work with the Web Security Model, and we are
>> not attempting to redefine the Web Security Model.
>>
>
> OK, not in scope.  Do you know a good link to the Web Security Model
> you're referring to (a web search fails me)?  I'd also be interested in how
> this fundamentally does not work with it.
>

Same Origin Policy. Anything that is in the same origin has the same
privilege level and capabilities. Core concept to the web. If you want
privilege separation, dropping, capabilities, you communicate across
origins.

However, it's quite simple, even without understanding anything about web
security:

You're running code. From someone you don't trust.
You cannot trust that code from someone you don't trust will do the things
it's supposed to. It's the halting problem applied to security.


>
>
> There are plenty of secure, robust ways to created this "Don't trust the
>> server" solution - using Apps/Extensions - but fundamentally, executing
>> code you're downloading from a server requires an element of trust in its
>> non-maliciousness.
>>
>
> Unless you sandbox it or otherwise restrict its capabilities to safe
> operations, as already happens with JS.
>

And you have that sandbox. It's called an origin. You have to trust *some*
origin. Whether it's an App/Extension *or* some crypto application.


>
>
> If this discussion has already been in another thread, let me know and I'm
> happy to review that.
>
> Thanks,
> James
>

The web does not sandbox you from yourself (that is, your origin). It lets
you sandbox yourself from others, it lets you defend against yourself, but
it doesn't protect your users from you messing up.

Put differently, you cannot combine an untrusted UI and a trusted UI into
the same origin. You can't. There are a million ways an evil server can get
you to screw up. The easiest being "Oh hey, I'm gonna encrypt this" - and
then doesn't. Or phishes you.

Good reading is http://tonyarcieri.com/whats-wrong-with-webcrypto to
understand