Draft: draft-ietf-rtcweb-security

Commentary: Addressing  's nits from his . There was one I was n't sure what to do with ( see ) . 
 In  's AD review : I ca n't parse this sentence . Consider reworking . Even if calls are only possible from HTTPS [ RFC2818 ] sites , if the site embeds active content ( e.g. , JavaScript ) that is fetched over HTTP or from an untrusted site , because that JavaScript is executed in the security context of the page [ finer - grained ] . 
 do you have a proposal here ? 
 how about the following knowing that you 're trying to bridge the previous that talks about HTTP origins : It is also dangerous to allow WebRTC functionality from HTTPS [ RFC2818 ] origins that embed mixed content because if the site embeds active content ( e.g. , JavaScript ) that is fetched over HTTP or from an untrusted site that JavaScript is executed in the security context of the page [ finer - grained ] . Note this would replace the 1st two sentences in the last para of § 4.1.4 copied here for convenience : Even if calls are only possible from HTTPS [ RFC2818 ] sites , if the site embeds active content ( e.g. , JavaScript ) that is fetched over HTTP or from an untrusted site , because that JavaScript is executed in the security context of the page [ finer - grained ] . Thus , it is also dangerous to allow WebRTC functionality from HTTPS origins that embed mixed content . 
 Has this been overtaken by events ? I mean , while it might have been the case that some browsers permitted the use of active mixed content when this was originally written , I do n't believe that any currently do . Could the text be removed ? 
 I guess it could , but this is the section on " Security Properties of the Calling Page " so maybe for posterity we make this tweak , but also add to the end of the paragraph : Note : the issue of active mixed content was an issue , but is now implemented by browsers . And , ( not having read the link entirely ) we also informatively point to this W3C draft ?
The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications
between Web browsers, generally called "WebRTC" I-D.ietf-rtcweb-
overview.  The major use cases for WebRTC technology are real-time
audio and/or video calls, Web conferencing, and direct data transfer.
Unlike most conventional real-time systems, (e.g., SIP-basedRFC3261
soft phones) WebRTC communications are directly controlled by some
Web server.  A simple case is shown below.
The Real-Time Communications on the Web (RTCWEB) working group
standardized protocols for real-time communications between Web
browsers, generally called "WebRTC" I-D.ietf-rtcweb-overview.  The
major use cases for WebRTC technology are real-time audio and/or
video calls, Web conferencing, and direct data transfer.  Unlike most
conventional real-time systems, (e.g., SIP-based RFC3261 soft phones)
WebRTC communications are directly controlled by some Web server.  A
simple case is shown below.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Many other resources are accessible but isolated.  For instance,
while scripts are allowed to make HTTP requests via the
XMLHttpRequest() API those requests are not allowed to be made to any
server, but rather solely to the same ORIGIN from whence the script
came RFC6454 (although CORS CORS and WebSockets RFC6455 provide a
escape hatch from this restriction, as described below.)  This SAME
ORIGIN POLICY (SOP) prevents server A from mounting attacks on server
B via the user's browser, which protects both the user (e.g., from
misuse of his credentials) and the server B (e.g., from DoS attack).
Many other resources are accessible but isolated.  For instance,
while scripts are allowed to make HTTP requests via the
XMLHttpRequest() API (see XmlHttpRequest) those requests are not
allowed to be made to any server, but rather solely to the same
ORIGIN from whence the script came RFC6454 (although CORS CORS and
WebSockets RFC6455 provide a escape hatch from this restriction, as
described below.)  This SAME ORIGIN POLICY (SOP) prevents server A
from mounting attacks on server B via the user's browser, which
protects both the user (e.g., from misuse of his credentials) and the
server B (e.g., from DoS attack).
the user interface chrome must clearly display elements showing that
the call is continuing in order to avoid attacks where the calling
site just leaves it up indefinitely but shows a Web UI that implies
otherwise.
the user interface chrome, which is the representation through which
the user interacts with the user agent itself, must clearly display
elements showing that the call is continuing in order to avoid
attacks where the calling site just leaves it up indefinitely but
shows a Web UI that implies otherwise.
The other two options are designed to restrict calls to a given
target.  Callee-oriented consent provided by the calling site not
work well because a malicious site can claim that the user is calling
any user of his choice.  One fix for this is to tie calls to a
cryptographically established identity.  While not suitable for all
cases, this approach may be useful for some.  If we consider the case
of advertising, it's not particularly convenient to require the
advertiser to instantiate an iframe on the hosting site just to get
permission; a more convenient approach is to cryptographically tie
the advertiser's certificate to the communication directly.  We're
still tying permissions to origin here, but to the media origin (and-
or destination) rather than to the Web origin.  I-D.ietf-rtcweb-
security-arch describes mechanisms which facilitate this sort of
consent.
The other two options are designed to restrict calls to a given
target.  Callee-oriented consent provided by the calling site would
not work well because a malicious site can claim that the user is
calling any user of his choice.  One fix for this is to tie calls to
a cryptographically-established identity.  While not suitable for all
cases, this approach may be useful for some.  If we consider the case
of advertising, it's not particularly convenient to require the
advertiser to instantiate an iframe on the hosting site just to get
permission; a more convenient approach is to cryptographically tie
the advertiser's certificate to the communication directly.  We're
still tying permissions to origin here, but to the media origin (and-
or destination) rather than to the Web origin.  I-D.ietf-rtcweb-
security-arch describes mechanisms which facilitate this sort of
consent.
Even if calls are only possible from HTTPS [RFC2818] sites, if the
site embeds active content (e.g., JavaScript) that is fetched over
HTTP or from an untrusted site, because that JavaScript is executed
in the security context of the page finer-grained.  Thus, it is also
dangerous to allow WebRTC functionality from HTTPS origins that embed
mixed content.  Note: this issue is not restricted to PAGES which
contain mixed content.  If a page from a given origin ever loads
mixed content then it is possible for a network attacker to infect
the browser's notion of that origin semi-permanently.
Even if calls are only possible from HTTPS [RFC2818] sites, if the
site embeds active content (e.g., JavaScript) that is fetched over
HTTP or from an untrusted site, because that JavaScript is executed
in the security context of the page finer-grained.  Thus, it is also
dangerous to allow WebRTC functionality from HTTPS origins that embed
mixed-content.  Note: this issue is not restricted to PAGES which
contain mixed content.  If a page from a given origin ever loads
mixed content then it is possible for a network attacker to infect
the browser's notion of that origin semi-permanently.
Use or RTCP as an implicit reachability check.
Use of RTCP as an implicit reachability check.
Note that as soon as the callee sends their ICE candidates, the
caller learns the callee's IP addresses.  The callee's server
reflexive address reveals a lot of information about the callee's
location.  In order to avoid tracking, implementations may wish to
suppress the start of ICE negotiation until the callee has answered.
In addition, either side may wish to hide their location entirely by
forcing all traffic through a TURN server.
Note that as soon as the callee sends their ICE candidates, the
caller learns the callee's IP addresses.  The callee's server
reflexive address reveals a lot of information about the callee's
location.  In order to avoid tracking, implementations may wish to
suppress the start of ICE negotiation until the callee has answered.
In addition, either side may wish to hide their location from the
other side entirely by forcing all traffic through a TURN server.
Finally, we consider a problem familiar from the SIP world:
communications security.  For obvious reasons, it MUST be possible
for the communicating parties to establish a channel which is secure
against both message recovery and message modification.  (See RFC5479
for more details.)  This service must be provided for both data and
voice/video.  Ideally the same security mechanisms would be used for
both types of content.  Technology for providing this service (for
instance, SRTP RFC3711, DTLS RFC6347 and DTLS-SRTP RFC5763) is well
understood.  However, we must examine this technology to the WebRTC
context, where the threat model is somewhat different.
Finally, we consider a problem familiar from the SIP world:
communications security.  For obvious reasons, it MUST be possible
for the communicating parties to establish a channel which is secure
against both message recovery and message modification.  (See RFC5479
for more details.)  This service must be provided for both data and
voice/video.  Ideally the same security mechanisms would be used for
both types of content.  Technology for providing this service (for
instance, SRTP RFC3711, DTLS RFC6347 and DTLS-SRTP RFC5763) is well
understood.  However, we must examine this technology in the WebRTC
context, where the threat model is somewhat different.
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 close to 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 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 trusted
UI to provide the name and (b) the user to not be fooled by similar
appearing names.
The conventional approach to providing communications identity has of
course been to have some third party identity system (e.g., PKI) to
authenticate the endpoints.  Such mechanisms have proven to be too
cumbersome for use by typical users (and nearly too cumbersome for
administrators).  However, a new generation of Web-based identity
providers (BrowserID, Federated Google Login, Facebook Connect,
OAuth, OpenID, WebFinger), has recently been developed and use Web
technologies to provide lightweight (from the user's perspective)
third-party authenticated transactions.  It is possible to use
systems of this type to authenticate WebRTC calls, linking them to
existing user notions of identity (e.g., Facebook adjacencies).
Specifically, the third-party identity system is used to bind the
user's identity to cryptographic keying material which is then used
to authenticate the calling endpoints.  Calls which are authenticated
in this fashion are naturally resistant even to active MITM attack by
the calling site.
The conventional approach to providing communications identity has of
course been to have some third party identity system (e.g., PKI) to
authenticate the endpoints.  Such mechanisms have proven to be too
cumbersome for use by typical users (and nearly too cumbersome for
administrators).  However, a new generation of Web-based identity
providers (BrowserID, Federated Google Login, Facebook Connect, OAuth
RFC6749, OpenID OpenID, WebFinger RFC7033), has recently been
developed and use Web technologies to provide lightweight (from the
user's perspective) third-party authenticated transactions.  It is
possible to use systems of this type to authenticate WebRTC calls,
linking them to existing user notions of identity (e.g., Facebook
adjacencies).  Specifically, the third-party identity system is used
to bind the user's identity to cryptographic keying material which is
then used to authenticate the calling endpoints.  Calls which are
authenticated in this fashion are naturally resistant even to active
MITM attack by the calling site.
the person I am calling has engaged a secure media mode.  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.
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.
Any new set of API features adds a risk of browser fingerprinting,
and WebRTC is no exception.  Specifically, sites can use the presence
or absence of specific devices as a browser fingerprint.  In general,
the API needs to be balanced between functionality and the
incremental fingerprint risk.