Re: [rtcweb] How to determine TLS roles?

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 10 February 2014 13:51 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB921A02A9 for <rtcweb@ietfa.amsl.com>; Mon, 10 Feb 2014 05:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level:
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqo7No9j4q_m for <rtcweb@ietfa.amsl.com>; Mon, 10 Feb 2014 05:51:47 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3318E1A02C9 for <rtcweb@ietf.org>; Mon, 10 Feb 2014 05:51:46 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-93-52f8d9726d76
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id EA.FD.04853.279D8F25; Mon, 10 Feb 2014 14:51:46 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 14:51:45 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Tim Panton <tim@phonefromhere.com>
Thread-Topic: [rtcweb] How to determine TLS roles?
Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BA=
Date: Mon, 10 Feb 2014 13:51:44 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com>
In-Reply-To: <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+JvjW7RzR9BBie6ZCzW/mtnt7i4/Raj A5PHkiU/gcSkRrYApigum5TUnMyy1CJ9uwSujDcTZrMUNHJVnJ+8nrGB8T57FyMnh4SAicTD b/+ZIGwxiQv31rOB2EICJxgldv1Q6GLkArIXM0pMeH8GqIGDg03AQqL7nzZIjYiAmsS5H4eZ QWxmAXWJO4vPgc0UFjCUWPp4LhNEjZHE7KWdbBC2lcSW1U8YQWwWAVWJadOngdXzCvhKfO6b xwyxt4NRYuUhGRCbU8BVomv5fLAaRqDbvp9awwSxS1zi1pP5UDcLSCzZc54ZwhaVePn4HyuE rSix82w71G06Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxShZ nFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGEUHt/w22sF4co/9IUZpDhYlcd7rrDVBQgLp iSWp2ampBalF8UWlOanFhxiZODilGhgXXbzQFb792sHY2BnfForNv2bodrlmh232pcTzmr+3 H+gVVqr0y7c8v8RZ6/8uScXmJ/Ib4tVKUpbzOhxc1J7zb1mPyKoCcasOX4ZZayfdcWsvbUqe qi/0darlXM7K+2rFO05N+P3vKcfXwzsUzTQdjL4skYxSVvG88Ddg2o11Uw81/k3Rsy5XYinO SDTUYi4qTgQAupRMznACAAA=
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] How to determine TLS roles?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2014 13:51:49 -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?
>
> 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.

Regards,

Christer