Re: Handling of unverified data and media

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

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic