- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 4 May 2017 10:19:38 +1000
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- Cc: Roman Shpount <roman@telurix.com>, Tim Panton <thp@westhawk.co.uk>, Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 4 May 2017 at 09:30, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote: > > 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. Unfortunately that doesn't work for the offerer. The offerer can't validate a ClientHello from the answerer without seeing the signaling that contains the answerer's tls-id value. You could decide that you don't care about the unknown key share attack. That leads to having two different designs, with all the associated complexity. And we would have to be very careful to ensure that one does not jeopardize the other. It seems like we have a choice here between some security goals and this use case with the third axis being the amount of complexity we are prepared to take on in specifications and implementations. That's inherently a security risk as well.
Received on Thursday, 4 May 2017 00:20:12 UTC