Original text:
1. <del> 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. </del>  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 <del> like SIP. </del>  This system presents a number of new security challenges, which are analyzed in I-D.ietf-rtcweb-security.  This document describes 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 <del> Bob's name which says "Call".  Alice clicks the button, which </del>  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. When modifying a session, if the set of fingerprints is unchanged, then the sender MAY send the same 'identity' attribute.  In this <del> case, the established identity SHOULD be applied to existing DTLS </del>  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 Requests for permanent access. Because HTTP origins cannot be securely established against network <del> attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins.  Implementations MUST refuse all permissions grants for HTTP origins. </del>  In addition, they SHOULD support requests for access that promise that media from this grant will be sent to a single communicating <del> 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 </del>  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 <del> it is unlikely that browsers would have an X.509 certificate, but </del>  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 MUST NOT be shared even if the application is being shared.  If the screen is being shared, then that MUST be indicated. <del> Clients MAY permit the formation of data channels without any direct </del>  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 one's IP address, which leaks large amounts of location information. This has negative privacy consequences in some circumstances.  The API requirements in this section are intended to mitigate this issue. <del> Note that these requirements are NOT intended to protect the user's </del>  IP address from a malicious site.  In general, the site will learn at least a user's server reflexive address from any HTTP transaction. Rather, these requirements are intended to allow a site to cooperate Implementations MUST implement SRTP RFC3711.  Implementations MUST implement DTLS RFC6347 and DTLS-SRTP RFC5764 for SRTP keying. <del> Implementations MUST implement RFC8261. </del>  All media channels MUST be secured via SRTP and SRTCP.  Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,

Reviewer comments:
Changes based on .
NAME NAME NAME NAME PTAL Also, there were two I wasn'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? Don't unexpected things happen if the recipient doesn't do this? : "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." (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 doesn'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 Ben is right, the first sentence is unnecessary. attackers, implementations MUST refuse all requests for permission grants from HTTP origins.
NAME okay fixed these points. On to Ben K's.
I don't think this "SHOULD" -> "can" for identities is right. Actually, I think it needs to be a MUST.
This won't build, but it looks fine otherwise. Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example. I'm balloting "yes", but have a few minor comments and editorial comments: : (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?) (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.) (nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG. : (nit) - '... button next to Bob’s name which says "Call".': s/which/that "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." This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention. : "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? Don't unexpected things happen if the recipient doesn't do this? : "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." (nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong? (nit) - .E.g., "Call EMAIL"' : sentence fragment. (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert). (maybe nit) - "Clients MAY permit the formation of data channels without any direct user approval." Is the switch from talking about "the browser" to "Clients" intentional? : (nit) - "Note that these requirements are NOT intended..." "NOT" in all caps is likely to be confused with 2119/8174 language. : (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [RFC8261]." Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261? : (nit) - First paragraph: Can there be a citation for the W3C API spec? (My bad, the draft is correct. Comment removed.) §7.1.4, SDP example: (nit) §11: The first sentence is a fragment. (normative references) (nit) - There's a reference to RFC 5234, but it is not cited in the text. Is there a reason to reference 5246 rather than 8446, which obsoleted it? : seems like the jsep reference should be normative.

Revised text:
1.  <ins> 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. </ins> 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  <ins> like SIP or something like Extensible Messaging and Presence Protocol (XMPP) RFC6120. </ins> This system presents a number of new security challenges, which are analyzed in I-D.ietf-rtcweb-security.  This document describes 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  <ins> Bob's name that says "Call".  Alice clicks the button, which </ins> 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. When modifying a session, if the set of fingerprints is unchanged, then the sender MAY send the same 'identity' attribute.  In this  <ins> case, the established identity can be applied to existing DTLS </ins> 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 Requests for permanent access. Because HTTP origins cannot be securely established against network  <ins> attackers, implementations MUST refuse all permissions grants for HTTP origins. </ins> In addition, they SHOULD support requests for access that promise that media from this grant will be sent to a single communicating  <ins> 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 </ins> 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  <ins> it is unlikely that browsers would have X.509 certificates, but </ins> 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 MUST NOT be shared even if the application is being shared.  If the screen is being shared, then that MUST be indicated.  <ins> Browsers MAY permit the formation of data channels without any direct </ins> 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 one's IP address, which leaks large amounts of location information. This has negative privacy consequences in some circumstances.  The API requirements in this section are intended to mitigate this issue.  <ins> Note that these requirements are not intended to protect the user's </ins> IP address from a malicious site.  In general, the site will learn at least a user's server reflexive address from any HTTP transaction. Rather, these requirements are intended to allow a site to cooperate Implementations MUST implement SRTP RFC3711.  Implementations MUST implement DTLS RFC6347 and DTLS-SRTP RFC5764 for SRTP keying.  <ins> Implementations MUST implement SCTP over DTLS RFC8261. </ins> All media channels MUST be secured via SRTP and SRTCP.  Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,