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

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Apr 2014 17:14:19 -0700

As I described briefly at the last meeting, ensuring that media is
isolated from the application or web site is a key part of addressing
our security goals.

The key part of that is making sure that any media that is isolated on
the sending side of RTCPeerConnection remains isolated when it reaches
the other side.

As I noted, this is also necessary in order to ensure the integrity of
the same origin model.  In that model, cross origin media is required
to be inaccessible to content, and as it stands RTCPeerConnection
could be used to work around those restrictions (implementations can
implement other protections, as Firefox already does).

The alternatives as I see them (and I hope that this is sufficiently
exhaustive) are:

 1. ask the TLS working group for a TLS-based solution
 2. build something into the session signaling (i.e., new SDP bits)
 3. give up on the idea

I prefer 1 for reasons already outlined.

I propose that we formally request the TLS working group recommend or
define a mechanism whereby we can signal in the TLS handshake that the
session contents are to be protected from access (where the
description of that protection may need to our responsibility).

I have pointed to draft-thomson-tls-acp as a potential solution here,
but others have noted that ALPN tokens could be used.  I expect that
TLS are capable of making the right decision here.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Apr 2014 18:51:24 -0700

> I prefer 1 for reasons already outlined.

Putting on my TLS hat, TLS already lets you send data across the
network securely. Why does this bit need to be treated differently
from all others?

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Apr 2014 19:29:48 -0700

Martin said:

"I have pointed to draft-thomson-tls-acp as a potential solution here,
but others have noted that ALPN tokens could be used."

Watson said:

"Putting on my TLS hat, TLS already lets you send data across the
network securely. Why does this bit need to be treated differently
from all others?

[BA] As Martin indicates, the desire for isolation needs to be communicated
to ensure that remote media is not misused.  With either of the TLS
approaches that Martin has suggested,  the desire for isolation is
communicated directly between the peers.   Having this occur E2E via media,
not hop-by-hop via signaling avoids the risk of a MITM preventing isolation
from being negotiated.

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.

On Thu, Apr 3, 2014 at 6:51 PM, Watson Ladd <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Apr 2014 19:49:33 -0700

> not hop-by-hop via signaling avoids the risk of a MITM preventing isolation

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.

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

Sincerely,
Watson Ladd

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Apr 2014 20:21:20 -0700

> On Apr 3, 2014, at 19:49, Watson Ladd <[email-masked]> wrote:
> 

[BA] The isolation request could be carried in an RTP header extension until, for example, a RR was obtained by the sender confirming it was received.  However, RTP extensions are optional and the sender wouldn't have confirmation from the receiver via the media plane that the isolation request was honored. So the TLS approach provides better semantics.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Apr 2014 20:25:21 -0700

> [BA] The isolation request could be carried in an RTP header extension until, for example, a RR was obtained by the sender confirming it was received.  However, RTP extensions are optional and the…

I feel this isn't worth changing TLS for, because you don't change
transports for each application because the application didn't do it
right the first time. But we have ALPN, so maybe a tag on that could
work. The right fix IMHO, is clearly to fix RTP to send this data and
keep the transport layer clean.

Sincerely,
Watson Ladd

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Apr 2014 20:25:51 -0700

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.

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2014 16:42:05 -0400

I'm confused by this, in at least a couple of respects:

- IIUC this isolation is a browser thing. If the other end doesn't
   have a browser then what does it mean?

- Isn't the isolation supposed to be on a per-stream basis?
   (Or is it really on a peer-connection basis.) If it is per-stream
   then how does signaling it on a per-TLS basis work?

- The use of DTLS to do SRTP keying is a sort of hack, since it
   isn't about the DTLS payload at all. I would think that whatever
   new you introduce into TLS for this would most naturally apply
   to the DTLS payload (the data channels).

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Apr 2014 13:50:44 -0700

Fair questions...

>   have a browser then what does it mean?

Yes, this is specific to a browser.  A non-browser peer would probably
respect this isolation property without any effort at all.  After all,
few non-browser applications permit the running of arbitrary,
remotely-source code in the way that a browser does.

>   then how does signaling it on a per-TLS basis work?

The question of scope is an important one.  The isolation property is,
at least at the most abstract layer, applicable to a MediaStreamTrack.
 I believe that the right approach is to broaden this scope to
RTCPeerConnection, where the identity controls exist.  This means that
you won't be able to mix isolated and non-isolated streams in the same
RTCPeerConnection.

>   to the DTLS payload (the data channels).

This is true only in the strictest academic or abstract sense.  We are
already taking things from the DTLS handshake and using those things
to make assertions about the properties of the SRTP.  Certificates.

Since you raise data channels, I'll note that we have no way to use
data channels in an isolated fashion.  Thus, I conclude that if we
intend to make this property consistent, we should not be using data
channels in the same RTCPeerConnection as media streams.  Of course,
I'm open to taking the pragmatists approach too, unless we think that
there is a use case for - say, file transfer - where it makes sense
for data to be isolated in the same way I'm proposing that media be.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 06 Apr 2014 14:37:08 -0400

> remotely-source code in the way that a browser does.

But ISTM there would need to be a different set of limitations for 
non-browsers. For instance, to not echo the stream back to the source. 
And not to store the stream in a place that the sender can retrieve.

Maybe it is possible to define a set of rules, but I don't have a vision 
of what that would be.

> you won't be able to mix isolated and non-isolated streams in the same

I'll wait to see what others have to say about this.
I haven't been able to wrap my head around it.

> for data to be isolated in the same way I'm proposing that media be.

Again I'm interested to hear what others have to say about this.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Apr 2014 10:02:55 +0200

> for data to be isolated in the same way I'm proposing that media be. 

Focusing on the "should we ever isolate data channels" question:

If we ever define a protocol carried *over* data channels that is 
interpreted in the browser, not in the Javascript, and exposes a 
different API to Javascript than the datachannel API, this might make sense.

In that case, I think we should investigate whether it's possible to 
make use of the "protocol" field (put some reserved values into it 
saying "for protocols that look like *this*, Javascript can't set 
them?), it's the logical place to say "this is datachannels, but with 
some extra rules".

Wild suggestion: if you want per-track isolation properties, open up a 
data channel with a protocol called '*WebRTCIsolationInfo' and use it to 
send information about the isolation status of each track, thereby also 
providing a working example for the rule 'all data channels that have 
protocols starting with "*" are for browser internal usage'.....

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Apr 2014 09:32:16 -0700

On 6 April 2014 11:37, Paul Kyzivat <[email-masked]> wrote:
> non-browsers. For instance, to not echo the stream back to the source. And
> not to store the stream in a place that the sender can retrieve.

Yes.  At the most abstract level, the requirements are the same.
Don't pass the media on to someone else.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Apr 2014 10:01:10 -0700

The subject is largely speculative, but when it comes to solutions,
the problem will not be a lack of options, but an inability to choose
a "right" one.

On 7 April 2014 01:02, Harald Alvestrand <[email-masked]> wrote:
> Wild suggestion: if you want per-track isolation properties, open up a data
> channel with a protocol called '*WebRTCIsolationInfo' and use it to send
> information about the isolation status of each track, thereby also providing
> a working example for the rule 'all data channels that have protocols
> starting with "*" are for browser internal usage'.....

I assume that you are talking PPID here.  Given that it's off limits
for JavaScript currently, then it does provide an opportunity for this
communication.  The problem there is that you need to spin up data
channels, even if the application has no need of them.  That's a
fairly high cost.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 7 Apr 2014 17:07:00 +0000

> From: rtcweb [mailto:[email-masked]] On Behalf Of Martin
> Thomson
>...  The problem there is that you need to spin up data
> channels, even if the application has no need of them.  That's a fairly high
> cost.

But only because the working group chose poorly for how data channels are transported.

Matthew Kaufman

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Apr 2014 10:11:29 -0700

On 7 April 2014 10:07, Matthew Kaufman (SKYPE)
<[email-masked]> wrote:
> the working group chose poorly

Yes, thanks.

That seems to be a pattern.  It's just not always obvious immediately.

Sometimes it doesn't matter.  Especially when you haven't noticed yet.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Apr 2014 19:20:47 +0200

> channels, even if the application has no need of them.  That's a
I was actually thinking "protocol" as in the string that goes into the 
datachannel setup packets. PPIDs would work too for separating 
browser-to-brower from app-to-app, but I wasn't thinking of them.

Yes, data channels do cost something to set up. But we're already paying 
the DTLS tax in order to set up the keying, so it's "just" another 
request/response. How many extra round trips does the SCTP setup add?

(Would need the response in order to make sure the respondent gave the 
promise to obey isolation, I think.)

(and to Matthew: At least we wouldn't have *yet* another congestion 
context to manage, which would be the case with a separate TCP 
connection. There are always tradeoffs.)

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Apr 2014 10:23:05 -0700

> browser-to-brower from app-to-app, but I wasn't thinking of them.

That would require carving out a space to use right now.  That
impinges to much on application autonomy for my liking.

> Yes, data channels do cost something to set up. But we're already paying the
> DTLS tax in order to set up the keying, so it's "just" another

2.

> (and to Matthew: At least we wouldn't have *yet* another congestion context to
> manage, which would be the case with a separate TCP connection. There are
> always tradeoffs.)

I'm certain that Matthew wasn't talking about TCP.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 7 Apr 2014 17:27:14 +0000

From: rtcweb [mailto:[email-masked]] On Behalf Of Harald
> Alvestrand
>...
> context to manage, which would be the case with a separate TCP connection.
> There are always tradeoffs.)

If it was me (and at one time, it was) I would use a protocol that allows for multiplexing and prioritization of media and data channels over the same secure session with shared congestion state. Over such a protocol, opening another data stream for this purpose could be done immediately without even a round trip.

RFC 7016 documents such an approach.

Matthew Kaufman

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 7 Apr 2014 19:38:09 +0200

>> request/response. How many extra round trips does the SCTP setup add?
Right now: Correct. But one could optimise the initial handshake...

Best regards
Michael

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Apr 2014 11:00:43 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Apr 2014 11:08:27 -0700

On 7 April 2014 11:00, Bernard Aboba <[email-masked]> wrote:
> 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.

The usual behaviour is to use the same 5-tuple for sending SRTP as the
one used for the DTLS handshake.  However, if the extracted keys from
the DTLS session is used to key different SRTP flows on other
5-tuples, then I suppose that the conditions attached to the DTLS
session would have to apply to those separate flows too.  That means
isolation, authentication, and whatever else we bind in.

I'm not sure that I'd do that, given the risks of things like SSRC
reuse, but maybe I'm misunderstanding the question.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Apr 2014 15:21:32 -0400

> RFC 7016 documents such an approach.

I see that the title starts with "Adobe's". Sigh.

If you want to entertain something other than existing solutions for 
media, why not simply run the RTP media streams over SCTP along with the 
data channels?

	Thanks,
	Paul

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 7 Apr 2014 19:27:11 +0000

-----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Monday, April 7, 2014 12:22 PM
> To: [email-masked]
> Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with
> media isolation)
> 
> > If it was me (and at one time, it was) I would use a protocol that allows for
> multiplexing and prioritization of media and data channels over the same
> secure session with shared congestion state. Over such a protocol, opening
> another data stream for this purpose could be done immediately without
> even a round trip.
> >

Yes, but there's little stopping many of these ideas from becoming the basis for an IETF-developed transport protocol that actually meets the needs we have here.
 
> If you want to entertain something other than existing solutions for media,
> why not simply run the RTP media streams over SCTP along with the data
> channels?

Except for some critical shortcomings of SCTP (which are being fixed), this isn't actually a terrible idea.

Matthew Kaufman

---

From: Mary Barnes <[email-masked]>
Date: Mon, 7 Apr 2014 14:32:08 -0500

On Mon, Apr 7, 2014 at 2:27 PM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

> Yes, but there's little stopping many of these ideas from becoming the
> basis for an IETF-developed transport protocol that actually meets the
> needs we have here.
>

[MB] Except, maybe, IPR:

https://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-thornburgh-adobe-rtmfp
[/MB]

> media,

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 7 Apr 2014 19:39:22 +0000

[MB] Except, maybe, IPR: 

Conveniently, RTMFP was preceded by an open-source project which had no patents filed. so to the extent the "ideas" are present there (and many of them are), that's easily worked around, if one needed a starting place.

But my point wasn't to start discussing the merits of the specific approach described in that particular RFC... rather to note that the cobbled-together collection of choices that have been made, specifically gluing SCTP on to the side of RTCWEB as a way of transporting data, is highly suboptimal and that other solutions do exist.

In fact, simply allowing the data we need to be sent unsolicited as another SRTP stream would be an improvement over doing 2 round trips of SCTP setup for the problem space we are discussing in this thread.

Matthew Kaufman

---

From: Michael Thornburgh <[email-masked]>
Date: Mon, 7 Apr 2014 20:56:55 +0000

> From: rtcweb [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: Monday, April 07, 2014 12:32 PM
> 
> On Mon, Apr 7, 2014 at 2:27 PM, Matthew Kaufman (SKYPE) <[email-masked]> wrote:
> 
> 	Yes, but there's little stopping many of these ideas from becoming the basis for an IETF-
> developed transport protocol that actually meets the needs we have here.
> 
> [MB] Except, maybe, IPR:

we would love for RTMFP to become the basis for an IETF-developed standard transport protocol.  and as far as using RTMFP as-is, note section VI of the (most recent) above-referenced IPR disclosure: "Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers."  we think it's pretty good already and published it (among other reasons) in the hopes that others would find new uses for it.

> 	Except for some critical shortcomings of SCTP (which are being fixed), this isn't actually a

except for the critical shortcomings of SCTP (for real-time communications) that aren't being fixed.

> 	Matthew Kaufman

-michael thornburgh

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Apr 2014 11:42:25 +0000

Hi,

>Don't pass the media on to someone else.

How would that work with an intermediary mixer, transcoder, etc?

Regards,

Christer

---

From: Dan Wing <[email-masked]>
Date: Tue, 8 Apr 2014 09:33:37 -0700

> How would that work with an intermediary mixer, transcoder, etc?

Or voicemail or an audio conference.

-d

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Apr 2014 09:50:55 -0700

Christer said:

"How would that work with an intermediary mixer, transcoder, etc."

[BA] I'm not sure that the concept of "isolation" makes sense for those
intermediaries (or to voicemail or an audio/video conference, for that
matter).   While in a point-to-point call it might be useful, in a
conference the whole point is to have audio/video sent to multiple parties,
and recording is commonplace.  The problem is that from a protocol point of
view the cases are not easily distinguishable -- and so if the browser
insists on "isolation" then one wonders what will happen if the conference
bridge/video MCU/voicemail system refuses to negotiate it.   Refusing to
send media would not be a desirable outcome.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Apr 2014 11:24:03 -0700

> send media would not be a desirable outcome.

I think that for this, it's perfectly reasonable to use identity, but
not stream isolation.  With isolation, if the peer does not agree to
comply, then the session fails to complete.

The authenticated party here is an MCU (or bridge, or voicemail,
etc...).  Rather than sending to "[email-masked]", media is
sent to "[email-masked]".  Is it reasonable for that MCU to forward
media to other, unspecified entities?  Clearly it can, but should it?

(Not having thought it through completely, a voicemail box could
conceivably work.  I think that I'd want to use a different identity
for it though.)

---

From: Dan Wing <[email-masked]>
Date: Tue, 8 Apr 2014 12:41:19 -0700

> conceivably work.  I think that I'd want to use a different identity

For voicemail, there was a proposal in 2009 for doing what amounted to object security, http://tools.ietf.org/html/draft-naslund-srtp-saf.  That document's last update was in 2011 but I don't know if it evolved into a product or died out or what.

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Apr 2014 10:56:02 +0200

> comply, then the session fails to complete.
Actually I'd say it's "if the peer does not *agree to* comply".
The protocol has no defense against liars, but that's a common issue.
> conceivably work.  I think that I'd want to use a different identity

I can see an use for a recording spec that said "you can record this, 
but only if you do it in such a way that it's only accessible to the 
stated identity".

Would be weird to try to enforce that.... but I agree; MCU and isolation 
have a hard time mixing.
Let's just not.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2014 10:51:43 -0400

> Would be weird to try to enforce that.... but I agree; MCU and isolation

So what does this mean for screen sharing with a conference?

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Apr 2014 12:31:49 -0700

> The protocol has no defense against liars, but that's a common issue.

That's precisely what I said, sans emphasis :)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Apr 2014 12:33:45 -0700

> So what does this mean for screen sharing with a conference?

It means the same thing, if the stream is isolated, it will not be
possible to share with a conference MCU.

(You can go full mesh to retain good isolation, but that requires
multiple differently isolated streams, and it's likely to annoy the
user with gUM prompts.)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2014 17:30:05 -0400

> multiple differently isolated streams, and it's likely to annoy the

Well, apparently it will be at the discretion of the conference focus. 
Since it presumably doesn't have a browser, it will only be governed by 
its own policies and whatever normative statements are made about the 
behavior of servers in this case.

There will be a business motivation to allow such sharing if a rationale 
can be made that it is allowed.

So that puts a premium on clear normative statements.

	Thanks,
	Paul