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

Re: DTLS/SRTP: potential API issues?

From: Roman Shpount <rshpount@turbobridge.com>
Date: Thu, 11 Dec 2014 14:27:19 -0500
Message-ID: <CAD5OKxsybFi3Gxv=KYcKC725+phj5fnAqx+MOYCLo4USRyBXFg@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: "public-ortc@w3.org" <public-ortc@w3.org>
On Thu, Dec 11, 2014 at 2:19 PM, Bernard Aboba <Bernard.Aboba@microsoft.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?

This is exactly what I am saying. Existing implementation will only expect
a new DTLS session negotiation if transport parameters have changed. They
will not handle a new DTLS session over the existing ICE transport
connection and they have no way to demultiplex two DTLS sessions over the
same ICE connection.
Roman Shpount
Received on Thursday, 11 December 2014 19:27:49 UTC

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