RE: DTLS/SRTP: potential API issues?

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.

Do we assume that there is some sort of internal callback from RTCDtlsTransport to RTCRtpReceiver object if DTLS re-key is initiated by the remote side? Even though it does make sense to prevent API users from initiating DTLS re-key, it would still be prudent to be able to handle re-key if it is initiated by the remote side.

[BA] Currently there is no callback like this in ORTC, and I don’t believe that the current ORTC API will cause an implementation to initiate a renegotiation or session resumption with associated DTLS/SRTP rekey. However, some implementations might respond to a re-key attempt, and revise the DTLS/SRTP keys accordingly.  The API doesn’t have any settings to control this.

P.S. I think current situation with re-key handling, fingerprint, and role-change is a temporary implementation deficiency of current WebRTC stacks. It is much easier to implement proper handling for all of those things then to re-define the standard to close all related gaps.

[BA] I am familiar with implementations that do support renegotiation, session resumption, DTLS/SRTP re-key, etc.   However, the current ORTC API doesn’t appear to have a way to initiate this and given that support is not there in existing implementations, it’s probably best to leaving sleeping dogs lie until that situation changes.

P.P.S. Is there a reason why DTLS role does not match the values for RFC 4145 SDP setup attribute? SDP setup attribute can be "actpass", which corresponds to auto, "active", which corresponds to client, "passive" which corresponds to server, and "holdconn" which does not match anything in the ORTC.

[BA] I will file this as an issue for investigation.

_____________
Roman Shpount

On Thu, Dec 11, 2014 at 12:50 PM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:

There has been a recent post on the RTCWEB WG mailing list relating to WebRTC 1.0 and the behavior of the DTLS/SRTP implementations.  It began with this post:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg13584.html




Some of the points made in the thread:



•       Existing implementations disable renegotiation, session resumption and/or re-export of SRTP keying material.  So to assure interoperability, WebRTC implementations should probably not attempt to renegotiate or resume a session.

•        WebRTC 1.0 does not allow the DTLS role to be changed in mid-stream, and is currently unclear about changing the certificate fingerprint.  Since without renegotiation you can’t exchange new certificates, there probably should be a prohibition on changing fingerprints.



Reviewing the implications for the ORTC API, at first glance I didn’t see a way for developers to shoot themselves in the foot:



•       Section 2.3.2 prohibits calling RTCDtlsTransport.start() more than once.   As a result, there is no way to change the remote DTLS parameters once .start() is called,. and no way to programmatically force renegotiation.

•       RTCIceTransport is supplied in the constructor and cannot be changed.



Are there potential issues that I missed?  Assuming that clarifications go into the protocol documents, is there any text worth inserting into the ORTC API document?