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

I went to write a PR for PeerConnection.onerror and found it difficult to
write it in a way that would actually be useful to JS applications.  And
the more I thought about it, the more I realized the real issue is that we
use PeerConnection.iceconnectionstate as if it meant
PeerConnection.connectionstate (including ICE and DTLS).

I created an issue in github to track this:
https://github.com/w3c/webrtc-pc/issues/278.

If someone else wants to try and make PeerConnection.onerror, or has other
ideas how to resolve this, go for it.  But for now I'm going to give up on
PeerConnection.onerror.

On Sat, Aug 8, 2015 at 3:32 PM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> Speaking personally: My sense is that we need PeerConnection.onerror or
> similar - there's simply too many error cases to enumerate them all.
>
> DtlsTransport.onstatechange is useful if there's anything the app can do
> about the situation apart from trying to tell the user "here's what we
> think is borked".
>
> Another question is what we should do about SignalingState when
> something goes belly-up inside: Would it make sense to simply say "we
> transition to closed on all errors"?
>
> That way, we're sure nobody's going to dig themselves deeper into the
> hole.....
>
> Den 08. aug. 2015 01:03, skrev Peter Thatcher:
> >
> >
> > On Fri, Aug 7, 2015 at 4:01 PM, Eric Rescorla <ekr@rtfm.com
> > <mailto:ekr@rtfm.com>> wrote:
> >
> >
> >
> >     On Fri, Aug 7, 2015 at 3:22 PM, Peter Thatcher <pthatcher@google.com
> >     <mailto:pthatcher@google.com>> wrote:
> >
> >
> >
> >         On Fri, Aug 7, 2015 at 2:39 PM, Eric Rescorla <ekr@rtfm.com
> >         <mailto:ekr@rtfm.com>> wrote:
> >
> >
> >
> >             On Fri, Aug 7, 2015 at 1:47 PM, Peter Thatcher
> >             <pthatcher@google.com <mailto: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
> >
> >
> > ​
> >
> >
>
>