- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Thu, 4 May 2017 02:26:06 +0000
- To: Martin Thomson <martin.thomson@gmail.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>
Hmm .. not sure that is the case depending on what you assume about security of signaling. But also never sure I fully understand the unathenticated key attack. Lets talk about it on the phone some time. But keep in mind ... I am totally fine with no security till you get the answer, what I need is that you can negotiate DTLS before the answer and later when you get the answer you find out if it is secure, who you are talking to, etc. Next week wed afternoon and Friday are mostly open for me. The week after that I am on vacation. > On May 3, 2017, at 6:19 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > > 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 02:26:47 UTC