Subject: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Aug 2014 17:08:41 -0400

CLUE people should review draft-ietf-rtcweb-alpn-00. It has some 
implications for us.

It defines some two specific ALPN protocol names for use with webrtc. 
These are used during DTLS initialization, and identify the application 
layer protocol running on top of DTLS.

If we are to be interoperable with webrtc, then it seems clue 
implementations will be required to follow this draft.

The two ALPN names defined are:
- webrtc
- c-webrtc

The value "c-webrtc" is used when "confidential" media streams are being 
conveyed. IIUC this is mostly a browser issue. The draft says:

    Private communications in WebRTC depend on separating control (i.e.,
    signaling) capabilities and access to media
    [I-D.ietf-rtcweb-security-arch].  In this way, an application can
    establish a session that is end-to-end confidential, where the ends
    in question are user agents (or browsers) and not the signaling
    application.

    A browser is required to enforce this control using isolation
    controls similar to those used in cross-origin protections.  These
    protections ensure that media is protected from applications.
    Applications are not able to read or modify the contents of a
    protected flow of media.  Media that is produced from a session using
    the "c-webrtc" identifier MUST only be displayed to users.
...
    RTP middleboxes and entities that forward media or data cannot
    promise to maintain confidentiality.  Any entity that forwards
    content, or records content for later access by entities other than
    the authenticated peer, MUST NOT offer or accept a session with the
    "c-webrtc" identifier.

I don't know how to interpret this in the CLUE context.

The simple answer would be to only define CLUE for use with "webrtc" as 
the ALPN, and leave support of "c-webrtc" undefined for now.

Or possibly we should not discuss the ALPN at all. But I fear that will 
lead to interop problems.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Aug 2014 11:15:36 +1000

Hello Paul,

As I've raised on the WebRTC list its not clear to me that either an 
alpn of webrtc or c-webrtc is correct for CLUE as the definition of 
these indicates the presence webrtc media and datachannel. CLUE may be 
used in environments where WebRTC controlled media is NOT used. Sending 
an alpn with 'webrtc' for a datachannel only case doesn't seem correct.

Christian

On 8/08/2014 7:08 AM, Paul Kyzivat wrote:
> These are used during DTLS initialization, and identify the 
> application layer protocol running on top of DTLS.
>
> The value "c-webrtc" is used when "confidential" media streams are 
> being conveyed. IIUC this is mostly a browser issue. The draft says:
>
> The simple answer would be to only define CLUE for use with "webrtc" 
> as the ALPN, and leave support of "c-webrtc" undefined for now.
>
> Or possibly we should not discuss the ALPN at all. But I fear that 
> will lead to interop problems.
>
>     Thanks,
>     Paul
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Aug 2014 22:26:07 -0400

> an alpn with 'webrtc' for a datachannel only case doesn't seem correct.

That argument applies equally to webrtc itself. There will no doubt be 
webrtc applications that only use the data channels, not the media streams.

Note that I did post a query to the rtcweb list asking about use of 
other ALPN ids with WebRTC.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 12 Aug 2014 11:08:37 +1000

Hello Paul,

I guess this relates to your comments about data channel being a general 
purpose mechanism and not a "webRTC" specific one. I think its fair for 
a WebRTC device/browser only using data channels to assert an ALPN with 
"webrtc" or "c-webrtc". But if there's a non-webrtc device e.g. a CLUE 
endpoint using data channel is that still really "webrtc"?

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Aug 2014 12:57:14 -0400

> endpoint using data channel is that still really "webrtc"?

I think we need to distinguish between the behavior and the name that is 
attached to the behavior.

We want some of the behavior specified in webrtc and rtcweb specs, for 
multiple reasons. In some cases we want it in order to enable 
interoperation with devices that are constrained by webrtc. We also want 
some features that happen to have been defined as part of webrtc, 
without regard to interoperation with webrtc. And further, if we need to 
behave one way when interoperating, then it is convenient to specify 
that we will also operate that way when not interoperating, just to keep 
things simple.

To achieve those things, we end up needing to use some of the names for 
things that webrtc is choosing. My *preference* is to convince them to 
use generic (non-webrtc-specific) names for things that have broader 
applicability. But if we loose those battles then so be it - they are 
just names, even if stupid ones. Using them doesn't prevent us for doing 
what we need to do. It just presents an additional documentation challenge.

While we could conceivably use different names depending on context, 
that is likely to just make things more complex.

Somebody did suggest that as a client we could offer alternative alpn 
values, and let the server choose one. So we could offer both "clue" and 
"webrtc", and be happy with either of them being accepted. And we could 
act exactly the same in both cases. But that buys us the obligation to 
define what it means when the "clue" alpn is used. That is extra work 
for us.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 12 Aug 2014 15:53:48 -0500

On Tue, Aug 12, 2014 at 11:57 AM, Paul Kyzivat <[email-masked]>
wrote:

> some features that happen to have been defined as part of webrtc, without
> regard to interoperation with webrtc. And further, if we need to behave one
> way when interoperating, then it is convenient to specify that we will also
> operate that way when not interoperating, just to keep things simple.
>
> things that webrtc is choosing. My *preference* is to convince them to use
> generic (non-webrtc-specific) names for things that have broader
> applicability. But if we loose those battles then so be it - they are just
> names, even if stupid ones. Using them doesn't prevent us for doing what we
> need to do. It just presents an additional documentation challenge.
>
> While we could conceivably use different names depending on context, that
> is likely to just make things more complex.
>
> "webrtc", and be happy with either of them being accepted. And we could act
> exactly the same in both cases. But that buys us the obligation to define
> what it means when the "clue" alpn is used. That is extra work for us.
>
[MB] As an individual, I don't see CLUE defining another alpn value to be a
negative.  I think it adds clarity and can help us avoid confusion.
Documenting what it means when "clue" alpn is used is a good thing IMHO, as
we really should describe how alpn works for CLUE regardless of the alpn
value.[/MB]

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Aug 2014 12:31:50 +1000

Please see my comments below.

Regards, Christian

On 13/08/2014 6:53 AM, Mary Barnes wrote:
>
>
>
> On Tue, Aug 12, 2014 at 11:57 AM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think we need to distinguish between the behavior and the name
>     that is attached to the behavior.
>
>     We want some of the behavior specified in webrtc and rtcweb specs,
>     for multiple reasons. In some cases we want it in order to enable
>     interoperation with devices that are constrained by webrtc. We
>     also want some features that happen to have been defined as part
>     of webrtc, without regard to interoperation with webrtc. And
>     further, if we need to behave one way when interoperating, then it
>     is convenient to specify that we will also operate that way when
>     not interoperating, just to keep things simple.
>
[CNG] I agree that we need some behaviour. I'm generally not fussed with 
names. In behaviour terms it seems strange to offer an ALPN that 
indicates the behaviour of "webrtc- the DTLS session is used to 
establish keys for a Secure Real-time Transport Protocol (SRTP) - known 
as DTLS-SRTP - as described in [RFC5764]." when for CLUE usage (outside 
WebRTC) the use of SRTP is not the case.
>
>
>     To achieve those things, we end up needing to use some of the
>     names for things that webrtc is choosing. My *preference* is to
>     convince them to use generic (non-webrtc-specific) names for
>     things that have broader applicability. But if we loose those
>     battles then so be it - they are just names, even if stupid ones.
>     Using them doesn't prevent us for doing what we need to do. It
>     just presents an additional documentation challenge.
>
[CNG] Preferably it would be good to use just "data channel" for the name.

I think it could easily be solved by adding an ALPN just for data channel:
datcha: The DTLS record layer is used for WebRTC data channels 
[I-D.ietf-rtcweb-data-channel].

>
>     While we could conceivably use different names depending on
>     context, that is likely to just make things more complex.
>
>     Somebody did suggest that as a client we could offer alternative
>     alpn values, and let the server choose one. So we could offer both
>     "clue" and "webrtc", and be happy with either of them being
>     accepted. And we could act exactly the same in both cases. But
>     that buys us the obligation to define what it means when the
>     "clue" alpn is used. That is extra work for us.
>
> [MB] As an individual, I don't see CLUE defining another alpn value to 
> be a negative.  I think it adds clarity and can help us avoid 
> confusion. Documenting what it means when "clue" alpn is used is a 
> good thing IMHO, as we really should describe how alpn works for CLUE 
> regardless of the alpn value.[/MB]
[CNG] I think we need to take a step back on this and look from the 
general case. The ALPN mechanism allows the specification of multiple 
protocols and the selection of one. An endpoint could advertise "webrtc" 
and "clue" but does the selection of "webrtc" really indicate CLUE 
support? What happens if the endpoint uses data channel for multiple 
protocols i.e. CLUE and BFCP? The server chooses one, so how does it 
indicate CLUE AND BFCP? It could use an ALPN for datachannel but that's 
not being defined. With the current values the server would have to 
choose webrtc. Implying support of SRTP when its not actually used. Its 
going to get messy when specifying multiple "application" protocols.

>             webrtc applications that only use the data channels, not
>             the media
>             streams.
>
>                        protected flow of media.  Media that is
>                     produced from a session
>                     using
>                     [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Aug 2014 15:19:46 -0400

> WebRTC) the use of SRTP is not the case.

AFAIK we do allow clue captures to share to be bundled with the SCTP. I 
can imagine that some implementations will prefer to do it that way. And 
the use of the ALPN for one DTLS session says nothing about what happens 
on other unbundled m-lines.

Note what else ALPN is used to denote - HTTP vs SPDY. Those aren't 
applications either.

AFAICT, the behavior being negotiated is behavior that can/should be the 
same between clue and webrtc.

I don't like the name, but neither do I want to invent another name and 
have two different behaviors.

> [CNG] Preferably it would be good to use just "data channel" for the name.

I have proposed using data-channel instead of webrtc-datachannel on the 
m-line for sctp.

But data-channel seems wrong here because it is about more than that - 
about SRTP as well.

> [I-D.ietf-rtcweb-data-channel].

Then that would presumably forbid bundling media with it. Why would we 
want to forbid that?

> protocols and the selection of one.

Yes. Unfortunately it seems to not be very clear about what it means to 
select one or another. Exactly what is it that you are selecting?

> An endpoint could advertise "webrtc"
> support?

Why should it? We have other mechanisms to indicate clue support. For 
this to be used with clue the m-line needs to be in the clue group.

> What happens if the endpoint uses data channel for multiple
> indicate CLUE AND BFCP?

This just further points out the confusion about what an ALPN does and 
doesn't name. And it should be possible for a webrtc browser to be a 
clue client and use the SCTP association for both a clue channel and a 
bfcp channel.

I guess it would be clearer if we were just trying to negotiate what 
DTLS payload is being used for. The answer to that is SCTP. But that is 
already known from the SDP. I suspect this ALPN thing may be an artifact 
for cases where there is no SDP negotiation.

> It could use an ALPN for datachannel but that's

I have run out of things to say.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 14 Aug 2014 10:39:05 +1000

Hello Paul,

Please see below.

Regards, Christian

On 14/08/2014 5:19 AM, Paul Kyzivat wrote:
> AFAIK we do allow clue captures to share to be bundled with the SCTP. 
> I can imagine that some implementations will prefer to do it that way. 
> And the use of the ALPN for one DTLS session says nothing about what 
> happens on other unbundled m-lines.
>
> AFAICT, the behavior being negotiated is behavior that can/should be 
> the same between clue and webrtc.
[CNG] CLUE only requires the use of data channel. It can be used by 
WebRTC devices and any other sort of devices. These devices can use 
bundling, RTP, SRTP etc. The part that is problematic for me is that the 
APLN indicates the DTLS is used for SRTP. For many devices where CLUE is 
used this will not be the case.

>
> I don't like the name, but neither do I want to invent another name 
> and have two different behaviors.
>
> I have proposed using data-channel instead of webrtc-datachannel on 
> the m-line for sctp.
>
[CNG] Yes that's why I think there needs to be a separate value for 
data-channel where SRTP is not involved.
> Then that would presumably forbid bundling media with it. Why would we 
[CNG] If you want to bundle media and use SRTP then use the ALPN 
"webrtc". If you only want to use a data channel and transmit media via 
another connection use "datachannel".

> Yes. Unfortunately it seems to not be very clear about what it means 
> to select one or another. Exactly what is it that you are selecting?
>
[CNG] I agree. That's why I don't think adding a "CLUE" ALPN is going to 
help.
> DTLS payload is being used for. The answer to that is SCTP. But that 
> is already known from the SDP. I suspect this ALPN thing may be an 
> artifact for cases where there is no SDP negotiation.
[CNG] I agree.