Re: HbbTV 2.0 Specification Announcement

Security for the messaging channel vs. the security status of the
controlling and presenting origins is an interesting topic.  We've had some
preliminary discussions in Chrome about this, but nothing firm enough to
propose, so I'm glad to have an opportunity to discuss this in the group.

On Mon, Apr 20, 2015 at 5:13 AM, Francois Daoust <fd@w3.org> wrote:

> On 2015-04-17 17:42, Matt Hammond wrote:
> [...]
>
>> Note that there may be ways for a user agent to establish a secure
>>> communication channel with a device, for instance following a similar
>>> mechanism to that described for the Named Web Sockets proposal [3].
>>>
>>
>> Thanks for the reference, I'll read it properly, but after a first glance
>> through, my initial question would be how to keep the password secret if
>> (presumably) it would be provided by the HTML application?
>>
>
> I do not know. I was more pointing at that mechanism as food for thought :)
>
>
>
>>  I do not know how this could work for existing devices, though. Did I
>>> miss something obvious? Is there a simple solution?
>>>
>>
>>  I'll create an issue on GitHub to track this down otherwise. This is not
>>> specific to HbbTV.
>>
>>
I will do this now.


>
>>
>>
>>
>> Agreed, this is a more general issue that if you are establishing
>> communication with another entity, how can you trust that other party on
>> the home network? You might send a request that they load a particular URL
>> but you take it on trust that they do. You could argue that any
>> communication via the messaging API in the presentation API is cannot be
>> trusted.
>>
>
> Perhaps! It might also be useful to look at WebRTC that enables a similar
> "communication with another entity" feature. The latest draft of the WebRTC
> security architecture forbids plain (unencrypted) data and media traffic
> altogether:
>
>
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#section-5.5


In general the client-server security architecture for WebSockets that is
based on TLS, DNS and certificate authorities does not work well for
peer-to-peer communication scenarios.

WebRTC relies on mandatory encryption (to prevent eavesdropping) and a
third party identity oracle (to authenticate both sides).  Other solutions
are possible as well;  I will look at the named WebSockets proposal in more
detail.

I don't think the spec should mandate a specific solution, but I do think
we need to put some requirements in place for communication between secure
(https) origins that is consistent with the Mixed Content proposal.

m.