Re: [rtcweb] Unsolicited DTLS Handshake

Christer Holmberg <> Wed, 03 December 2014 12:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F09F51A0461 for <>; Wed, 3 Dec 2014 04:09:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zrZ1b6UmcmBK for <>; Wed, 3 Dec 2014 04:09:48 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4C051A1A80 for <>; Wed, 3 Dec 2014 04:09:47 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-bd-547efd89b55b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3E.27.24955.98DFE745; Wed, 3 Dec 2014 13:09:45 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 13:09:45 +0100
From: Christer Holmberg <>
To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <>, Roman Shpount <>
Thread-Topic: [rtcweb] Unsolicited DTLS Handshake
Thread-Index: AQHQDbgwjr0wkzj8TUKVKwdS4+MXBJx9xuEg
Date: Wed, 3 Dec 2014 12:09:44 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW7n37oQg4s/rC1mXJjKbLH2Xzu7 A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgyuj6eJa5oEO64krzDdYGxu2iXYycHBICJhKt R1qYIWwxiQv31rN1MXJxCAkcYZR4MuU6E4SzmFFi74atQFUcHGwCFhLd/7RBGkQEiiS6/vWy gtjMAuoSdxafYwexhQUMJKZPms4MUWMo0Xz6LAuEbSSx58M6RhCbRUBF4tznzWA1vAK+Eisn PWWH2NXEKnH+2nsmkASngJ/Ek0t32UBsRqDrvp9awwSxTFzi1pP5TBBXC0gs2XMe6gNRiZeP /7FC2IoS7U8bGCHq9SRuTJ3CBmFrSyxb+BpqsaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiy ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwfg5u+a26g/HyG8dDjAIcjEo8vBtq6kKEWBPL iitzDzFKc7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjwDbve22W51RWZmql G5w91bpLlndR8HuvLN4kgSwmBcOJClp6r6qq7/Js3Jqk5/RL72XDj9evz/y4v05y4w/fkwlr 68/Xu/uwnVryqnNaxZv/psdz48/499y4o7TJOvC03ReWmI+JXwwWL4vkv6pqej7/pHL9tZeV 3rtNJ1598VjNIoRjy8kTSizFGYmGWsxFxYkA12cXdYACAAA=
Cc: "" <>
Subject: Re: [rtcweb] Unsolicited DTLS Handshake
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Dec 2014 12:09:51 -0000


There are a number of issues we need to solve, so I'll try to separate them.

First, we need to agree on whether support of rekeying and renegotiation is mandatory, optional or not supported in general.

Second, we need to agree on how/if an updated offer affects an existing DTLS connection.

- If the transport parameters have changed, a new DTLS connection is obviously needed. But, then, how are the roles determined? Using the SDP setup attribute, as in the initial offer? OR, do we use the roles determined in the initial offer?

- If the transport parameters have NOT changed, would an updated offer affect an existing DTLS connection? Could the roles be changed (based on the SDP setup attribute)?



-----Original Message-----
From: Stefan Håkansson LK 
Sent: 3. joulukuuta 2014 13:02
To: Roman Shpount; Christer Holmberg
Subject: Re: [rtcweb] Unsolicited DTLS Handshake

On 02/12/14 14:46, Roman Shpount wrote:
> On Tue, Dec 2, 2014 at 8:06 AM, Christer Holmberg 
> < 
> <>>
> wrote:
>     > Chrome on the other hand has renegotiation enabled but does not have the code to detect it and to re-export SRTP keys. My question is, should disabling renegotiation
>     > be codified somewhere (like JSEP) or is this something that is going to be implemented? If renegotiation is somehow an optional feature, how does one know that remote party supports it?
>     Well, we have mechanisms to indicate support of something. In SDP we
>     can define an attribute, in SIP we can define a media feature
>     tag/option tag. I assume there are ways on the DTLS level to
>     indicate support also?
> I do not think this was ever consider an optional feature and because 
> of this there is no option to negotiate it.
>     > Finally, JSEP should define what can be changed on the DTLS connection. I think it was already agreed on the list that the setup roles should be preserved (btw is this a SHOULD or a MUST?). What about the fingerprint? Is it legal to change  it without changing transport parameters?
>     Again, I don't think this belong to JSEP. It is a generic SDP
>     Offer/Answer issue.
> Supposedly, JSEP will already define that DTLS setup role cannot be 
> changed. Why is fingerprint any different?
> I think DTLS and DTLS-SRTP end-points must supports rekey and 
> renegotiation. I do not think DTLS or DTLS-SRTP is broken or unclear 
> (of cause, this can always be improved). It looks like the mandatory 
> DTLS capability is missing from the current browser implementations. 
> So, either the rtcweb browsers should implement  this or specification 
> should be created to explain how browsers will work without it.

I agree, we really need to decide on this (and other stuff) to enable independent implementations to interoperate.

Is there any reason for not implementing according to DTLS/DTLS-SRTP specs? If not, I think that is what we should mandate.

> If the
> second path is chosen, then this discussion should probably move to 
> other groups, such as MMUSIC. The less attractive option is to argue 
> that this is a rtcweb specific DTLS profile and keep it 
> non-inter-operable with regular DTLS/DTLS-SRTP.
> _____________
> Roman Shpount