Draft: draft-ietf-rtcweb-security

Commentary: I - D nits complained about a couple of outdated and unused references . This fixes them . Note that a few still remain .
Even if calls are only possible from HTTPS 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.
There also needs to be some mechanism for the browser to verify that
the target of the traffic continues to wish to receive it.  Because
ICE keepalives are indications, they will not work here.  I-D.ietf-
rtcweb-stun-consent-freshness describes the mechanism for providing
consent freshness.
There also needs to be some mechanism for the browser to verify that
the target of the traffic continues to wish to receive it.  Because
ICE keepalives are indications, they will not work here.  RFC7675
describes the mechanism for providing consent freshness.
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 RFC4347 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 to the WebRTC
context, where the threat model is somewhat different.