Re: [rtcweb] Unsolicited DTLS Handshake

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Wed, 03 December 2014 11:02 UTC

Return-Path: <stefan.lk.hakansson@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 C02861A1A4E for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 03:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymr81Eqn5hUk for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 03:01:59 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFAF1A0379 for <rtcweb@ietf.org>; Wed, 3 Dec 2014 03:01:58 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-26-547eeda4a123
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.3A.24955.4ADEE745; Wed, 3 Dec 2014 12:01:56 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 12:01:56 +0100
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [rtcweb] Unsolicited DTLS Handshake
Thread-Index: AQHQDbgwUx1qYQbt0UW184QphZppJQ==
Date: Wed, 03 Dec 2014 11:01:56 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se>
References: <CAD5OKxtyy2Djh5ssE69qLJq7deQU9LP=J2vpn_Y3eO=4D2vpmg@mail.gmail.com> <CALiegfnh3pHA=Z6O_PYuhoECzzex3quDh1fUk=yRvbFp+xKGNQ@mail.gmail.com> <CABkgnnUppq01v1vo8H6WY80nS5XUhf+mjuNMreYyCQagKFgOGQ@mail.gmail.com> <CAD5OKxsbt4O8xuphthvEJqEYgPfubhpvY1sNDi_GkzcyEQXkyw@mail.gmail.com> <CABkgnnX8ufq1YQm+6S1xE+zDMQ42qAcvYiViKmAdG49Tj3HXUA@mail.gmail.com> <CAD5OKxv9SZUCwZT81QgPHs_TLyLiMJLKt1WU+2F0oH+gKQAJoA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <CAD5OKxvjbqNhszkDUjMaSJB2+Pnc4qQdmQQKfNT+Ypnz5yR2yw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
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==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7Nelp6tgr6qRr6_s0kuGiF3ajLA
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Unsolicited DTLS Handshake
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: 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
> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>
> 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
>