- From: T H Panton <thp@westhawk.co.uk>
- Date: Tue, 14 Mar 2017 15:39:18 +0000
- To: Adam Roach <abr@mozilla.com>
- Cc: Dominique Hazael-Massieux <dom@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
> On 14 Mar 2017, at 15:01, Adam Roach <abr@mozilla.com> wrote: > > Without commenting on the process aspects of this, I'm going to jump all the way to "voicing concerns about the lack of adoption of this." > > Preventing trivial MITM attacks by WebRTC service providers is impossible without an identity mechanism. That in and of itself should be of sufficient importance as to draw more attention. > > On top of this: one of the things the IETF is working on at the moment is PERC, which provides a framework in which a conference mixer can be deployed that is trusted to handle the basic conference logic, but which isn't trusted to have access to the media. We've seen interest, in particular, from the financial industry for such systems. Without the WebRTC identity mechanism, it becomes impossible to build such systems at all: you need to have authenticated identities associated with each participant, or media interception becomes trivial. > > To be absolutely clear -- we had a long and drawn-out out series of conversations in the IETF that resulted in the decision to use DTLS-SRTP rather than SDES; the rationale was that doing so is the only way it could be possible to build a system that assures the user that their conversation is confidential. Publishing a spec without an identity mechanism would utterly defeat that. > > /a I'm sympathetic to the goals of the identity mechanism and support it's inclusion in the webRTC standardization effort. I'd be happy to collaborate on a second implementation but whilst I do have most of an independent rtcweb stack, unfortunately I don't have a browser ;-) Also it is fair to say that there are other ways of validating a webRTC identity which work without this proposal. They tend to have a more restricted scope, but within their field they do the job of MiTM detection and prevention. Tim.
Received on Tuesday, 14 March 2017 15:39:58 UTC