Re: Identity mechanism at risk?

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

On 3/14/17 04:35, Dominique Hazael-Massieux wrote:
> Hi all,
>
> As we are getting closer to clearing our issue lists for webrtc-pc and
> thus hopefully moving to Candidate Recommendation soon, and looking at
> the overall rough implementation status of the spec, it strikes me that
> at the moment the identity mechanism of the spec is one part for which I
> have very little clarity on implementations plan beyond Firefox.
>
>
> Given that part of the CR process is to demonstrate that each of the
> feature in the spec will be getting two independent implementations, I'm
> wondering how likely we feel we will achieve this for that part of the spec.
>
> In particular, if our current impression is that it is unlikely, it
> might be useful to mark it at risk [1] - beyond the small process
> efficiency it gives (not needing to go back to CR to remove it from the
> spec if we can't demonstrate interop), I think it would also serve as a
> useful way to draw attention to the community that they may voice their
> concerns one way or the other on the lack of adoption of this.
>
> Thoughts?
>
> (I've raised https://github.com/w3c/webrtc-pc/issues/1074 to track this)
>
> Dom
>
> 1. https://www.w3.org/2017/Process-20170301/#candidate-rec
>


-- 
Adam Roach
Principal Engineer, Mozilla