Re: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

I wanted to quickly respond to the two discuss questions you have.

On 3/6/19 1:08 PM, Datatracker on behalf of Benjamin Kaduk wrote:
> Mutually-verifiable "secure mode" seems to require that the peer's browser be included in
> the TCB, which is a bit hard to swallow.  Are we comfortable wrapping that in alongside
> "we trust the peer to not be malicious"?


You are correct that this is part of the assumption of the model, and 
the reason it makes any sense at all is that the "attacker" of concern 
here is a web app. To mount an attack with the current assumptions, a 
malicious app would need to somehow compel a user to install a malicious 
browser platform prior to using its app.

Another way of thinking about this is: unless we are going to require 
the validated use of a crytographically secured operating system with 
signed, secure audio and video drivers that require HDCP, running on 
Trusted Computing hardware, then we need to draw a line somewhere, 
beyond which the media is considered in a "safe enough" environment.


> It's not clear how much benefit we can get from *optional* third-party identity providers;
> won't the calling service have the ability to silently downgrade to their non-usage even if
> both calling peers support it?


The notion here is that the web browser itself provides indicia that 
mean "this media is secure and being sent only to <remote party's 
identity>" in a way that web pages cannot. So you are correct that it's 
up to the web app to opt-in to this feature; but whether they do so is 
user-visible. So, e.g., if you host a service that claims its media 
cannot be intercepted (e.g., in the style of Signal, Wire, or WhatsApp), 
users can trivially verify whether such a claim is true.

/a