Re: Identity mechanism at risk?

It is possible to contribute an implementation to an open source browser
such as chromium.

14. mar. 2017 4:42 p.m. skrev "T H Panton" <thp@westhawk.co.uk>:

>
> > 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 Friday, 17 March 2017 09:00:00 UTC