Re: DTLS/SRTP: potential API issues?

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

>  Roman Shpount said:
>
>
>
> *“*Is it possible to create a new RTCDtlsTransport with
> an existing RTCICETransport? This will effectively initiate a new DTLS
> handshake without the corresponding transport parameter change, which is
> what currently is causing problems.”
>
>
>
> [BA] The RTCDtlsTransport constructor takes an RTCIceTransport as an
> argument, and we do not say anything about the state that the
> RTCIceTransport is in at the time of construction.  So the IceTransport
> could have been newly constructed, or could have had IceTransport.start()
> called before the RTCDtlsTransport is constructed.  The IceTransport could
> even have concluded connectivity checks and pruned candidates.  From the
> point of view of the RTCDtlsTransport, it is just looking for a suitable
> path to send packets, so I don’t believe that changes in the IceTransport
> state are material.  For example, if the IceTransport transitions from
> “disconnected” to “connected” for some reason, the DTLS transport just
> resumes where it left off, whether it was in the middle of a negotiation,
> or sending/receiving packets.  So as things stand, I don’t believe that
> IceTransport state changes result in new DTLS handshakes.
>
>
>
> “On the other hand, this is the only way to handle a new offer where
> fingerprint or role do change without the underlying transport parameter
> change.”
>
>
>
> [BA] With the current ORTC API, if there is a desire to change the
> fingerprint or role, then a new RTCDtlsTransport needs to be constructed.
>
>
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.
_____________
Roman Shpount