Re: What event do we fire when the DTLS handshake fails, or when DTLS-SRTP key extraction fails?

On Fri, Aug 7, 2015 at 2:39 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, Aug 7, 2015 at 1:47 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>> If a DTLS handshake fails, what event should fire on the PeerConnection?.
>>
>>
>> I can see three options:
>>
>> A.  Fire PeerConnection.iceconnectionstatechange, and the state goes to
>> disconnected/failed.
>>
>> B.  DtlsTransport.onstatechange, and the state goes to failed.
>>
>
> Yes, this sees like it
>

>
>> C.  Add PeerConnection.onerror, and fire that.
>>
>>
>> I think we should definitely do B.  The question I have is: should we
>> also do A or C (or both)?
>>
>> While A is not technically true (it's the DTLS state that's broken, not
>> the ICE state), the reason for doing this is to avoid the application from
>> seeing ICE connected, but then having nothing work (I'm guessing very few
>> applications will remember to listen to DtlsTransport.onstatechange,
>> whereas nearly all will listen to PeerConnection.iceconnectionstatechange).
>>
>>
>> FYI, Chrome currently does A.
>>
>
> A seems wrong :)
>
> Maybe we need some sort of bigger "This connection is busted" thing
>

That's what I was suggesting with C, except perhaps you want it more
connection-specific: PeerConnection.ontransporterror or .onconnectionerror.

The problem is that while all apps will listen
to PeerConnection.oniceconnectionstatechange, not all will listen to the
new thing, and so many apps will just silently fail if we leave ICE
connected but DTLS failed.


>
>

>
>
>> Similarly, what if DTLS succeeds, but DTLS-SRTP key extraction fails?  Do
>> we consider it a complete DTLS failure (do A or B), or do we consider the
>> DTLS transport partially usable (for data channels, but not for RTP)?
>>
>
> How do you expect this to happen? The other side rejects the use_srtp
> extension?
>

​I call
SSL_export_keying_material
​.  It can return a failure, and I need to handle it.

​I don't know why
​it​
 would fail (you probably know better than me), but I do need to handle the
failure paths.​



Similary, I call
srtp_init
​ or
srtp_create
​
​.  It can return a failure, and I need to handle it.​
​
​
​
​  It's not key extraction failure, but key application failure.

So, my question was more of "if DTLS-SRTP goes bad even thought DTLS
didn't, what do we do?"​





>
> -Ekr
>
> FYI, Chrome currently does something quite strange: it returns an error
>> the next time SetLocalDescription or SetRemoteDescription is called.  This
>> happens because it signals an internal version of PeerConnection.onerror
>> internally, but that error never has anywhere to go up to the Javascript.
>> The impetus for this email is that we want to improve on this behavior, but
>> we want to make sure we change it to the right behavior so we don't have to
>> change it again later :).
>>
>>
>>
>>
>>
>>
>