Subject: [rtcweb] How to determine TLS roles?

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 13:29:48 +0000

Hi,

If I understand correctly, in RTCWEB we are going to use a single DTLS association for two things:

1)      Key exchange for SRTP

2)      The data channel

Now, this means that there needs to be a generic way to determine the TLS roles.

In WEBRTC, how are the TLS roles determined?

Regards,

Christer

---

From: Tim Panton <[email-masked]>
Date: Mon, 10 Feb 2014 13:45:33 +0000

> In WEBRTC, how are the TLS roles determined?

That was the subject of a rant of mine.

I think the correct answer is that the party that ends up being IceControlling then becomes the
DTLS client. Typically the initiator of a session is IceControlling. 

However the recent addition of 
a=setup:passive 
to chrome's SDP clouds the story somewhat, allowing an IceController to say that it is DTLS passive
and allow the non-initiator to be the DTLS client.

Ostensibly this is to support early media - where the receiver of a call wishes to send media before the
initiator does.

As I said (rather intemperately) this added complexity is not worth the benefit.

Tim.

http://webrtchacks.com/tim-rant/

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

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 13:51:44 +0000

Hi,

> I think the correct answer is that the party that ends up being IceControlling then becomes the DTLS client. Typically the initiator of a session is IceControlling. 
>
> to chrome's SDP clouds the story somewhat, allowing an IceController to say that it is DTLS passive and allow the non-initiator to be the DTLS client.
>
> Ostensibly this is to support early media - where the receiver of a call wishes to send media before the initiator does.
>

I think that it should be possible for a JS App to explicitly set the roles.

Because, when SDP O/A is used on the wire, there are specified rules on how the roles are determined. But, some other on-the-wire protocol may have different rules.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 14:23:54 +0000

Hi,

> There are many things that the JS app will need to do if we aren't bound by SDP O/A - but I agreed not to talk about that - until after 1.0 gets out :-)

Fair enough, but for 1.0 we still need to know how the roles are determined :)

The security-arch document does say that a DTLS handshake is performed on each channel that has been established by ICE, but I don't find anything regarding the roles.

Regards,

Christer

---

From: Tim Panton <[email-masked]>
Date: Mon, 10 Feb 2014 14:14:19 +0000

> Because, when SDP O/A is used on the wire, there are specified rules on how the roles are determined. But, some other on-the-wire protocol may have different rules.

There are many things that the JS app will need to do if we aren't bound by SDP O/A - but I agreed not to talk about that -
until after 1.0 gets out :-)

T.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Feb 2014 06:48:13 -0800

This is defined in RFC 5763 S 5:
http://tools.ietf.org/html/rfc5763#section-5

Which points to:
http://tools.ietf.org/html/rfc4145

-Ekr

On Mon, Feb 10, 2014 at 6:23 AM, Christer Holmberg <
[email-masked]> wrote:

> >>> I think the correct answer is that the party that ends up being
> IceControlling then becomes the DTLS client. Typically the initiator of a
> session is IceControlling.
> >>>
> >>> to chrome's SDP clouds the story somewhat, allowing an IceController
> to say that it is DTLS passive and allow the non-initiator to be the DTLS
> client.
> >>>
> >>> Ostensibly this is to support early media - where the receiver of a
> call wishes to send media before the initiator does.
> >>>
> >> Because, when SDP O/A is used on the wire, there are specified rules on
> how the roles are determined. But, some other on-the-wire protocol may have
> different rules.
> >>
> > There are many things that the JS app will need to do if we aren't bound
> by SDP O/A - but I agreed not to talk about that - until after 1.0 gets out
> :-)
>
> The security-arch document does say that a DTLS handshake is performed on
> each channel that has been established by ICE, but I don't find anything
> regarding the roles.
>
> Regards,
>
> Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 16:37:39 +0000

Hi,

>http://tools.ietf.org/html/rfc4145

Ok. So, a few questions to for clarification:

Q1: This means that the JS App must set the setup attrbute value before passing an SDP to the browser?

Q2: If SDP O/A is not used on the wire, there needs to be another mechanism for the peers to negotiate/indicate who is "active" and who is "passive"?

Q3: If you have mulitple m- lines, all using the same DTLS association, the setup attribute value must be identical in all m- lines?

Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using the setup attribute value) as DTLS/SRTP for determining the TLS role?

Regards,

Christer

On Mon, Feb 10, 2014 at 6:23 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

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

---

From: Tim Panton <[email-masked]>
Date: Mon, 10 Feb 2014 17:39:46 +0000

> Q1: This means that the JS App must set the setup attrbute value before passing an SDP to the browser?
No, peer-to-peer browser calls should 'do the right thing' - based on the initator/ice-controlling rule 
Both browsers set 
a=setup:act-pass
meaning that we fall back to the old rules.

> Q2: If SDP O/A is not used on the wire, there needs to be another mechanism for the peers to negotiate/indicate who is "active" and who is "passive"?
If you don't care, and are locally generating the SDP for a remote offer or answer, set 
a=setup:act-pass 
and the roles sort themselves out.

If however you have a gateway initating a call to a browser, and it wants to do early media (it's an 800 number gateway for example)
then it sets  
a=setup:active

in the SDP it sends (or you create on it's behalf).

> Q3: If you have mulitple m- lines, all using the same DTLS association, the setup attribute value must be identical in all m- lines?

Yes, I think so.

> Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using the setup attribute value) as DTLS/SRTP for determining the TLS role?

That's the way chrome seems to implement it - and presumably the way the spec is intended.

T.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 20:03:03 +0000

Hi,

> No, peer-to-peer browser calls should 'do the right thing' - based on the initator/ice-controlling rule Both browsers set a=setup:act-pass meaning that we fall back to the old rules.

What "old rules"? :)

> If you don't care, and are locally generating the SDP for a remote offer or answer, set a=setup:act-pass and the roles sort themselves out.

According to the "old rules", right? :)

>If however you have a gateway initating a call to a browser, and it wants to do early media (it's an 800 number gateway for example) then it sets a=setup:active

There doesn't necessarily have to be a gateway. It may be a browser-to-browser call, using SIP and SDP O/A on the wire - meaning that the SDP setup attribute is used to determine the roles.

> That's the way chrome seems to implement it - and presumably the way the spec is intended.

Ok.

Regards,

Christer

---

From: Tim Panton <[email-masked]>
Date: Mon, 10 Feb 2014 20:22:09 +0000

>> No, peer-to-peer browser calls should 'do the right thing' - based on the initator/ice-controlling rule Both browsers set a=setup:act-pass meaning that we fall back to the old rules.

Sorry that was unclear - As I read it, putting 
a=setup:actpass 
in the SDP indicates that the ice-controlling entity should act as DTLS client, and typically the ice-controlling entity is the initiator of the session. So it isn't a matter of O/A negotiation.

> According to the "old rules", right? :)

Yeah, Ice controlling is the DTLS client. 

> There doesn't necessarily have to be a gateway. It may be a browser-to-browser call, using SIP and SDP O/A on the wire - meaning that the SDP setup attribute is used to determine the roles.

But there is no concept of early media on a peer-to-peer webRTC call, so there isn't any need to manage which side is the DTLS client or server.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 20:30:50 +0000

Hi,

> Sorry that was unclear - As I read it, putting a=setup:actpass in the SDP indicates that the ice-controlling entity should act as DTLS client, and typically the ice-controlling entity is the initiator of the session. So it isn't a matter of O/A negotiation.

Do you have a reference to where you read that?

>>> If however you have a gateway initating a call to a browser, and it 
>>> wants to do early media (it's an 800 number gateway for example) then it sets a=setup:active in the SDP it sends (or you create on it's behalf).
>> 

Not sure what this has to do with early media. You can have two browser based applications, using SDP O/A to negotiate the DTLS roles.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Feb 2014 12:41:52 -0800

> passing an SDP to the browser?

No. The browser does it.

Q2: If SDP O/A is not used on the wire, there needs to be another mechanism
> for the peers to negotiate/indicate who is "active" and who is "passive"?
>

I don't see how this is our problem.

> Q3: If you have mulitple m- lines, all using the same DTLS association,
> the setup attribute value must be identical in all m- lines?
>

You mean because they are bundled? This should follow the same rules we
generally
use for things that are bundled.

> Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using the
> setup attribute value) as DTLS/SRTP for determining the TLS role?
>

I would think so.

-Ekr

Regards,
> [email-masked]<mailto:[email-masked]>>
> wrote:
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 20:54:35 +0000

Hi,

> I don't see how this is our problem.

Ok, let me rephrase: we use SDP O/A in the API between the JS App and the browser, and the RFCs you pointed to above say that the SDP setup attribute is used to negotiate the roles. 

So, can the JS App, using the setup attribute, control the DTLS role in the browser?

> You mean because they are bundled? This should follow the same rules we generally use for things that are bundled.

We haven't specified the rules for the setup attribute yet, but I assume it will have to be identical for each m- line within a BUNDLE group.

And, in case the m- lines are NOT bundled, there will be separate DTLS associations, with separate roles, right?

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Feb 2014 14:09:30 -0800

On Mon, Feb 10, 2014 at 12:54 PM, Christer Holmberg <
[email-masked]> wrote:

> >> Q2: If SDP O/A is not used on the wire, there needs to be another
> mechanism for the peers to negotiate/indicate who is "active" and who is
> "passive"?
> >
> Ok, let me rephrase: we use SDP O/A in the API between the JS App and the
> browser, and the RFCs you pointed to above say that the SDP setup attribute
> is used to negotiate the roles.
>
> So, can the JS App, using the setup attribute, control the DTLS role in
> the browser

That ties into the general question of which a-lines can be modified in
the JS app. It's no more decided than those questions.

> generally use for things that are bundled.
>
> We haven't specified the rules for the setup attribute yet, but I assume
> it will have to be identical for each m- line within a BUNDLE group.
>

OK.

> And, in case the m- lines are NOT bundled, there will be separate DTLS
> associations, with separate roles, right?
>

Yes.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Feb 2014 07:56:00 +0000

Hi,

>>So, can the JS App, using the setup attribute, control the DTLS role in the browser
>

So, if I understand correctly, currently the JS App CANNOT control the browser DTLS role?

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2014 00:01:59 -0800

On Mon, Feb 10, 2014 at 11:56 PM, Christer Holmberg <
[email-masked]> wrote:

> >>Ok, let me rephrase: we use SDP O/A in the API between the JS App and
> the browser, and the RFCs you pointed to above say that the SDP setup
> attribute is used to negotiate the roles.
> >>

Well, that may turn out to be the case, but it's not what I said.

JSEP Section 6 contains a list of which SDP parameters can
be manipulated by the JS, however, it's clearly unfinished.

http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-05#section-6

Thus, it seems to me to be an open question whether the JS
can manipulate this field.

-Ekr

---

From: Tim Panton <[email-masked]>
Date: Tue, 11 Feb 2014 10:08:03 +0000

On 11 Feb 2014, at 08:01, Eric Rescorla <[email-masked]> wrote:

> 
> 
> 
> On Mon, Feb 10, 2014 at 11:56 PM, Christer Holmberg <[email-masked]> wrote:
> Hi,
> 

But be aware those rules apply to manipulation that happens between 
createOffer and setLocalDescription

In concrete terms this means that a browser might create an offer (with setup:actpass)
set it unaltered as the local description, then send it to a peer.
The peer might reply with an answer with setup:active

This signals that the remote peer wants to be the DTLS client - and the offer said that the local browser was ok with that.
So this example allows the normal roles to be reversed, the non-initiator would be the DTLS client.

However, in a browser-to-browser call this may not be possible, because the JS at the far end may not be
allowed (see above) to change the setup: field between createAnswer() and setting it locally.

A gateway might not feel bound by such rules (code permitting).

Tim.

---

From: Tim Panton <[email-masked]>
Date: Tue, 11 Feb 2014 10:19:24 +0000

> Do you have a reference to where you read that?

No, I don't think I have seen it explicitly stated.

> Not sure what this has to do with early media. You can have two browser based applications, using SDP O/A to negotiate the DTLS roles.

You only care about manipulating the DTLS roles if you want the side that _didn't_ initiate the call to initiate the media flow. The only instance
where that happens is early media. 
Without early media there is no need to manipulate which end is client/server since the default or initiator is client makes sense - or am I missing something?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Feb 2014 10:49:44 +0000

Hi,

> You only care about manipulating the DTLS roles if you want the side that _didn't_ initiate the call to initiate the media flow. The only instance where that happens is early media. 

I don't really have a need to "manipulate" the roles. I just want my JS App to know what role its browser will take, so it can inform its peer (using whatever signaling protocol) about the role.

Regards,

Christer

---

From: Tim Panton <[email-masked]>
Date: Tue, 11 Feb 2014 14:53:48 +0000

> I don't really have a need to "manipulate" the roles. I just want my JS App to know what role its browser will take, so it can inform its peer (using whatever signaling protocol) about the role.

well - assuming you leave  a=setup as actpass (the default in the browser)  .
If you called createOffer, then you'll be DTLS client. 
If you called createAnswer you'll be DTLS server.
That's assuming no weirdness in the ICE implementation. So your JS can _deduce_ the role but neither influence it nor _know_ it directly.

However, signalling it over your high level signalling protocol is the wrong way to do it (IMHO). Your peer should deduce the appropriate DTLS role from the 'signalling' 
in the ICE packets, by looking at the ICE CONTROLLING flag.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Feb 2014 15:04:12 +0000

Hi,

> in the ICE packets, by looking at the ICE CONTROLLING flag.

In SIP/SDP O/A it is done using the setup attribute (red: high level signalling protocol), and JSEP is based on SDP O/A, so...

If we do NOT want to use the setup attribute to determine the DTLS roles, then I think we need to have a separate discussion about that. 

Regards,

Christer

---

From: Tim Panton <[email-masked]>
Date: Tue, 11 Feb 2014 15:26:16 +0000

> If we do NOT want to use the setup attribute to determine the DTLS roles, then I think we need to have a separate discussion about that. 

we are using the  setup attribute in a way. - actpass means we are saying "we don't care". That leaves it to the lower levels to sort it out - via the iceControlling flag.

So now you see what caused the rant :-)

T.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Feb 2014 15:56:10 +0000

Hi,

>>> However, signalling it over your high level signalling protocol is the wrong way to do it (IMHO). Your peer should 
>>> deduce the appropriate DTLS role from the 'signalling' in the ICE packets, by looking at the ICE CONTROLLING flag.
>>
> we are using the  setup attribute in a way. - actpass means we are saying "we don't care". 

That is NOT what it means in SDP O/A - it means "the other side decides" :)

> That leaves it to the lower levels to sort it out - via the iceControlling flag.
>

One way would be to add some flag/parameter, to explicitly indicate the usage of the iceControlling flag to determine the roles - if people want to do that. The advantage is that it would be independent of the signalling protocol used between the peers.

Regards,

Chrsiter

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 11 Feb 2014 22:58:29 +0530

Hi Christer,

I agree with you that SDP setup attribute has to be used to determine the
TLS role as it is not required that the remote side is also WebRTC endpoint.

Thanks
Partha

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Christer
> Holmberg
> Sent: Tuesday, February 11, 2014 9:26 PM
> To: Tim Panton
> Cc: [email-masked]
> Subject: Re: [rtcweb] How to determine TLS roles?
> 
> 
> Hi,
> 
> >>> However, signalling it over your high level signalling protocol is
> the wrong way to do it (IMHO). Your peer should
> >>> deduce the appropriate DTLS role from the 'signalling' in the ICE
> packets, by looking at the ICE CONTROLLING flag.
> >>
> >> In SIP/SDP O/A it is done using the setup attribute (red: high level
> signalling protocol), and JSEP is based on SDP O/A, so...
> >>
> >> If we do NOT want to use the setup attribute to determine the DTLS
> roles, then I think we need to have a separate discussion about that.
> >
> One way would be to add some flag/parameter, to explicitly indicate the
> usage of the iceControlling flag to determine the roles - if people
> want to do that. The advantage is that it would be independent of the
> signalling protocol used between the peers.
> 
> Regards,
> 
> Chrsiter
>