W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2017

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 4 May 2017 10:19:38 +1000
Message-ID: <CABkgnnUELaZh1qPh6unVnfFfvSdrRiVk+mhsfQVatmW6fEGgkQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:50 UTC