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

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

>
>
> 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.
>
>
​I think it would be fairly easy to educate app developers to listen to
PeerConnection.onerror, so perhaps making that the "new thing" would be OK.​



>
> 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.
>
>
Agreed.  PeerConnection.onerror, or something like that, would be fine.​
​



> -Ekr
>

​