Re: DTLS/SRTP: potential API issues?

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