Re: [MMUSIC] Handling of unverified data and media

If the full ice endpoint receives an offer, it has the remote DTLS
fingerprint, so no problem on that

It's true that the ice lite endpoint will be able to receive media from the
full ice endpoint before it receives the DTLS fingerprint of the full ICE
endpoint.  So you are correct that this is an issue for ice lite endpoints,
just as it is for non-ICE endpoints.

On Thu, Mar 30, 2017 at 6:11 PM Roman Shpount <roman@telurix.com> wrote:

> Peter,
>
> What about ICE lite? If ICE lite sends an offer to WebRTC end point, it
> can get DTLS ClientHello before it got the answer response from the WebRTC
> end point. Since ICE lite client does not send ICE requests before sending
> data, it will respond with ServerHello and establish the connection. At
> this point data can be sent to it before the answer arrives and fingerprint
> can be verified.
>
> I think the right answer to this situation is not to send ServerHello
> until answer and fingerprint is received. ClientHello should be buffered
> and only handled when answer is received.
>
> Regards,
>
> _____________
>
> Roman Shpount
>
> On Thu, Mar 30, 2017 at 7:40 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
> Bernard, you are right that this is possible with ORTC, even though I
> think it's impossible with WebRTC.  But that's clearly out of scope for the
> MMUSIC WG.  Perhaps the right forum to discuss Cullen's 1-800-fedex use
> case is in the context of ORTC (or WebRTC NV).
>
> On Thu, Mar 30, 2017 at 3:50 PM Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
> These both sound like legitimate cases where ICE can precede
> signaling.  I would recommend that the W3C think carefully about
> whether they might like to accept (potentially) invalid data before we
> spend a whole lot more time on the issue.
>
> On 30 March 2017 at 17:11, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> > The unverified media scenarios seem to depend on ICE connectivity being
> > bi-directionally enabled so as to permit the DTLS negotiation to proceed
> in
> > advance of remote fingerprint arrival. If ICE candidates are signaled
> > separately from the DTLS fingerprint exchange it might be feasible, such
> as
> > in ORTC signaling where the ICE parameters are exchanged before the
> > DtlsParameters.
> >
> > At the last WebRTC interim a scenario involving PRANSWER and Trickle ICE
> was
> > presented. In the scenario, the PRANSWER included a fingerprint, but
> > possibly one which did not match the certificate provided in DTLS unlike
> the
> > final answer. I do not see how this could work but perhaps I am missing
> > something.
> >
> > On Mar 30, 2017, at 14:14, Peter Thatcher <pthatcher@google.com> wrote:
> >
> > We have a mailing list discussion (here), a bug
> > (https://github.com/w3c/webrtc-pc/issues/849) and a PR
> > (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215)
> about
> > this.  I've copied the following comments to the latter two, so I'm
> adding
> > them here as well.
> >
> > TL;DR: I don't think unverified media is compatible with ICE+DTLS.  Here
> is
> > why (you can go see the bug, too):
> >
> > You can receive DTLS from the remote side before receiving the remote
> > description (and thus fingerprint). This happens if the remote side
> sends an
> > ICE connectivity check and the local side sends a response and then the
> > remote side sends a DTLS packet.
> >
> > You cannot send DTLS from the local side before receiving the remote
> > description (and thus fingerprint). This is because you can't send an ICE
> > connectivity check until you have the remote ICE ufrag and pwd, and thus
> > can't get an ICE connectivity check response, and thus can't send DTLS.
> This
> > is because you can't send anything other than ICE until you get an ICE
> > connectivity check response.
> >
> > Since you can't send DTLS, you can't complete the handshake, and thus
> can't
> > extract the SRTP key.
> >
> >
> > Maybe I'm missing something, but I think this is impossible.
> >
> > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <fluffy@iii.ca> wrote:
> >>
> >>
> >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg
> >> <christer.holmberg@ericsson.com> wrote:
> >>
> >> My question is: is this something that’s causing problems in real
> >> deployments, and requires a change in the standard?
> >>
> >>
> >> 1-800 go fedex. See webrtc requirements documents from many years ago.
> >> _______________________________________________
> >> mmusic mailing list
> >> mmusic@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>