Re: [rtcweb] Asking TLS for help with media isolation

[Martin Thomson <[e-mail]>]

Perhaps some more context is necessary.

(D)TLS provides us good protection against network attackers.  The
problem is that this protection ends at the browser, and our security
story doesn't.  Media streams in the browser are an extension of those
that traverse the network, and we need something of a gentlemen's
agreement between browsers to be reached.  That agreement says that
your browser and mine will agree between themselves to protect media
from the application that is running in their sandbox: all that nasty
JavaScript that came from a site (or sites) that we might not want to
include in our conversation.

On 3 April 2014 19:49, Watson Ladd <[e-mail]> wrote:
> The MITM can kill any TLS connection containing the extension. My
> understanding is that signalling data is immutable, hence the need to
> ask the browser to generate it.

Signaling is totally mutable, which is a big problem.  Once an
application gets it, there's a lot that can be changed between peers.

>> However once the desire for isolation is communicated E2E (either via ACP or
>> ALPN tokens), there is nothing in the SRTP traffic (keyed by DTLS/SRTP) that
>> indicates that the traffic is to be isolated.
>
> I don't see why the isolation status cannot be included as an
> extension to SRTP. You aren't asking TLS to make extensions for video
> resolution and codec after all.

That's a good question, and it's an option I should have added to the
list.  The problem there is that nothing in RTP is reliable, and this
signal needs to be reliable.  Combine that with the fact that the
extent of an RTP session is essentially unknowable, and you end up
having to put an RTP header extension on every packet.  RTP header
extensions have other drawback as well, though I suspect most of those
aren't applicable in this context.

With the TLS handshake, you either get a marked session, or you don't
get a session at all.  That's a big advantage with this approach.  And
it costs far fewer bytes.