Re: [MIX]: Expand scope beyond TLS/non-TLS (Re: "Mixed Content" draft up for review.)

> On 9 Jun, 2014, at 14:37, Zack Weinberg <zackw@cmu.edu> wrote:
> Thinking out loud:
> Presupposition: as far the reference monitor in the browser is
> concerned, communication is with the phone.  More precisely, if the
> websockets channel were to be secured, you would terminate TLS on the
> *phone*, not the watch, and rely on Bluetooth link encryption to
> protect that dialogue.  Is that right, Katherine?  (I bring this up
> mainly because pretending the watch doesn't exist simplifies reasoning
> from the browser's perspective, but also because the phone is probably
> capable of doing more work if we need it to, whereas the watch might
> not be.)


This is correct - the watch is here primarily as justification for
“why we want to do this” and can be ignored for most purposes here.
TLS would terminate on the phone (which has ~arbitrary resources to
handle these things) and bluetooth link encryption, which we already
do, would cover it the rest of the way. We would do TLS already if
we didn’t have the obvious certificate naming/signing issue.

> This monkeywrenches our way around the inability to assign a "real"
> TLS server certificate to a host with no global DNS name.  It also
> protects Device from malicious websites other than the Mothership that
> it registered itself with (which it trusts, by assumption).  I know
> all too well that it's going to be a PITA to implement in the browser,
> but I don't see anything simpler that gives us the security properties
> we need.
> 
> Katharine: How infeasible would the Device/Mothership behavior here be
> for Pebble to implement?  (Assume all the browser APIs you need are
> present.)

That all looks relatively easy for us to do (relative to "everything is
broken forever", at any rate). It is (mostly) fair to assume that
Device can act as a web client to Mothership. Much of the necessary
infrastructure for registration and setup is in place (modulo
certificate generation), and some cursory investigation suggests that
the Device’s role in the handshake could be feasibly implemented.

I think we would prefer this proposal, or something like it, over both
the current, insecure state and one in which we’re forced to hack TLS
on in an almost pointlessly insecure manner (though given the current
and imminent state of browsers, we’re probably going to have to
do that anyway...). 

– Katharine