Re: [rtcweb] Unsolicited DTLS Handshake

Stefan Håkansson LK <> Wed, 03 December 2014 11:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C02861A1A4E for <>; Wed, 3 Dec 2014 03:02:05 -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 ymr81Eqn5hUk for <>; Wed, 3 Dec 2014 03:01:59 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDFAF1A0379 for <>; Wed, 3 Dec 2014 03:01:58 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-26-547eeda4a123
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 02.3A.24955.4ADEE745; Wed, 3 Dec 2014 12:01:56 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 12:01:56 +0100
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <>
To: Roman Shpount <>, Christer Holmberg <>
Thread-Topic: [rtcweb] Unsolicited DTLS Handshake
Thread-Index: AQHQDbgwUx1qYQbt0UW184QphZppJQ==
Date: Wed, 3 Dec 2014 11:01:56 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
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+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6St3UhBvebLC1mXJjKbLH2Xzu7 A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgyth0egtbwTmRivlvPjM3MB4V6GLk5JAQMJFY 0neAFcIWk7hwbz1bFyMXh5DAEUaJVwsXMEM4ixklNrevYwSpYhMIlNi6bwEbiC0iEC1xue0/ M4jNLKAucWfxOXYQW1jAQGLrgl2sEDWGEs2nz7JA2HoSm+ZMBqthEVCR+Nl3EKiXg4NXwFdi +T5niF37WCSe/z0KNpMR6KLvp9YwQcwXl7j1ZD4TxKUCEkv2nGeGsEUlXj7+B/WBksSi25+h 6vUkbkydwgZha0ssW/garJ5XQFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqclJtu ZKyXWpSZXFycn6eXl1qyiREYJwe3/FbdwXj5jeMhRgEORiUe3g01dSFCrIllxZW5hxilOViU xHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxakIoO3tT4p8fc5gEeuamJpupRkjP XV3fPOfbas45u82qbTQX/Flq5c2yQ559we9TRYwvbzq1ec0utbl58+DRRLb7xT1sGic5OLM+ X39sfeyyZfT1T1ptlULm62OLJHWdmE8an5lmYejvqtXewjdN5t2nWau2XJNcvNNRl1/uVWfj qdWCPr+UWIozEg21mIuKEwFhZZ1hdAIAAA==
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 11:02:06 -0000

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