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>
wrote:

>  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