Re: Suggested resolution of Issue 849: Specify an AllowUnverifiedMedia RTCConfiguration property

For what it is worth I've come up with a scenario where this can happen, but I think it is unlikely.

If you have
1) an un-ordered or lossy signalling transport (SIP over UDP or JSON over an SCTP _unordered_ channel)
2) are using trickle-ice which 
3) are sending a=candidates containing ufrag and password set

Then you could (theoretically) have the situation where the candidate (with ufrag/pass) arrives before the answer with the fingerprint.

If the ICE consent and DTLS handshakes complete (2 x rtt) before that delayed answer arrives, you could legitimately get
media sent and received (2.5 rtt) before the fingerprint can be used to verify the channel.

In practice I think browsers wait for a RTCP exchange before sending video, so that's >3rtts delay needed before you lose a keyframe.

As Roman says, "prohibit to start DTLS handshake until the answer is received" will cover that unlikely case nicely.
Alternatively we could remove the ufrag/pass from the trickle candidate and only allow it in the answer.

T.

> On 3 May 2017, at 06:25, Tim Panton new <thp@westhawk.co.uk> wrote:
> 
> I'd be happy to join that call too please. 
> 
> T.
> 
> Sent from my iPod
> 
> On 2 May 2017, at 23:46, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> wrote:
> 
>> Cullen,
>> 
>> Do you want to have call where you would walk me through this example? You seem to be the only one who understands it. Please contact me directly if you have time to discuss this.
>> 
>> We also are planning to update the dtls-sdp draft (https://github.com/cdh4u/draft-dtls-sdp/pull/31 <https://github.com/cdh4u/draft-dtls-sdp/pull/31>) which will prohibit to start DTLS handshake until the answer is received. This should prevent unverified media from ever occurring with DTLS, even if ICE and consent to send is not used.
>> 
>> Regards,
>> 
>> _____________
>> Roman Shpount
>> 
>> On Tue, May 2, 2017 at 5:15 PM, Cullen Jennings (fluffy) <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote:
>> 
>> > On Apr 26, 2017, at 10:26 AM, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> wrote:
>> >
>> > Cullen,
>> >
>> > Until we see the scenario where unverified media can be received by a full ICE end point which implements consent to send, there is general consensus that unverified media to WebRTC endpoint cannot happen.
>> >
>> > Regards,
>> 
>> The example I gave was fully consistent with everything WebRTC requires including consent.
>> 
>> >
>> > _____________
>> > Roman Shpount
>> >
>> > On Wed, Apr 26, 2017 at 11:45 AM, Cullen Jennings (fluffy) <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote:
>> >
>> > I did explain the issue where this can happen in the PR. There may not be agreement that the case can not happen but there is also not agreement that it can not. So until someone explains to my why this can not happen, I think it should remain open. I'm not really following the mmusic conversation and have no idea why they are sending a liaison like that.
>> >
>> >
>> > > On Apr 25, 2017, at 11:52 AM, Bernard Aboba <Bernard.Aboba@microsoft.com <mailto:Bernard.Aboba@microsoft.com>> wrote:
>> > >
>> > > At the March 1, 2017 virtual interim, the WEBRTC WG discussed Issue 849 and PR 1026 and Peter and Cullen were given the task of producing “more exact info on the offers and answers”: https://www.w3.org/2017/03/01-webrtc-minutes <https://www.w3.org/2017/03/01-webrtc-minutes>
>> > >
>> > > Since then, we have had considerable discussion on Github relating to PR 1026 , as well as related discussion on the IETF MMUSIC WG mailing list and at the IETF 98 MMUSIC WG meeting.
>> > >
>> > > Over time, the focus of the discussion has narrowed to whether it is possible for unverified media to arise within the WebRTC 1.0 API.
>> > >
>> > > The MMUSIC WG is now in the process of drafting a response to the W3C WEBRTC WG liaison statement :
>> > > https://mailarchive.ietf.org/arch/msg/mmusic/TcyynbwyBsmJhE9eLac-gt33wtQ <https://mailarchive.ietf.org/arch/msg/mmusic/TcyynbwyBsmJhE9eLac-gt33wtQ>
>> > >
>> > > In this draft liaison response, the IETF MMUSIC WG indicates that they “would like to request a clarification of the exact sequence of events that WEBRTC believes can lead to this.  In particular, we ask you to please show either
>> > >
>> > >       • How ICE can complete prior to DTLS fingerprint exchange, or
>> > >       • How media can be received prior to ICE completing”
>> > >
>> > > Looking over the discussion of PR 1026 , multiple scenarios are investigated, but in the end, it appears that in each scenario the above conditions cannot be met.
>> > >
>> > > Given the extensive discussion that has taken place, and the inability to come up with a sequence of events, I would like to propose that we close Issue 849.
>> > >
>> > > Thoughts?
>> >
>> >
>> 
>>