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

On Fri, Aug 7, 2015 at 3:22 PM, Peter Thatcher <pthatcher@google.com> wrote:

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

I feel like this is a more general question:

I think (C) or some variant would be fine.


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?"​
>

I feel like we need to distinguish between two cases here:

- Errors that are the result of some sort of networking failure
- Internal errors.

srtp_init() seems like a good example here. Here's the code:
https://dxr.mozilla.org/mozilla-central/source/netwerk/srtp/src/srtp/srtp.c#1227

If I'm reading this correctly, this is basically an internal failure, so
you need to
return something that indicates "things are borked", but it's not like you
should need a specific error.

-Ekr