Re: DTLS/SRTP: potential API issues?

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. 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.

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.

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.

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.

_____________
Roman Shpount

On Thu, Dec 11, 2014 at 12:50 PM, Bernard Aboba <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?
>
>
>
>
>
>
>
>
>
>
>
>
>