Re: [MMUSIC] Handling of unverified data and media

[Roman Shpount <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
>> >>
>> >>
>> >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg
>> >> <[e-mail]> 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/mmusic
>> >
>> > _______________________________________________
>> > mmusic mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mmusic
>> >
>> >
>> > _______________________________________________
>> > mmusic mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mmusic
>> >
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>