Re: [rtcweb] Unsolicited DTLS Handshake

Christer Holmberg <> Thu, 04 December 2014 06:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 94FB31A88CB for <>; Wed, 3 Dec 2014 22:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fTAFMryycSjk for <>; Wed, 3 Dec 2014 22:28:21 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBBE31A88C8 for <>; Wed, 3 Dec 2014 22:28:20 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-e9-547fff023dc3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1D.C8.24955.20FFF745; Thu, 4 Dec 2014 07:28:19 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 07:28:18 +0100
From: Christer Holmberg <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] Unsolicited DTLS Handshake
Thread-Index: AQHQDbgwjr0wkzj8TUKVKwdS4+MXBJx9xuEggAAb0wCAAAUYAIAA9eU6gAABjYCAABvl8A==
Date: Thu, 4 Dec 2014 06:28:18 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D577B42ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM+JvjS7z//oQg7+/2S2m77Ox2DpVyGLG hanMFmv/tbM7sHica3jP7rFgU6nHkiU/mTxuTSkIYInisklJzcksSy3St0vgytjxeBZzQVde RfuplWwNjD3ZXYycHBICJhJvJ51kgbDFJC7cW8/WxcjFISRwhFFiwtp97BDOYkaJ9y9mM3Ux cnCwCVhIdP/TBmkQEVCTeDhrFytIDbNAG6PEy/tHwSYJCxhITJ80nRmiyFCi+fRZFpBeEYEw iSfnZUHCLAIqEifPLGUCsXkFfCX2v10Ltfg+u8TZOa9ZQRKcAoESM7qnMYLYjEDXfT+1BqyB WUBc4taT+UwQVwtILNlznhnCFpV4+fgfK8guCQEliWlb0yDK8yXu9/9jh9glKHFy5hOWCYyi s5BMmoWkbBaSsllAk5gFNCXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0I2O9 1KLM5OLi/Dy9vNSSTYzAaDy45bfqDsbLbxwPMQpwMCrx8Bqcqw8RYk0sK67MPcQozcGiJM67 8Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MHm+y5/5VLHui3cB7vEPHJyFzXUmutt69 5wXdk9P/hIozsdze7ix1dmkEyz7bo3cOHgh9XvflyY4bwk8qE/4fmLVkTd9bsawqThkXyw19 W/hLcxdxPDjCc+H5hlML19gVec1Or50lkP3rr+CP/e4+nN6u07bqTjom8MVx88HtSnxWdhdd buzOVGIpzkg01GIuKk4EABU0rD+nAgAA
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: Thu, 04 Dec 2014 06:28:23 -0000

5763 is specific to SRTP, but there are also other protocols using DTLS.

The Offer/Answer considerations should be the same for all of them – otherwise we will have problems e.g. in BUNDLE, if different protocols within a BUNDLE group use different rules for negotiating TLS roles etc…



From: Justin Uberti []
Sent: 4. joulukuuta 2014 7:47
To: Christer Holmberg
Cc: Iñaki Baz Castillo; Roman Shpount;
Subject: Re: [rtcweb] Unsolicited DTLS Handshake

That sounds like a 5763-bis.

On Wed, Dec 3, 2014 at 8:41 PM, Christer Holmberg <<>> wrote:
Hi Inaki,

My intention is not to be able to do everything with O/A.

I am trying to figure out what can be done with O/A, and how/if O/A affects existing DTLS connections.

If something can NOT be done, I think it would be good to document somewhere.

I am willing to start drafting a "TLS with SDP O/A" draft, if people think such would be useful.



Sent from my Windows Phone
From: Iñaki Baz Castillo<>
Sent: ‎03/‎12/‎2014 17:01
To: Roman Shpount<>
Cc: Christer Holmberg<>;<>
Subject: Re: [rtcweb] Unsolicited DTLS Handshake
2014-12-03 15:43 GMT+01:00 Roman Shpount <<>>:
> If the transport parameter have NOT changed, can the fingerprint be changed?

Correct me if I'm wrong, but during a DTLS/TLS session certificates
are sent just once, at the beginning. Changing the a=fingerprint
attribute in a new SDP O/A round-trip without forcing a new DTLS
session should just be considered an error.

Again: we are trying to signal too much in the SDP.

Iñaki Baz Castillo

rtcweb mailing list<>