Draft: draft-ietf-rtcweb-security-arch

Commentary: Changes based on . 
 PTAL Also , there were two I was n't entirely sure how to address : : " In this case , the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints . " Applied by the recipient ? ( consider active voice ) . Also , why not MUST ? Do n't unexpected things happen if the recipient does n't do this ? : " Because HTTP origins can not be securely established against network attackers , implementations MUST NOT allow the setting of permanent access permissions for HTTP origins . Implementations MUST refuse all permissions grants for HTTP origins . " ( nit - ish ) - The MUST NOT seems non - constraining considering the last sentence . Or am I reading that sentence wrong ? 
 case , the established identity can be attributed to existing DTLS connections with fingerprints that match any of the included fingerprints , plus any new connections established using one of those fingerprints . This does n't need a SHOULD , it 's axiomatic . The 6.2 thing is a interesting . The second statement appears to be merely a restatement of the first , for emphasis , but it is a stronger statement . So  is right , the first sentence is unnecessary . attackers , implementations MUST refuse all requests for permission grants from HTTP origins . 
 okay fixed these points . On to    . 
 I do n't think this " SHOULD " -"can " for identities is right . Actually , I think it needs to be a MUST . 
 This wo n't build , but it looks fine otherwise .
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-
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):
A more complicated system might allow for interdomain calling, as
shown in fig.multidomain.  The protocol to be used between the
domains is not standardized by WebRTC, but given the installed base
and the form of the WebRTC API is likely to be something SDP-based
like SIP.
Paragraph (version B):
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, via
a JavaScript (JS) API as shown in fig.simple.
Paragraph (version B):
A more complicated system might allow for interdomain calling, as
shown in fig.multidomain.  The protocol to be used between the
domains is not standardized by WebRTC, but given the installed base
and the form of the WebRTC API is likely to be something SDP-based
like SIP or something like Extensible Messaging and Presence Protocol
(XMPP) RFC6120.
Paragraph (version A):
Alice is logged onto the calling service and decides to call Bob.
She can see from the calling service that he is online and the
calling service presents a JS UI in the form of a button next to
Bob's name which says "Call".  Alice clicks the button, which
initiates a JS callback that instantiates a PeerConnection object.
This does not require a security check: JS from any origin is allowed
to get this far.
Paragraph (version B):
Alice is logged onto the calling service and decides to call Bob.
She can see from the calling service that he is online and the
calling service presents a JS UI in the form of a button next to
Bob's name that says "Call".  Alice clicks the button, which
initiates a JS callback that instantiates a PeerConnection object.
This does not require a security check: JS from any origin is allowed
to get this far.
Paragraph (version A):
When modifying a session, if the set of fingerprints is unchanged,
then the sender MAY send the same 'identity' attribute.  In this
case, the established identity SHOULD be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires
that each media section use the same set of fingerprints for every
media section.
Paragraph (version B):
When modifying a session, if the set of fingerprints is unchanged,
then the sender MAY send the same 'identity' attribute.  In this
case, the established identity can be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires
that each media section use the same set of fingerprints for every
media section.
Paragraph (version A):
Because HTTP origins cannot be securely established against network
attackers, implementations MUST NOT allow the setting of permanent
access permissions for HTTP origins.  Implementations MUST refuse all
permissions grants for HTTP origins.
Paragraph (version A):
In addition, they SHOULD support requests for access that promise
that media from this grant will be sent to a single communicating
peer (obviously there could be other requests for other peers).
E.g., "Call customerservice@ford.com".  The semantics of this request
are that the media stream from the camera and microphone will only be
routed through a connection which has been cryptographically verified
(through the IdP mechanism or an X.509 certificate in the DTLS-SRTP
handshake) as being associated with the stated identity.  Note that
it is unlikely that browsers would have an X.509 certificate, but
servers might.  Browsers servicing such requests SHOULD clearly
indicate that identity to the user when asking for permission.  The
idea behind this type of permissions is that a user might have a
fairly narrow list of peers he is willing to communicate with, e.g.,
"my mother" rather than "anyone on Facebook".  Narrow permissions
grants allow the browser to do that enforcement.
Paragraph (version B):
Because HTTP origins cannot be securely established against network
attackers, implementations MUST refuse all permissions grants for
HTTP origins.
Paragraph (version B):
In addition, they SHOULD support requests for access that promise
that media from this grant will be sent to a single communicating
peer (obviously there could be other requests for other peers), e.g.,
"Call customerservice@ford.com".  The semantics of this request are
that the media stream from the camera and microphone will only be
routed through a connection which has been cryptographically verified
(through the IdP mechanism or an X.509 certificate in the DTLS-SRTP
handshake) as being associated with the stated identity.  Note that
it is unlikely that browsers would have X.509 certificates, but
servers might.  Browsers servicing such requests SHOULD clearly
indicate that identity to the user when asking for permission.  The
idea behind this type of permissions is that a user might have a
fairly narrow list of peers he is willing to communicate with, e.g.,
"my mother" rather than "anyone on Facebook".  Narrow permissions
grants allow the browser to do that enforcement.
Paragraph (version A):
Clients MAY permit the formation of data channels without any direct
user approval.  Because sites can always tunnel data through the
server, further restrictions on the data channel do not provide any
additional security.  (though see sec.proposal.communications.consent
for a related issue).
Paragraph (version B):
Browsers MAY permit the formation of data channels without any direct
user approval.  Because sites can always tunnel data through the
server, further restrictions on the data channel do not provide any
additional security.  (though see sec.proposal.communications.consent
for a related issue).
Paragraph (version A):
Implementations MUST implement SRTP RFC3711.  Implementations MUST
implement DTLS RFC6347 and DTLS-SRTP RFC5764 for SRTP keying.
Implementations MUST implement RFC8261.
Paragraph (version B):
Implementations MUST implement SRTP RFC3711.  Implementations MUST
implement DTLS RFC6347 and DTLS-SRTP RFC5764 for SRTP keying.
Implementations MUST implement SCTP over DTLS RFC8261.