Draft: draft-ietf-rtcweb-security

Commentary: Please double check the line 863 change .
In the system shown in fig.simple, Alice and Bob both have WebRTC-
enabled browsers and they visit some Web server which operates a
calling service.  Each of their browsers exposes standardized
JavaScript calling APIs (implementated as browser built-ins) which
are used by the Web server to set up a call between Alice and Bob.
The Web server also serves as the signaling channel to transport
control messages between the browsers.  While this system is
topologically similar to a conventional SIP-based system (with the
Web server acting as the signaling service and browsers acting as
softphones), control has moved to the central Web server; the browser
simply provides API points that are used by the calling service.  As
with any Web application, the Web server can move logic between the
server and JavaScript in the browser, but regardless of where the
code is executing, it is ultimately under control of the server.
In the system shown in fig.simple, Alice and Bob both have WebRTC-
enabled browsers and they visit some Web server which operates a
calling service.  Each of their browsers exposes standardized
JavaScript calling APIs (implemented as browser built-ins) which are
used by the Web server to set up a call between Alice and Bob.  The
Web server also serves as the signaling channel to transport control
messages between the browsers.  While this system is topologically
similar to a conventional SIP-based system (with the Web server
acting as the signaling service and browsers acting as softphones),
control has moved to the central Web server; the browser simply
provides API points that are used by the calling service.  As with
any Web application, the Web server can move logic between the server
and JavaScript in the browser, but regardless of where the code is
executing, it is ultimately under control of the server.
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).
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 an 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).
Note that consent verification is not sufficient to prevent overuse
of network resources.  Because WebRTC allows for a Web site to create
data flows between two browser instances without user consent, it is
possible for a malicious site to chew up a signficant amount of a
user's bandwidth without incurring significant costs to himself by
setting up such a channel to another user.  However, as a practical
matter there are a large number of Web sites which can act as data
sources, so an attacker can at least use downlink bandwidth with
existing Web APIs.  However, this potential DoS vector reinforces the
need for adequate congestion control for WebRTC protocols to ensure
that they play fair with other demands on the user's bandwidth.
Note that consent verification is not sufficient to prevent overuse
of network resources.  Because WebRTC allows for a Web site to create
data flows between two browser instances without user consent, it is
possible for a malicious site to chew up a significant amount of a
user's bandwidth without incurring significant costs to himself by
setting up such a channel to another user.  However, as a practical
matter there are a large number of Web sites which can act as data
sources, so an attacker can at least use downlink bandwidth with
existing Web APIs.  However, this potential DoS vector reinforces the
need for adequate congestion control for WebRTC protocols to ensure
that they play fair with other demands on the user's bandwidth.
Once initial consent is verified, we also need to verify continuing
consent, in order to avoid attacks where two people briefly share an
IP (e.g., behind a NAT in an Internet cafe) and the attacker arranges
for a large, unstoppable, traffic flow to the network and then
leaves.  The appropriate technologies here are fairly similar to
those for initial consent, though are perhaps weaker since the
threats is less severe.
Once initial consent is verified, we also need to verify continuing
consent, in order to avoid attacks where two people briefly share an
IP (e.g., behind a NAT in an Internet cafe) and the attacker arranges
for a large, unstoppable, traffic flow to the network and then
leaves.  The appropriate technologies here are fairly similar to
those for initial consent, though are perhaps weaker since the
threats are less severe.
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.
ZRTP RFC6189 uses a "short authentication string" (SAS) which is
derived from the key agreement protocol.  This SAS is designed to be
compared by the users (e.g., read aloud over the the voice channel or
transmitted via an out of band channel) and if confirmed by both
sides precludes MITM attack.  The intention is that the SAS is used
once and then key continuity (though a different mechanism from that
discussed above) is used thereafter.
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.
ZRTP RFC6189 uses a "short authentication string" (SAS) which is
derived from the key agreement protocol.  This SAS is designed to be
compared by the users (e.g., read aloud over the voice channel or
transmitted via an out of band channel) and if confirmed by both
sides precludes MITM attack.  The intention is that the SAS is used
once and then key continuity (though a different mechanism from that
discussed above) is used thereafter.
Additionally, it is unclear that users will actually use an SAS.  As
discussed above, the browser UI constraints preclude requiring the
SAS exchange prior to completing the call and so it must be
voluntary; at most the browser will provide some UI indicator that
the SAS has not yet been checked.  However, it it is well-known that
when faced with optional security mechanisms, many users simply
ignore them whitten-johnny.
Additionally, it is unclear that users will actually use an SAS.  As
discussed above, the browser UI constraints preclude requiring the
SAS exchange prior to completing the call and so it must be
voluntary; at most the browser will provide some UI indicator that
the SAS has not yet been checked.  However, it is well-known that
when faced with optional security mechanisms, many users simply
ignore them whitten-johnny.