Draft: draft-ietf-rtcweb-security

Commentary: ( or attempts to at least ) . 
 ready to merge 
 Need to work through  's .
In this model, then, the browser acts as a TRUSTED COMPUTING BASE
(TCB) both from the user's perspective and to some extent from the
server's.  While HTML and JavaScript (JS) provided by the server can
cause the browser to execute a variety of actions, those scripts
operate in a sandbox that isolates them both from the user's computer
and from each other, as detailed below.
Conventionally, we refer to either WEB ATTACKERS, who are able to
induce you to visit their sites but do not control the network, and
NETWORK ATTACKERS, who are able to control your network.  Network
attackers correspond to the RFC3552 "Internet Threat Model".  Note
that for non-HTTPS traffic, a network attacker is also a Web
attacker, since it can inject traffic as if it were any non-HTTPS Web
site.  Thus, when analyzing HTTP connections, we must assume that
traffic is going to the attacker.
In this model, then, the browser acts as a Trusted Coomputing Base
(TCB) both from the user's perspective and to some extent from the
server's.  While HTML and JavaScript (JS) provided by the server can
cause the browser to execute a variety of actions, those scripts
operate in a sandbox that isolates them both from the user's computer
and from each other, as detailed below.
Conventionally, we refer to either web attackers, who are able to
induce you to visit their sites but do not control the network, and
network attackers, who are able to control your network.  Network
attackers correspond to the RFC3552 "Internet Threat Model".  Note
that in some cases, a network attacker is also a web attacker, since
transport protocols that do not provide integrity protection allow
the network to inject traffic as if they were any communications
peer.  TLS, and HTTPS in particular, prevent against these attacks,
but when analyzing HTTP connections, we must assume that traffic is
going to the attacker.
In either case, identity is at the heart of any consent decision.
Moreover, the identity of the party the browser is connecting to is
all that the browser can meaningfully enforce; if you are calling A,
A can simply forward the media to C.  Similarly, if you authorize A
to place a call to B, A can call C instead.  In either case, all the
browser is able to do is verify and check authorization for whoever
is controlling where the media goes.  The target of the media can of
course advertise a security/privacy policy, but this is not something
that the browser can enforce.  Even so, there are a variety of
different consent scenarios that motivate different technical consent
mechanisms.  We discuss these mechanisms in the sections below.
In either case, identity is at the heart of any consent decision.
Moreover, the identity of the party the browser is connecting to is
all that the browser can meaningfully enforce; if you are calling A,
A can simply forward the media to C.  Similarly, if you authorize A
to place a call to B, A can call C instead.  In either cases, all the
browser is able to do is verify and check authorization for whoever
is controlling where the media goes.  The target of the media can of
course advertise a security/privacy policy, but this is not something
that the browser can enforce.  Even so, there are a variety of
different consent scenarios that motivate different technical consent
mechanisms.  We discuss these mechanisms in the sections below.
Now that we have seen another use case, we can start to reason about
the security requirements.
Now that we have described the calling scenarios, we can start to
reason about the security requirements.
The attacker forges the response apparently from http://calling-
service.example.com/ to inject JS to initiate a call to himself.
The attacker forges the response from http://calling-
service.example.com/ to inject JS to initiate a call to himself.
Even if calls are only possible from HTTPS [RFC2818] sites, if those
sites include active content (e.g., JavaScript) from an untrusted
site, that JavaScript is executed in the security context of the page
finer-grained.  This could lead to compromise of a call even if the
parent page is safe.  Note: this issue is not restricted to PAGES
which contain untrusted content.  If a page from a given origin ever
loads JavaScript from an attacker, then it is possible for that
attacker to infect the browser's notion of that origin semi-
permanently.
Even if calls are only possible from HTTPS [RFC2818] sites, if those
sites include active content (e.g., JavaScript) from an untrusted
site, that JavaScript is executed in the security context of the page
finer-grained.  This could lead to compromise of a call even if the
parent page is safe.  Note: this issue is not restricted to PAGES
which contain untrusted content.  If any page from a given origin
ever loads JavaScript from an attacker, then it is possible for that
attacker to infect the browser's notion of that origin semi-
permanently.
Moreover, it is trivial to bypass even this kind of mechanism.
Recall that unlike the case of SSH, the browser never directly gets
the peer's identity from the user.  Rather, it is provided by the
calling service.  Even enabling a mechanism of this type would
require an API to allow the calling service to tell the browser "this
is a call to user X".  All the calling service needs to do to avoid
triggering a key continuity warning is to tell the browser that "this
is a call to user Y" where Y is confusable with X.  Even if the user
actually checks the other side's name (which all available evidence
indicates is unlikely), this would require (a) the browser has
trusted UI to provide the name and (b) the user to not be fooled by
similar appearing names.
Moreover, it is trivial to bypass even this kind of mechanism.
Recall that unlike the case of SSH, the browser never directly gets
the peer's identity from the user.  Rather, it is provided by the
calling service.  Even enabling a mechanism of this type would
require an API to allow the calling service to tell the browser "this
is a call to user X".  All the calling service needs to do to avoid
triggering a key continuity warning is to tell the browser that "this
is a call to user Y" where Y is confusable with X.  Even if the user
actually checks the other side's name (which all available evidence
indicates is unlikely), this would require (a) the browser to use the
trusted UI to provide the name and (b) the user to not be fooled by
similar appearing names.
local side and the remote side.  I.e., I must be able to verify that
the person I am calling has engaged a secure media mode (see
sec.malicious).  In order to achieve this it will be necessary to
cryptographically bind an indication of the local media access policy
into the cryptographic authentication procedures detailed in the
previous sections.
local side and the remote side.  I.e., users must be able to verify
that the person called has engaged a secure media mode (see
sec.malicious).  In order to achieve this it will be necessary to
cryptographically bind an indication of the local media access policy
into the cryptographic authentication procedures detailed in the
previous sections.