Re: [rtcweb] How to determine TLS roles?

[Tim Panton <[e-mail]>]

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

> 
> 
> 
> On Mon, Feb 10, 2014 at 11:56 PM, Christer Holmberg <[e-mail]> wrote:
> Hi,
> 
> >>>> 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.
> >>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.
> 
> So, if I understand correctly, currently the JS App CANNOT control the browser DTLS role?
> 
> 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.

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.

> 
> -Ekr
>