Re: [rtcweb] Unsolicited DTLS Handshake

Christer Holmberg <> Tue, 02 December 2014 13:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DDDE01A1B46 for <>; Tue, 2 Dec 2014 05:06:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cX0Jnxi9CxXy for <>; Tue, 2 Dec 2014 05:06:52 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E10101A1B01 for <>; Tue, 2 Dec 2014 05:06:51 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-99-547db969f398
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 31.7E.24955.969BD745; Tue, 2 Dec 2014 14:06:50 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 14:06:49 +0100
From: Christer Holmberg <>
To: Roman Shpount <>, Martin Thomson <>
Thread-Topic: [rtcweb] Unsolicited DTLS Handshake
Thread-Index: AQHQDbgwjr0wkzj8TUKVKwdS4+MXBJx7Tk6AgAAmLgCAAA71AIAAU10AgABbRoCAABFToA==
Date: Tue, 2 Dec 2014 13:06:48 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvjW7WztoQg3X/mC2unfnHaDHjwlRm i7X/2tkdmD12zrrL7rFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyFr3rYiu4JFnxu+0SYwPj H4kuRk4OCQETicV7z7NA2GISF+6tZ+ti5OIQEjjCKPHuz1omCGcxo8TH9n72LkYODjYBC4nu f9ogDSICQRLPp89nArGZBdQl7iw+xw5iCwsYSEyfNJ0ZosZQovn0WRYIO0zi47utYHEWARWJ v18vsYHYvAK+ElPuTGSB2LWZWeL3449gRZwCgRIPlsxkBbEZga77fmoN1DJxiVtPIBZLCAhI LNlznhnCFpV4+fgfK4StJPFjwyUWkJuZBTQl1u/Sh2hVlJjS/ZAdYq+gxMmZT1gmMIrNQjJ1 FkLHLCQds5B0LGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGE8Ht/xW3cF4+Y3jIUYB DkYlHt4Pn2pChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD Y+WU9DPafEleegtb9a9Yfa/XFmpwyxVawvHnotVsdtdP/7K+pUgHH6xuym3hbDnVIfuxV/F9 ftKeHXwlWx5EFp15oNv2dvXLWG6JBs3LfYfNn20xvxTJNaN2zZec3sz/SpH2mS0XmDlZw+OF mDVqN04tf7PLQTlW7k547Ke66DXiyTwPr7sosRRnJBpqMRcVJwIAywEUEYgCAAA=
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: Tue, 02 Dec 2014 13:06:56 -0000


>>ekr corrected me.  Firefox explicitly disables renegotiation.  We
>>don't have the machinery in place to re-export SRTP keying material
>>anyway (I suspect that it requires use of MKI).
> 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?

> Also, what happens when transport parameters stay the same but the fingerprint changes? This definitely requires a new DTLS connection, but you will still need to de-mux 
> SRTP packets belonging to the old and new SRTP contexts somehow. This is not that different from rekey.
> As for the text in RFC 5763, I read that as : if you have a
> connection, use it; if you don't, or the existing one is "bad" for any
> reason, make a new one.  That is not renegotiation.
> What happens if one side decides it does not like its connection and the other side decides to keep it? In such case one side will start a new handshake but
> the other side will not expect it. The specification needs to define when new connection MUST be created and when new connection MUST not be created to 
> work consistently. Alternatively DTLS end point should be prepared to handle ClientHello or HelloRequest at any time, as well as, actively solicit the handshake 
> when in passive mode by sending periodic HelloRequests to make sure both sides participate.

If no endpoint supports renegotiation, I guess they won't decide not to like the connection (or, if they do, perhaps they will terminate the whole call).

> 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.