Re: DTLS/SRTP: potential API issues?

On Thu, Dec 11, 2014 at 3:38 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>  Roman said:
>
>
>
>    [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.
>
>
>
> [BA] I guess there are two ways to address this:
>
>
>
> 1.       Prevent an RTCDtlsTransport from being constructed from an
> RTCIceTransport that isn’t in the “new” state (e.g. construct the
> RTCDtlsTransport before calling IceTransport.start()) OR
>
> 2.       Clarify the protocol specifications to require that
> implementations support renegotiation and DTLS/SRTP rekey.
>

Preventing RTCDtlsTransport from being constructed with RTCIceTransport in
the non-new state  is cleaner from the interop with existing WebRTC
implementation but leaves the question of what to do if fingerprint or
setup role is changed in the offer which maintained the ICE transport
settings. The only reliable way to handle such situation from the API is to
accept the offer with some sort of dummy answer and then issue a new offer
with new ICE and DTLS transports. If we agree that this is sufficient, then
we can impose this limitation on the API. Alternative does improve the
interop with non WebRTC implementations, but complicates things
considerably for ORTC implementors for something which is most likely is an
edge case. DTLS/SRTP rekey can still be handled by the ORTC implementation
internally as long as setup roles and fingerprints remain the same.
_____________
Roman Shpount