Re: [rtcweb] How to determine TLS roles?

On Mon, Feb 10, 2014 at 8:37 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>
> Hi,
>
> >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
>
> 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?
>

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,
>
> Christer
>
>
>
>
>
>
>
> On Mon, Feb 10, 2014 at 6:23 AM, Christer Holmberg <
> christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
> wrote:
> 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?
> >>>
> >>> 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.
> >>
> >> 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.
> >>
> > 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org<mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>