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

By happy to join a call on this. Let me be clear that I think is a very bad idea postpone DTLS handshake. I think the tls-id should be in the offer and both sides should use it. 


> 


> On May 3, 2017, at 2:00 PM, Roman Shpount <roman@telurix.com> wrote:
> 
> On Wed, May 3, 2017 at 4:09 AM, T H Panton <thp@westhawk.co.uk> wrote:
> 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.
> 
> This case seems to be legitimate but extremely unlikely.
>  
> As Roman says, "prohibit to start DTLS handshake until the answer is received" will cover that unlikely case nicely.
> 
> 
> Do you agree with me that it is a good idea to postpone DTLS handshake until answer is received?
> 
> I see no benefit in allowing DTLS handshake to proceed before the answer is received by the end point, but I do see a lot of potential problems. As I have mentioned before the main motivation for doing this was to convert unusual call scenarios to the most common behavior and to avoid unverified media and handshake in the process. I think this would make the whole negotiation process easier to test and will prevent unexpected negotiation flows.
> 
> Regards,
> _____________
> Roman Shpount
>

Received on Wednesday, 3 May 2017 23:30:40 UTC