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

[Bernard Aboba <[e-mail]>]

Martin said:

"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."

[BA] Agreed.  To be clear, the "marked session" we are talking about is the
DTLS session.  All DTLS/SRTP sessions subsequently occurring within that
DTLS marked session inherit the "isolation" property, correct?

The implication here is that not only do media sharing the same DTLS
session (e.g. audio and video multiplexed on the same port) share the
"isolation" property, but even if audio and video are not multiplexed, if
the same DTLS session is used by subsequent DTLS/SRTP sessions, then the
"isolation" property is also shared.

>From RFC 5764, Section 3:

   RTP and RTCP traffic MAY be multiplexed on a single UDP port
   [RFC5761 <http://tools.ietf.org/html/rfc5761>].  In this case, both
RTP and RTCP packets may be sent over
   the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions
   needed.  This improves the cryptographic performance of DTLS, but may
   cause problems when RTCP and RTP are subject to different network
   treatment (e.g., for bandwidth reservation or scheduling reasons).

   Between a single pair of participants, there may be multiple media
   sessions.  There MUST be a separate DTLS-SRTP session for each
   distinct pair of source and destination ports used by a media session
   (though the sessions can share a single DTLS session and hence
   amortize the initial public key handshake!).







On Thu, Apr 3, 2014 at 8:25 PM, Martin Thomson <[e-mail]>wrote:

> 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.
>