Draft: draft-ietf-rtcweb-security-arch

Commentary: Some nits I noted .
Paragraph (version A):
The Real-Time Communications on the Web (WebRTC) working group is
tasked with standardizing protocols for real-time communications
between Web browsers.  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, via a JavaScript (JS) API as shown in
fig.simple.
Paragraph (version B):
The Real-Time Communications on the Web (WebRTC) working group is
tasked with standardizing protocols for real-time communications
between Web browsers.  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, via a JavaScript (JS) API as shown in
fig.simple.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
This separation of identity provision and signaling isn't
particularly important in "closed world" cases where Alice and Bob
are users on the same social network and have identities based on
that domain (fig.proposal.idp) However, there are important settings
where that is not the case, such as federation (calls from one domain
to another; fig.proposal-federated.idp) and calling on untrusted
sites, such as where two users who have a relationship via a given
social network want to call each other on another, untrusted, site,
such as a poker site.
Paragraph (version B):
This separation of identity provision and signaling isn't
particularly important in "closed world" cases where Alice and Bob
are users on the same social network and have identities based on
that domain (fig.proposal.idp).  However, there are important
settings where that is not the case, such as federation (calls from
one domain to another; fig.proposal-federated.idp) and calling on
untrusted sites, such as where two users who have a relationship via
a given social network want to call each other on another, untrusted,
site, such as a poker site.
Paragraph (version A):
This message is sent to the signaling server, e.g., by XMLHttpRequest
XmlHttpRequest or by WebSockets RFC6455.  preferably over TLS
RFC5246.  The signaling server processes the message from Alice's
browser, determines that this is a call to Bob and sends a signaling
message to Bob's browser (again, the format is currently undefined).
The JS on Bob's browser processes it, and alerts Bob to the incoming
call and to Alice's identity.  In this case, Alice has provided an
identity assertion and so Bob's browser contacts Alice's identity
provider (again, this is done in a generic way so the browser has no
specific knowledge of the IdP) to verify the assertion.  This allows
the browser to display a trusted element in the browser chrome
indicating that a call is coming in from Alice.  If Alice is in Bob's
address book, then this interface might also include her real name, a
picture, etc.  The calling site will also provide some user interface
element (e.g., a button) to allow Bob to answer the call, though this
is most likely not part of the trusted UI.
Paragraph (version B):
This message is sent to the signaling server, e.g., by XMLHttpRequest
XmlHttpRequest or by WebSockets RFC6455, preferably over TLS RFC5246.
The signaling server processes the message from Alice's browser,
determines that this is a call to Bob and sends a signaling message
to Bob's browser (again, the format is currently undefined).  The JS
on Bob's browser processes it, and alerts Bob to the incoming call
and to Alice's identity.  In this case, Alice has provided an
identity assertion and so Bob's browser contacts Alice's identity
provider (again, this is done in a generic way so the browser has no
specific knowledge of the IdP) to verify the assertion.  This allows
the browser to display a trusted element in the browser chrome
indicating that a call is coming in from Alice.  If Alice is in Bob's
address book, then this interface might also include her real name, a
picture, etc.  The calling site will also provide some user interface
element (e.g., a button) to allow Bob to answer the call, though this
is most likely not part of the trusted UI.
Paragraph (version A):
Of course, the call works perfectly well if either Alice or Bob
doesn't have a relationship with an IdP; they just get a lower level
of assurance.  I.e., they simply have whatever information their
calling site claims about the caller/calllee's identity.  Moreover,
Alice might wish to make an anonymous call through an anonymous
calling site, in which case she would of course just not provide any
identity assertion and the calling site would mask her identity from
Bob.
Paragraph (version B):
Of course, the call works perfectly well if either Alice or Bob
doesn't have a relationship with an IdP; they just get a lower level
of assurance.  I.e., they simply have whatever information their
calling site claims about the caller/callee's identity.  Moreover,
Alice might wish to make an anonymous call through an anonymous
calling site, in which case she would of course just not provide any
identity assertion and the calling site would mask her identity from
Bob.
Paragraph (version A):
All implementations MUST implement DTLS 1.0, with the cipher suite
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the FIPS186.  The DTLS-
SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported
for SRTP.  Implementations SHOULD implement DTLS 1.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
Implementations MUST favor cipher suites which support PFS over non-
PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.
Paragraph (version B):
All implementations MUST implement DTLS 1.0, with the cipher suite
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the FIPS186.  The DTLS-
SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported
for SRTP.  Implementations SHOULD implement DTLS 1.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
Implementations MUST favor cipher suites which support (Perfect
Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD
over non-AEAD cipher suites.
Paragraph (version A):
The "security characteristics" MUST include some mechanism to
allow an out-of-band verification of the peer, such as a
certificate fingerprint or an SAS.
Paragraph (version B):
The "security characteristics" MUST include some mechanism to
allow an out-of-band verification of the peer, such as a
certificate fingerprint or a Short Authentication String (SAS).
Paragraph (version A):
IdPs which don't have control of their section of the identity
space but instead verify user's identities via some unspecified
mechanism and then attest to it.  Because the IdP doesn't actually
control the namespace, RPs need to trust that the IdP is correctly
verifying AP identities, and there can potentially be multiple
IdPs attesting to the same section of the identity space.
Probably the best-known example of a third-party identity provider
is SSL certificates, where there are a large number of CAs all of
whom can attest to any domain name.
Paragraph (version B):
IdPs which don't have control of their section of the identity
space but instead verify user's identities via some unspecified
mechanism and then attest to it.  Because the IdP doesn't actually
control the namespace, RPs need to trust that the IdP is correctly
verifying AP identities, and there can potentially be multiple
IdPs attesting to the same section of the identity space.
Probably the best-known example of a third-party identity provider
is SSL/TLS certificates, where there are a large number of CAs all
of whom can attest to any domain name.
Paragraph (version A):
In order to protect against malicious content JavaScript, that
JavaScript MUST NOT be allowed to have direct access to---or perform
computations with---DTLS keys.  For instance, if content JS were able
to compute digital signatures, then it would be possible for content
JS to get an identity assertion for a browser's generated key and
then use that assertion plus a signature by the key to authenticate a
call protected under an ephemeral DH key controlled by the content
JS, thus violating the security guarantees otherwise provided by the
IdP mechanism.  Note that it is not sufficient merely to deny the
content JS direct access to the keys, as some have suggested doing
with the WebCrypto API.  webcrypto.  The JS must also not be allowed
to perform operations that would be valid for a DTLS endpoint.  By
far the safest approach is simply to deny the ability to perform any
operations that depend on secret information associated with the key.
Operations that depend on public information, such as exporting the
public key are of course safe.
Paragraph (version B):
In order to protect against malicious content JavaScript, that
JavaScript MUST NOT be allowed to have direct access to---or perform
computations with---DTLS keys.  For instance, if content JS were able
to compute digital signatures, then it would be possible for content
JS to get an identity assertion for a browser's generated key and
then use that assertion plus a signature by the key to authenticate a
call protected under an ephemeral Diffie-Hellman (DH) key controlled
by the content JS, thus violating the security guarantees otherwise
provided by the IdP mechanism.  Note that it is not sufficient merely
to deny the content JS direct access to the keys, as some have
suggested doing with the WebCrypto API webcrypto.  The JS must also
not be allowed to perform operations that would be valid for a DTLS
endpoint.  By far the safest approach is simply to deny the ability
to perform any operations that depend on secret information
associated with the key.  Operations that depend on public
information, such as exporting the public key are of course safe.