W3C home > Mailing lists > Public > public-ortc@w3.org > December 2014

RE: DTLS/SRTP: potential API issues?

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Thu, 11 Dec 2014 19:19:43 +0000
To: Roman Shpount <rshpount@turbobridge.com>
CC: "public-ortc@w3.org" <public-ortc@w3.org>
Message-ID: <BLUPR03MB1330038CB8D5831B116C01EEC630@BLUPR03MB133.namprd03.prod.outlook.com>
Roman said:

“Based on this, your initial statement about calling start on RTCDtlsTransport once is effectively irrelevant. An API user can initiate a new DTLS handshake at any time (including re-key) by creating a new RTCDtlsTransport, configuring the relevant parameters and associating it with an existing RTCICETransport. All the tools needed to shoot oneself in the foot with the current WebRTC implementation are ready and provided to the API user. On the other hand, I do not think this needs to be specifically disabled since there are valid use cases when such functionality is needed to interwork with valid DTLS and DTLS-SRTP implementations.”

[BA] It is true that the developer could construct a new RTCDtlsTransport based on an existing RTCIceTransport and then call RTCDtlsTransport.start().  However, my assumption is that doing this would not result in a DTLS re-negotiation (e.g. a DTLS exchange using an existing crypto-context) or a session resumption, although it would cause a new DTLS negotiation to occur.  So yes, the DTLS role, fingerprints, etc. would change and a new DTLS/SRTP key would be derived.   Are you saying that a new DTLS negotiation on an existing IceTransport would be likely to fail with existing implementations?
Received on Thursday, 11 December 2014 19:20:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:54 UTC