All data channels MUST be secured via DTLS. All implementations MUST implement DTLS 1.0, with the cipher suite <del> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80.  Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_RSA_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.  [[OPEN ISSUE: Should we require ECDSA?  Waiting for WG Consensus.]] The API MUST provide a mechanism to indicate that a fresh DTLS key pair is to be generated for a specific call.  This is intended to allow for unlinkability.  Note that there are also settings where it is attractive to use the same keying material repeatedly, especially those with key continuity-based authentication.  Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin.  (This avoids creating a super-cookie.) </del>  When DTLS-SRTP is used, the API MUST NOT permit the JS to obtain the negotiated keying material.  This requirement preserves the

I also cleaned up the requirements that follow on from this. I think that those changes are editorial only.
Tickling this issue. Not clear to me if it is resolved or not. Current text (-12): All implementations MUST implement DTLS 1.0, with the cipher suite TLSECDHEECDSAWITHAES128CBCSHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTPAES128CMHMACSHA180 MUST be supported for SRTP. Implementations SHOULD implement DTLS 1.2 with the TLSECDHEECDSAWITHAES128GCM_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. (Original text of this comment turned out to be a misunderstanding. The draft linked as "editor's draft" from the project's master page is older than the published -12 version.)
I think that the actual editors draft is OK, ekr merged a while ago.

All data channels MUST be secured via DTLS. All implementations MUST implement DTLS 1.0, with the cipher suite  <ins> 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. The API MUST generate a new authentication key pair for every new call by default.  This is intended to allow for unlinkability. The API MUST provide a means to reuse a key pair for calls.  This can be used to enable key continuity-based authentication, and could be used to amortize key generation costs. Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin.  (This avoids creating a super-cookie.) </ins> When DTLS-SRTP is used, the API MUST NOT permit the JS to obtain the negotiated keying material.  This requirement preserves the


Because the consent issue is more difficult here, we require WebRTC implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness <del> mechanism specified in I-D.muthu-behave-consent-freshness.  If a keepalive fails and no new ICE channels can be established, then the session is terminated. </del>  5. Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile <del> the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </del>  5.4.

Addresses .
NAME CI fail
Yeah I can’t wait to diagnose what xml problem I introduced - sigh.
From Cullen's 20171106 review: The refs to draft-muthu-behave-consent-freshness should be to RFC7675
Addressed by .

Because the consent issue is more difficult here, we require WebRTC implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness  <ins> mechanism specified in RFC7675.  If a keepalive fails and no new ICE channels can be established, then the session is terminated. </ins> 5. Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile  <ins> the ICE timers to be used; see RFC7675. </ins> 5.4.


necessary in systems that are non-windows-based but that have good notifications support, such as phones.] <del> Browsers MUST not permit permanent screen or application sharing </del>  permissions to be installed as a response to a JS request for permissions.  Instead, they must require some other user action such as a permissions setting or an application install experience The browser MUST indicate any windows which are currently being shared in some unambiguous way.  Windows which are not visible <del> MUST not be shared even if the application is being shared.  If </del>  the screen is being shared, then that MUST be indicated. Clients MAY permit the formation of data channels without any direct

There were two instances of "MUST not" that need to be "MUST NOT"
Address I-D nits complaints.

necessary in systems that are non-windows-based but that have good notifications support, such as phones.]  <ins> Browsers MUST NOT permit permanent screen or application sharing </ins> permissions to be installed as a response to a JS request for permissions.  Instead, they must require some other user action such as a permissions setting or an application install experience The browser MUST indicate any windows which are currently being shared in some unambiguous way.  Windows which are not visible  <ins> MUST NOT be shared even if the application is being shared.  If </ins> the screen is being shared, then that MUST be indicated. Clients MAY permit the formation of data channels without any direct


The "security characteristics" MUST indicate the cryptographic <del> algorithms in use (For example: "AES-CBC" or "Null Cipher".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. </del>  The "security characteristics" MUST indicate whether PFS is provided.

Addressing .
From Cullen's 20171106 review: At the end of section 5.5, there is mention of a NULL cipher in an example. I don't think that is allowed and thought is not a problem the way it is mentioned here, perhaps it should be removed from the example.
NAME Version -06, exposed the NULL ciphers at the top level so are you suggested to just delete the part in the parenthetical or the rest of the sentence too: i.e.,: The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI.

The "security characteristics" MUST indicate the cryptographic  <ins> algorithms in use (For example: "AES-CBC".)  However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. </ins> The "security characteristics" MUST indicate whether PFS is provided.


channels.  This is performed via DTLS RFC6347 and DTLS-SRTP RFC5763 keying for SRTP RFC3711 for the media channel and SCTP over DTLS RFC8261 for data channels.  Specifically, Alice and Bob perform a <del> DTLS handshake on every channel which has been established by ICE. </del>  The total number of channels depends on the amount of muxing; in the most likely case we are using both RTP/RTCP mux and muxing multiple media streams on the same channel, in which case there is only one

RFC 5764 rather optimistically describes how the same DTLS handshake can be used to key SRTP for RTP and RTCP even if these are on different components (i.e., is not negotiated). This is not what anyone does. Mandate precisely one handshake per component.
FROM IETF100: Don't mux.
Given we don't allow rtcpmux in WEbRTC. This is sort of irrelevant and we can say it never happens just don't do it.
I actually thought this was pretty clear before, but I've added the term component to make it clear. I don't understand NAME comment. We absolutely allow rtcpmux in WebRTC, but it's still possible to not have it (browsers aren't forbidden to support it).

channels.  This is performed via DTLS RFC6347 and DTLS-SRTP RFC5763 keying for SRTP RFC3711 for the media channel and SCTP over DTLS RFC8261 for data channels.  Specifically, Alice and Bob perform a  <ins> DTLS handshake on every component which has been established by ICE. </ins> The total number of channels depends on the amount of muxing; in the most likely case we are using both RTP/RTCP mux and muxing multiple media streams on the same channel, in which case there is only one


Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by the browser, so nothing stops a Web attacker from creating their own <del> IFRAME, loading the IdP proxy HTML/JS, and requesting a signature. In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. Note that although this origin check is enforced on the RP side and not at the IdP, it is absolutely imperative that it be done.  The mechanisms in this document rely on the browser enforcing access restrictions on the DTLS keys and assertion requests which do not come with the right origin may be from content JS rather than from browsers, and therefore those access restrictions cannot be assumed. </del>  Note that this check only asserts that the browser (or some other entity with access to the user's authentication data) attests to the request and hence to the fingerprint.  It does not demonstrate that <del> the browser has access to the associated private key.  However, attaching one's identity to a key that the user does not control does not appear to provide substantial leverage to an attacker, so a proof of possession is omitted for simplicity. </del>  6.4.2.

…
That's an artifact of an older design.
NAME PTAL
Note that "ensure that it is running in the IdP's origin" is a non-trivial thing. But I guess we can rely on stackoverflow for that ultimately :)

Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by the browser, so nothing stops a Web attacker from creating their own  <ins> IFRAME, loading the IdP proxy HTML/JS, and requesting a signature over his own keys rather than those generated in the browser. However, that proxy would be in the attacker's origin, not the IdP's origin.  Only the browser itself can instantiate a context that (a) is in the IdP's origin and (b) exposes the correct API surface. Thus, the IdP proxy on the sender's side MUST ensure that it is running in the IdP's origin prior to issuing assertions. </ins> Note that this check only asserts that the browser (or some other entity with access to the user's authentication data) attests to the request and hence to the fingerprint.  It does not demonstrate that  <ins> the browser has access to the associated private key, and therefore an attacker can attach their own identity to another party's keying material, thus making a call which comes from Alice appear to come from the attacker.  See I-D.ietf-mmusic-sdp-uks for defenses against this form of attack. </ins> 6.4.2.


hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values: <del> The IdP's domain name </del>  The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to The scheme, "https:".  An IdP MUST be loaded using RFC2818. <del> The authority, which is the IdP domain name.  The authority MAY contain a non-default port number.  Any port number is removed </del>  when determining if an asserted identity matches the name of the <del> IdP.  The authority MUST NOT include a userinfo sub-component. </del>  The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol.  Note that the separator characters '/'

This references RFC 3986 authority instead of providing a definition for IdP domain. This change means that userinfo sub-components are permitted, as are non-default ports, but also states that both are removed before matching against the certificate.

hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values:  <ins> The RFC3986 at which the IdP's service is hosted.  Note that this may include a non-default port or a userinfo component, but neither will be available in a certificate verifying the site. </ins> The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to The scheme, "https:".  An IdP MUST be loaded using RFC2818.  <ins> The RFC3986.  As noted above, the authority MAY contain a non- default port number or userinfo sub-component.  Both are removed </ins> when determining if an asserted identity matches the name of the  <ins> IdP. </ins> The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol.  Note that the separator characters '/'


dictionary with one or two further values that identify the IdP, as described in sec.idp-uri.  5.6.5. In order to ensure that the IdP is under control of the domain owner

From URL repos it seems the conclusion is that how identity is handled carried in the SDP, and how identity in the SDP is parsed, and how multiple identity attributes (if we are to support that) should be describe in draft-ietf-rtcweb-security-arch [5]. draft-ietf-rtcweb-security-arch, but only for a single identity attribute, and parsing is not described, so it needs to be updated. repo [6] for draft-ietf-rtcweb-security-arch seems to be low (indicating the action happens elsewhere). [2] URL [3] URL [4] URL [5] URL [6] URL
FROM IETF100: EKR just needs to write some crap. Should only have one, semantics are undefined with more than 1, implementations need only process one.
1) only put 1 in 2) semantics undefined if more than one 3) implementations only need to process one
NAME PTAL Hi, after some discussing in in W3C webrtc-pc [1] and JSEP [2][3][4] github repos it seems the conclusion is that how identity is handled carried in the SDP, and how identity in the SDP is parsed, and how multiple identity attributes (if we are to support that) should be describe in draft-ietf-rtcweb-security-arch [5]. Identity in the SDP is currently described in draft-ietf-rtcweb-security-arch, but only for a single identity attribute, and parsing is not described, so it needs to be updated. I decided to send this to the list as the activity level at the github repo [6] for draft-ietf-rtcweb-security-arch seems to be low (indicating the action happens elsewhere). Stefan [1] URL [2] URL [3] URL [4] URL [5] URL [6] URL

dictionary with one or two further values that identify the IdP, as described in sec.idp-uri. <ins> The semantics of multiple identity attributes are undefined. Implementations SHOULD only include a single identity attribute in an offer and relying parties MAY elect to ignore all but the first identity attribute. </ins> 5.6.5. In order to ensure that the IdP is under control of the domain owner


5.6.4. An identity assertion binds the user's identity (as asserted by the <del> IdP) to the SDP offer/exchange transaction and specifically to the media.  In order to achieve this, the PeerConnection must provide the DTLS-SRTP fingerprint to be bound to the identity.  This is provided as a JavaScript object (also known as a dictionary or hash) with a single "fingerprint" key, as shown below: </del>  The "fingerprint" value is an array of objects.  Each object in the array contains "algorithm" and "digest" values, which correspond 5.6.4.1. Once an IdP has generated an assertion, it is attached to the SDP <del> message.  This is done by adding a new identity attribute to the SDP. The sole contents of this value are a RFC4648 identity assertion. For example: </del>  The identity attribute attests to all "a=fingerprint" attributes in the session description.  It is therefore a session-level attribute.

Just some tweaks to consistently use offer/answer exchange and to explain that the offer/answer includes the caller's/callee's assertion, respectively.

5.6.4. An identity assertion binds the user's identity (as asserted by the  <ins> IdP) to the SDP offer/answer exchange and specifically to the media. In order to achieve this, the PeerConnection must provide the DTLS- SRTP fingerprint to be bound to the identity.  This is provided as a JavaScript object (also known as a dictionary or hash) with a single "fingerprint" key, as shown below: </ins> The "fingerprint" value is an array of objects.  Each object in the array contains "algorithm" and "digest" values, which correspond 5.6.4.1. Once an IdP has generated an assertion, it is attached to the SDP  <ins> offer/answer message.  This is done by adding a new identity attribute to the SDP.  The sole contents of this value are a RFC4648 identity assertion.  For example: </ins> The identity attribute attests to all "a=fingerprint" attributes in the session description.  It is therefore a session-level attribute.


location controlled by the attacker.  Implementations MUST either choose to terminate the call or display a warning at that point.  5.2. Implementations MUST obtain explicit user consent prior to providing

This is an (lame) attempt to I'm, not sure the text is in the right place even. NAME NAME NAME NAME PTAL As far as I know this is the last technical security issue.
As described in the (mailing list discussion)[URL] As the RTCCertificates are allowed to be stored or transferred across domains via postMessage it could allow a potential attacker to reuse a past identity assertion when it is no longer valid. A possible solution would to generate an unique dtls external session Id per peerconnection as described in URL and provide that information to the generate and validate assertion js methods.
I think where this conversation ended up, based on Harald's email: URL Means that the security arch draft needs to say that the security architecture depends on the keying material not being available to move between origins, but that we understand and assume that the identity token can be passed to anyone that the page cares to. And, Martin also added this PR to the WebRTC spec: Also URL To make sure we're all on the same page: The identity token is a JSON blob - ie a string. There's absolutely no way to prevent the page from passing it to anyone it wants to pass it to - and there shouldn't be. In contrast, the RTCCertificate is an object with an interface that has a specific guarantee: "No mechanism is provided for applications to access the [[KeyingMaterial]] internal slot." and therefore this further statement can be made to implementors: "In implementations where an RTCCertificate might not directly hold private keying material (it might be stored in a secure module), a reference to the private key can be held in the [[KeyingMaterial]] internal slot, allowing the private key to be stored and used." I think it doesn't make sense to move such an object between origins. We might want to state that explictly. (But that's a W3C issue, so ought to be addressed to a different list.)

location controlled by the attacker.  Implementations MUST either choose to terminate the call or display a warning at that point. <ins> Also note that the security architecture depends on the keying material not being available to move between origins.  But, it is assumed that the identity assertion can be passed to anyone that the page cares to. </ins> 5.2. Implementations MUST obtain explicit user consent prior to providing


dictionary with one or two further values that identify the IdP, as described in sec.idp-uri.  The semantics of multiple identity attributes are undefined. Implementations SHOULD only include a single identity attribute in an offer and relying parties MAY elect to ignore all but the first

This currently uses the fingerprint, but that's just this version.
I am ok with this scope, and to allow other means to be defined in future. However, as the whole document is based on the usage of fingerprints for assertion, I think this scope should be defined in the beginning of the document, e.g., in a separate "Scope" section and/or in the Introduction. Related to that, the document references the W3C API between the user and the IdP. It would be good to say that other APIs can also be used, but is outside the scope of this document.

dictionary with one or two further values that identify the IdP, as described in sec.idp-uri. <ins> An identity assertion as defined in this document relies on the value of "a=fingerprint" attributes, but this does not preclude the definition of alternative means of binding an assertion to the identity of a peer. </ins> The semantics of multiple identity attributes are undefined. Implementations SHOULD only include a single identity attribute in an offer and relying parties MAY elect to ignore all but the first


When an offerer sends an offer, in order to provide its identity assertion to the peer, it includes an 'identity' attribute in the offer.  In addition, the offerer includes one or more SDP <del> 'fingerprint' attributes.  The set of fingerprints MUST be the same as the set to which the identity assertion is bound. </del>  5.1.2. 5.1.5. <del> When an endpoint has provided its identity assertion in a previous successful offer/answer exchange, and when the endpoint later in the session sends an offer or answer, the endpoint can either keep the identity assertion value unchanged, modify the value, or revoke the identity assertion.  This section describes the procedures for doing so. </del>  <del> If the endpoint wants to maintain the previously provided identity assertion, it MUST include an 'identity' attribute with the previously provided attribute value in the offer or answer. If the endpoint wants to modify its identity assertion within the session, it MUST include an 'identity' attribute value with the new identity assertion in the offer or answer. If the endpoint maintains or modifies its identity assertion within the session, it includes one or more SDP 'fingerprint' attributes. The set of fingerprints MUST be the same as the set to which the identity assertion is bound. If the endpoint wants to revoke its identity assertion from the session, it MUST NOT include an 'identity' attribute in the offer or answer. Specific usages might restrict the modification and/or revoking of the identity assertion within a session.  Endpoints can add, modify, or remove 'fingerprint' attributes when modifying a session.  If a modified session retains the 'identity' attribute, there MUST be at least one 'fingerprint' attribute included. </del>  6. 11.1.  Update discussion of IdP security model Replace "domain name" with RFC 3986 Authority Require support for ECDSA, PFS, and AEAD <del> 11.2. </del>  Update cipher suite profiles. Rework IdP interaction based on implementation experience in Firefox. <del> 11.3. </del>  Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the IETF WG Assorted editorial work. <del> 11.4. </del>  The following changes have been made since the -05 draft. Editorial cleanup. <del> 11.5. </del>  Version -04 was a version control mistake.  Please ignore. Editorial cleanup. <del> 11.6. </del> 11.7.  The following changes have been made since the -02 draft. Forbid persistent HTTP permissions.

NAME I looked at the deletion issue and I don't think it's worth leaving it in as an exception, because you'd have to DTLS re-handshake anyway.

When an offerer sends an offer, in order to provide its identity assertion to the peer, it includes an 'identity' attribute in the offer.  In addition, the offerer includes one or more SDP  <ins> 'fingerprint' attributes.  The 'identity' attribute MUST be bound to all the 'fingerprint' attributes in the session description. </ins> 5.1.2. 5.1.5.  <ins> 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. </ins>  <ins> If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in fingerprints also causes a new DTLS connection to be established, the receiver MUST discard all previously established identities. </ins> 6. 11.1. <ins> Rewrite the Identity section in more conventional offer/answer format. Clarify rules on changing identities. 11.2. </ins> Update discussion of IdP security model Replace "domain name" with RFC 3986 Authority Require support for ECDSA, PFS, and AEAD  <ins> 11.3. </ins> Update cipher suite profiles. Rework IdP interaction based on implementation experience in Firefox.  <ins> 11.4. </ins> Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the IETF WG Assorted editorial work.  <ins> 11.5. </ins> The following changes have been made since the -05 draft. Editorial cleanup.  <ins> 11.6. </ins> Version -04 was a version control mistake.  Please ignore. Editorial cleanup.  11.7. <ins> 11.8. </ins> The following changes have been made since the -02 draft. Forbid persistent HTTP permissions.


local policy is configured to trust this IdP domain for the domain portion of the identity string. <del> Sites that have identities that do not fit into the RFC822 style (for instance, identifiers that are simple numeric values, or values that contain '@' characters) SHOULD convert them to this form by escaping illegal characters and appending their IdP domain (e.g., user%40133@identity.example.com), thus ensuring that they are authoritative for the identity. </del>  9.

NAME I think this one is good to merge.
Raised by Jim Spring at the interim
I think this is now closed by MT's revision with LOGINNEEDED.
Closing. Jim, please re-open if you believe it is not.
LGTM

local policy is configured to trust this IdP domain for the domain portion of the identity string.  <ins> Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in Section 2.1 of RFC3986.  Characters other than "@" and "%" MUST NOT be percent-encoded.  For example, with a user of "user@133" and a domain of "identity.example.com", the resulting string will be encoded as "user%40133@identity.example.com". Implementations are cautioned to take care when displaying user identities containing escaped "@" characters.  If such characters are unescaped prior to display, implementations MUST distinguish between the domain of the IdP proxy and any domain that might be implied by the portion of the <user> portion that appears after the escaped "@" sign. </ins> 9.


Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered.  The API MUST generate a new authentication key pair for every new call by default.  This is intended to allow for unlinkability.

Address . Wasn't sure if we should reject the connection. NAME PTAL
This was entirely motivated by ekr's issue. Just trying to move this one along.
We should prohibit false start.
Why? (Sean in the PT said "because of ekr's issue", but I can't see what the issue is here)
Because the DTLS-SRTP cipher negotiation is not protected until the Finished.
That is covered by the false start RFC adequately in my view.
Which section do you believe covers it?
Well, I guess that URL covers cipher negotiation, but I would concede that it's probably more mechanical and less about the underlying principles.
Yes, and so consider the case where you are negotiating both double and regular SRTP....
Ugh. You have convinced me :) Prohibit it. And we should maybe say why.
I tend to agree that we should include a reason in .
Why make this prohibition? The description in RFC 7918 covers most of the reasons you might choose not to false start, is there anything in that set that motivates this? I mean, clients doing false start only do so if they aren't concerned about the implications of downgrade for the parameters that are (apparently) negotiated.

Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. <ins> Endpoints MUST NOT implement TLS False Start RFC7918. </ins> The API MUST generate a new authentication key pair for every new call by default.  This is intended to allow for unlinkability.


attribute of the SDP RFC8122. This object is encoded in a RFC8259 string for passing to the IdP.  This structure does not need to be interpreted by the IdP or the IdP proxy.  It is consumed solely by the RP's browser.  The IdP merely 7.4.1. <del> Once an IdP has generated an assertion, it is attached to the SDP offer/answer message.  This is done by adding a new 'identity' attribute to the SDP.  The sole contents of this value are a RFC4648 identity assertion.  For example: </del>  The 'identity' attribute attests to all "fingerprint" attributes in the session description.  It is therefore a session-level attribute. Unlike the AP, the RP need not have any particular relationship with the IdP.  Rather, it needs to be able to process whatever assertion <del> is provided by the AP.  As the assertion contains the IdP's identity, the URI can be constructed directly from the assertion, and thus the RP can directly verify the technical validity of the assertion with no user interaction.  Authoritative assertions need only be verifiable.  Third-party assertions also MUST be verified against local policy, as described in sec.id-format. </del>  7.6.

The description of how an assertion is constructed seemed to imply that the object with the fingerprints was what went in a=identity. You had to read much further down to learn that this wasn't right and that it was really the assertion. This just moves some of the critical text up, duplicating it really, so that this confusion is less likely.

attribute of the SDP RFC8122. This object is encoded in a RFC8259 string for passing to the IdP. <ins> The identity assertion returned by the IdP, which is encoded in the "identity" attribute, is a JSON object that is encoded as described in sec.carry-assertion. </ins> This structure does not need to be interpreted by the IdP or the IdP proxy.  It is consumed solely by the RP's browser.  The IdP merely 7.4.1.  <ins> Once an IdP has generated an assertion (see sec.request-assert), it is attached to the SDP offer/answer message.  This is done by adding a new 'identity' attribute to the SDP.  The sole contents of this value is the identity assertion.  The identity assertion produced by the IdP is encoded into a UTF-8 JSON text, then RFC4648 to produce this string.  For example: </ins> The 'identity' attribute attests to all "fingerprint" attributes in the session description.  It is therefore a session-level attribute. Unlike the AP, the RP need not have any particular relationship with the IdP.  Rather, it needs to be able to process whatever assertion  <ins> is provided by the AP.  As the assertion contains the IdP's identity in the "idp" field of the JSON-encoded object (see sec.request- assert), the URI can be constructed directly from the assertion, and thus the RP can directly verify the technical validity of the assertion with no user interaction.  Authoritative assertions need only be verifiable.  Third-party assertions also MUST be verified against local policy, as described in sec.id-format. </ins> 7.6.


Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed.  While the details vary, what these technologies share is that they have a Web-based (i.e., <del> HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could use the example.org identity provider to prove to others that I was </del>  alice@example.org.  The development of these technologies allows us <del> to separate calling from identity provision: I could call you on </del>  Poker Galaxy but identify myself as alice@example.org. Whatever the underlying technology, the general principle is that the service can strip off any such identity assertions, though it cannot forge new ones.  Note that all of the third-party security mechanisms available (whether X.509 certificates or a third-party IdP) rely on <del> the security of the third party--this is of course also true of your connection to the Web site itself.  Users who wish to assure </del>  themselves of security against a malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band.

In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." EMAIL is used there so the pronouns are mixed. Same comment for 9.1 -- I would suggest replacing "your" with "the user's."

Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed.  While the details vary, what these technologies share is that they have a Web-based (i.e.,  <ins> HTTP/HTTPS) identity provider which attests to Alice's identity.  For instance, if Alice has an account at example.org, Alice could use the example.org identity provider to prove to others that Alice is </ins> alice@example.org.  The development of these technologies allows us  <ins> to separate calling from identity provision: Alice could call you on </ins> Poker Galaxy but identify myself as alice@example.org. Whatever the underlying technology, the general principle is that the service can strip off any such identity assertions, though it cannot forge new ones.  Note that all of the third-party security mechanisms available (whether X.509 certificates or a third-party IdP) rely on  <ins> the security of the third party--this is of course also true of the user's connection to the Web site itself.  Users who wish to assure </ins> themselves of security against a malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band.


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,

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.

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,


hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values: <del> The RFC3986 at which the IdP's service is hosted.  Note that this may include a non-default port or a userinfo component, but neither will be available in a certificate verifying the site. </del>  The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to

Need to address Ben's points.
Working group consensus to remove non-default port capability from the specification. In line with RFC 5785bis's guidance in Section 3. Thanks for addressing my Discuss points! I'll leave the original Comment section below, as I note that at least one issue remains (I spot-checked the SDP Offer/Answer reference, that still points to RFC 6454, which is "the Web Origin Concept".  I didn't make any attempt to trim points that did get addressed. (My comment about TCB and the other browser from the companion document is probably relevant here, too.) This is the optimistic "best security" case, and we already say we're talking to the signaling server over HTTPS, so it should be safe to just say "over TLS" and drop the "preferably".  (Also, s/5246/8446.) I think I'm confused.  We're displaying trusted browser chrome based on an assertion from some IdP that we have no relationship with and no reason to trust? nit: that's not really more specific.  Maybe "Once the requisite ICE checks have completed"? I see that the 4566 <base64> includes the pad characters, though sometimes we will mention explicitly whether they are or are not included. leading whitespace, too, right? 6454 is "the Web Origin Concept"; presumably this is supposed to be 4566 (or 3264?). I feel like we need some text here about the (non?)trustworthiness of the IdP. I'm a bit confused at what's going on here.  Is "MAY send the same" supposed to prevent changing it?  If I don't send it, does that identity continue to apply to the existing DTLS connections but not any new ones generated by the session modification?  Am I allowed to send a different one? nit: is this "each media section"/"every media section" redundant? There may be some (weak) privacy considerations if this is literally anyone, since it would allow some observers (with weird abilities/restrictions) to associate "real" identities with keys in a way that they couldn't otherwise do. Just to check: this last sentence applies for one-time requets, too? Does this need to be an exhaustive list or can we leave it open-ended? Also, it may be appropriate to mention some concept of "IdP trusted to authenticate the stated identity". Do we need to say anything about that state transition being visible to the peer, here? nit: s/windows/window/? Is there anything to say about why clients might not opt to do so (and what such approval might look like)? (My comments about "verified user" including the IdP in some way will apply here as well.) Is the "the current WG consensus" language going to age well? Is there a WIP draft for this separate document? nit: maybe make it more clear that this only applies for incoming calls? It's not clear to me that the "that is" reflects a strict equivalence; would "in particular" be more appropriate? (Also, "cipher suite" is a DTLS term, but do we want to disambiguate explicitly?) [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note] "MUST NOT implement" isn't really something that 2119 language can enforce; "MUST NOT use" is the best we can get. (7918 doesn't claim to be applicable to DTLS anyway) nit: might be appropriate to note why we care about a super-cookie (and what it is) I'm not sure I see anywhere that we allow the usage of null ciphers. I agree with Alissa that the first person is not needed here. This probably needs some qualifier, given recent developments with CAA and similar mechanisms. The RP still needs to establish somehow that the IdP in use is in fact an authoritative IdP, though! A reference to that W3C API spec might be handy. nit: the grammar is a bit weird here, as the "information from the signaling message" isn't really a part of this work, but rather the specification for what information that is. The indentation of the line with "}, {" is a bit confusing. I'm a little confused what this "encoded in a JSON string" is supposed to mean. The IdP probably wants to know enough about its structure to not turn into a signing oracle for other protocols, though. (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention that.) It's a little surprising to see sha-1 fingerprint in use (since "examples are recommendations"), though I didn't find anything that would actually formally deprecate such usage yet. leading whitespace, too, right? (Still need to say how it's know than authoritative assertions are in fact authoritative for what they claim.) (IdP still doesn't want to become a signing oracle.) nit: it's unclear that "serialized into JSON" adds any value, since the thing is defined to be a JSON object. I think that the framing of HTTP Basic (7617) here is not great. RFC 7235 might be a better link for HTTP Authentication in general, and of course there are mechanisms that don't include sending the password in plaintext, like SCRAM (RFC7804). IMPORTANT: Do we need a freshness property for the assertion?  Some of these schemes do not provide freshness. (Doesn't the W3C API spec need to say how the response is formatted?  Is the JSON formatting actually "illustrative" then, or is this just an example output?) Reading closely, I think this is supposed to be "unless either", but it's easy to assume it should be read as "unless both", so I think clarification is in order. We just said in the first paragraph that "user" has "any character except '@'", so this is a bit redundant. I suppose an "untrustworthy" IdP is basically a malicious one, though there are perhaps some subtleties that could be distinguished here. I don't think I fully understand the scenario described in this last sentence.  Is "compute digital signatures" supposed to be with some specific secret key, and/or is "a browser's generated key" one that is covered under the fingerprint in the IdP assertion? nit: "linkable information that would allow them to correlate the browser across multiple calls". I think I'm missing a step here.  How is the attacker using the data channel directly when the point is to get the multiple browsers to send the data on the data channel? nit: "must be used to suppress the misbehaving flow", I think. I don't see an "origin" field in the signature request; is this supposed to be the "domain"? nit: it might be friendlier to the reader to prefix this with "When popup blocking is in use, ". It's perhaps debatable that JSEP is only an informative reference.

hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values:  <ins> The RFC3986 at which the IdP's service is hosted. </ins> The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to


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 <del> media section. </del>  If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in

What happens if fingerprints don't change but identity does, and there's no new connection, (e.g., a codec change). This text needs to say you propagate that identity to the existing connections.
The webrtc text forbids changing of identity. You might want to note that, even if this new language is correct in a more general sense.

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  <ins> media section.  If a new identity attribute is received, then the receiver MUST apply that identity to all existing connections. </ins> If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in


fig.assert-ex shows an example assertion formatted as JSON.  In this case, the message has presumably been digitally signed/MACed in some way that the IdP can later verify it, but this is an implementation <del> detail and out of scope of this document.  Line breaks are inserted solely for readability. </del>  For use in signaling, the assertion is serialized into JSON, RFC4648, <del> and used as the value of the "identity" attribute. </del>  7.7.

The key point is that this is a self-consumed token, so you need to separate it from other self-consumed tokens with different semantics or externally consumed tokens, either by format or by using a separate ke. Ben suggests making this point in 7.4.

fig.assert-ex shows an example assertion formatted as JSON.  In this case, the message has presumably been digitally signed/MACed in some way that the IdP can later verify it, but this is an implementation  <ins> detail and out of scope of this document. </ins> For use in signaling, the assertion is serialized into JSON, RFC4648,  <ins> and used as the value of the "identity" attribute.  IdPs SHOULD ensure that any assertions they generate cannot be interpreted in a different context.  E.g., they should use a distinct format or have separate cryptographic keys for assertion generation and other purposes.  Line breaks are inserted solely for readability. </ins> 7.7.


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 <del> specific knowledge of the IdP) to verify the assertion.  This allows the browser to display a trusted element in the browser chrome </del>  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 When an endpoint receives an offer or answer that contains an 'identity' attribute, the answerer can use the the attribute <del> information to contact the IdP, and verify the identity of the peer. If the identity verification fails, the answerer MUST discard the offer or answer as malformed. </del>  5.1.4.

We'll leave this for later.
What's generic is the protocol, but if you have a third party IdP, trust has to be configured. Say that and point to 7.1
See also 5.1.3. Forward reference to 7.1

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  <ins> specific knowledge of the IdP) to verify the assertion.  It is also possible to have IdPs with which the browser has a specific trustrelationship, as described in sec.trust-relationships.  This allows the browser to display a trusted element in the browser chrome </ins> 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 When an endpoint receives an offer or answer that contains an 'identity' attribute, the answerer can use the the attribute  <ins> information to contact the IdP and verify the identity of the peer. If the identity requires a third-party IdP as described in sec.trust- relationships then that IdP will need to have been specifically configured.  If the identity verification fails, the answerer MUST discard the offer or answer as malformed. </ins> 5.1.4.


The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC" I-D.ietf-rtcweb- <del> overview.  The major use cases for WebTC technology are real-time </del>  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 while scripts are allowed to make HTTP requests via the XMLHttpRequest() API those requests are not allowed to be made to any server, but rather solely to the same ORIGIN from whence the script <del> came xref target="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). </del>  More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes.  While there are techniques to allow them cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address.  Implementations <del> wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. </del>  4.3.

As discussed, a couple of minor typos and corrections.
The travis failures here aren't Michael's fault.
I've looked up the missing reference dates and added them. Travis seems happier.

The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC" I-D.ietf-rtcweb-  <ins> overview.  The major use cases for WebRTC technology are real-time </ins> 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 while scripts are allowed to make HTTP requests via the XMLHttpRequest() API those requests are not allowed to be made to any server, but rather solely to the same ORIGIN from whence the script  <ins> 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). </ins> More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes.  While there are techniques to allow them cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address.  Implementations  <ins> may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. </ins> 4.3.


risk is created by allowing calls at all from a page fetched over HTTP. <del> 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. </del>  4.2.

This seems like it should fix things
It's been there since the beginning, but the point is that people often think that if the page itself doesn't have malicious content then it's fine, but that's not true. Anyway, I'm comfortable with that piece unless someone objects to the content.
In Adam's AD review: I can't parse this sentence. Consider reworking. 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].
NAME do you have a proposal here?
NAME how about the following knowing that you're trying to bridge the previous that talks about HTTP origins: It is also dangerous to allow WebRTC functionality from HTTPS [RFC2818] origins that embed mixed content because if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site that JavaScript is executed in the security context of the page [finer-grained]. Note this would replace the 1st two sentences in the last para of §4.1.4 copied here for convenience: 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.
Has this been overtaken by events? I mean, while it might have been the case that some browsers permitted the use of active mixed content when this was originally written, I don't believe that any currently do. Could the text be removed?
I guess it could, but this is the section on "Security Properties of the Calling Page" so maybe for posterity we make this tweak, but also add to the end of the paragraph: Note: the issue of active mixed content was an issue, but is now implemented by browsers. And, (not having read the link entirely) we also informatively point to this W3C draft?

risk is created by allowing calls at all from a page fetched over HTTP.  <ins> Even if calls are only possible from HTTPS [RFC2818] sites, if those sites include active content (e.g., JavaScript) from an untrusted site, that JavaScript is executed in the security context of the page finer-grained.  This could lead to compromise of a call even if the parent page is safe.  Note: this issue is not restricted to PAGES which contain untrusted content.  If a page from a given origin ever loads JavaScript from an attacker, then it is possible for that attacker to infect the browser's notion of that origin semi- permanently. </ins> 4.2.


The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com <del> The attacker forges the response apparently http://calling- </del>  service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure. user is behind a VPN that masks their IP address.  Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented <del> systems such as Tor. </del>  4.3. with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a <del> source of call linkage I-D.ietf-rtcweb-ip-handling </del>  4.4.2. and WebRTC is no exception.  Specifically, sites can use the presence or absence of specific devices as a browser fingerprint.  In general, the API needs to be balanced between functionality and the <del> incremental fingerprint risk.  See Fingerprinting </del>  5.

Addressing Alissa's comments. I also added to periods that I noticed were missing.
NAME NAME PTAL
Scratch that, I'm reading backwards. The references are fine.

The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com  <ins> The attacker forges the response apparently from http://calling- </ins> service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure. user is behind a VPN that masks their IP address.  Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented  <ins> systems such as Tor.  See I-D.ietf-rtcweb-ip-handling for additional information. </ins> 4.3. with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a  <ins> source of call linkage I-D.ietf-rtcweb-ip-handling. </ins> 4.4.2. and WebRTC is no exception.  Specifically, sites can use the presence or absence of specific devices as a browser fingerprint.  In general, the API needs to be balanced between functionality and the  <ins> incremental fingerprint risk.  See Fingerprinting. </ins> 5.


into the cryptographic authentication procedures detailed in the previous sections.  4.3.3. One class of attack that we do not generally try to prevent is

Ben cleared his discuss after Adam's response, but we still need to include text to address the . I'd like to have a brief discussion about a few points, though it's not clear that any change to the document will be required (details in the COMMENT section for all of these): Mutually-verifiable "secure mode" seems to require that the peer's browser be included in the TCB, which is a bit hard to swallow.  Are we comfortable wrapping that in alongside "we trust the peer to not be malicious"? It's not clear how much benefit we can get from *optional* third-party identity providers; won't the calling service have the ability to silently downgrade to their non-usage even if both calling peers support it? I mostly only have editorial comments, though there are a few that are more content-ful. The user can observe the javascript running the browser, though maybe this distinction is not necessary here. I note that the author of this document is listed as a coauthor on huang-w2sp; does the self-cite really add much authority to the summary of the guarantee? The use of ALL-CAPS to call out new terms feels a bit dated. nit: I know this is a web-centric document, but the privileging of https as the only "secure" traffic reads a bit oddly to me; something like "note that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker."  (A thought experiment might be to consider whether wss://traffic counts as "HTTPS traffic".) It might be appropriate to provide some example references in place of "extensive research". nit: the wording here is a bit odd, since in case (1) you're verifying you're talking to A, but you still control where the media goes (in terms of A or not-A; A can of course then forward on the media further). nit: "local" is perhaps overly restricting, depending on interpretation Maybe note that the "result" of the cross-site requests that is leaked is in the form of pixels and not structured data, but that does not change the information content. nit: I'm confused by "another" here. This seems to be relying on the reader to have some background knowledge and make some leaps of reasoning that may not be reasonable to expect. This is especially challenging because if the site (and/or its javascript) is in the path for binding a cryptographic identity to a real-world identity, then a malicious site can still get whatever keys it wants authorized. seem to be missing a word or two here. nit: "If any page" is more emphatic, I think. Do we want any discussion of the risks when metered bandwidth (pay per byte) is in use? There's probably some room to tighten up the verbiage here; e.g., "the site initiating ICE" is referring to a website that is using a browser API to request ICE against some remote peer (right?).  And "ICE keepalives are indications" is using Indication as the technical term for a message that doesn't get an ACK response, not in its common English usage. A one- or two-sentence summary of the impact of misinterpretation attacks is probably in order, instead of making us follow the reference (which isn't a section reference). nit: "employed" to obfuscate what, exactly? nit: "incorporated" into what? I think I'm a little confused about which legacy actors we're talking about.  Are we still considering the broader situation a webserver-mediated interaction between two browsers or brower-adjacent applications?  (E.g., a WebRTC client calling some other sort of video chat system?) nit: "threat is" Is "answered" supposed to be some interaction with the controlling site? Some rewording for clarity is probably in order; "ordinary operation" is of a website without WebRTC; "sites can cause the browser to provide IP addresses" is when the site uses the browser API to request ICE initiation; etc. [Obligatory note about "Forward Secrecy" vs. "Perfect Forward Secrecy"] To be clear, the authentication that the calling service provides is a binding between identity and the public keys that are input to the key exchange mechanism? nit: "browser to use trusted UI" It's not clear that third-party identity providers actually provide downgrade-resistance -- can't the site mediating the calls just decline to acknowledge that a third-party identity is/was available for the peer? This seems to require extending the TCB from just the local browser to the remote browser as well, which is ... a stretch. (Also, do we really need the first person?) The coordinates for [OpenID] don't seem quite right.

into the cryptographic authentication procedures detailed in the previous sections. <ins> It should be noted that the use of this secure media mode is left to the discretion of the site.  When such a mode is engaged, the browser will need to provide indicia to the user that the associated media has been authenticated as coming from the identified user.  This allows WebRTC services that wish to claim end-to-end security to do so in a way that can be easily verified by the user.  This model requires that the remote party's browser be included in the TCB, as described in sec.web-security. </ins> 4.3.3. One class of attack that we do not generally try to prevent is


this section provides more background on the existing Web security model. <del> In this model, then, the browser acts as a TRUSTED COMPUTING BASE </del>  (TCB) both from the user's perspective and to some extent from the server's.  While HTML and JavaScript (JS) provided by the server can cause the browser to execute a variety of actions, those scripts operate in a sandbox that isolates them both from the user's computer and from each other, as detailed below. <del> Conventionally, we refer to either WEB ATTACKERS, who are able to </del>  induce you to visit their sites but do not control the network, and <del> NETWORK ATTACKERS, who are able to control your network.  Network </del>  attackers correspond to the RFC3552 "Internet Threat Model".  Note <del> that for non-HTTPS traffic, a network attacker is also a Web attacker, since it can inject traffic as if it were any non-HTTPS Web site.  Thus, when analyzing HTTP connections, we must assume that traffic is going to the attacker. </del>  3.1. user must explicitly select the file and consent to its upload. [Note: in many cases browsers are explicitly designed to avoid dialogs with the semantics of "click here to bypass security checks", <del> as extensive research shows that users are prone to consent under such circumstances.] </del>  Similarly, while Flash programs (SWFs) SWF can access the camera and microphone, they explicitly require that the user consent to that Moreover, the identity of the party the browser is connecting to is all that the browser can meaningfully enforce; if you are calling A, A can simply forward the media to C.  Similarly, if you authorize A <del> to place a call to B, A can call C instead.  In either case, all the </del>  browser is able to do is verify and check authorization for whoever is controlling where the media goes.  The target of the media can of course advertise a security/privacy policy, but this is not something 4.1.3. <del> Now that we have seen another use case, we can start to reason about the security requirements. </del>  As discussed in sec.same-origin, the basic unit of Web sandboxing is the origin, and so it is natural to scope consent to origin. The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com <del> The attacker forges the response apparently from http://calling- </del>  service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure. site, that JavaScript is executed in the security context of the page finer-grained.  This could lead to compromise of a call even if the parent page is safe.  Note: this issue is not restricted to PAGES <del> which contain untrusted content.  If a page from a given origin ever loads JavaScript from an attacker, then it is possible for that </del>  attacker to infect the browser's notion of that origin semi- permanently. 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 <del> indicates is unlikely), this would require (a) the browser has </del>  trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. cannot interfere.  In order to facilitate that, it will be necessary to provide features whereby the site can verifiably give up access to the media streams.  This verification must be possible both from the <del> local side and the remote side.  I.e., I must be able to verify that the person I am calling has engaged a secure media mode (see </del>  sec.malicious).  In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the

(or attempts to at least).
NAME ready to merge
Need to work through Ben's . I'd like to have a brief discussion about a few points, though it's not clear that any change to the document will be required (details in the COMMENT section for all of these): Mutually-verifiable "secure mode" seems to require that the peer's browser be included in the TCB, which is a bit hard to swallow.  Are we comfortable wrapping that in alongside "we trust the peer to not be malicious"? It's not clear how much benefit we can get from *optional* third-party identity providers; won't the calling service have the ability to silently downgrade to their non-usage even if both calling peers support it? I mostly only have editorial comments, though there are a few that are more content-ful. The user can observe the javascript running the browser, though maybe this distinction is not necessary here. I note that the author of this document is listed as a coauthor on huang-w2sp; does the self-cite really add much authority to the summary of the guarantee? The use of ALL-CAPS to call out new terms feels a bit dated. nit: I know this is a web-centric document, but the privileging of https as the only "secure" traffic reads a bit oddly to me; something like "note that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker."  (A thought experiment might be to consider whether wss://traffic counts as "HTTPS traffic".) It might be appropriate to provide some example references in place of "extensive research". nit: the wording here is a bit odd, since in case (1) you're verifying you're talking to A, but you still control where the media goes (in terms of A or not-A; A can of course then forward on the media further). nit: "local" is perhaps overly restricting, depending on interpretation Maybe note that the "result" of the cross-site requests that is leaked is in the form of pixels and not structured data, but that does not change the information content. nit: I'm confused by "another" here. This seems to be relying on the reader to have some background knowledge and make some leaps of reasoning that may not be reasonable to expect. This is especially challenging because if the site (and/or its javascript) is in the path for binding a cryptographic identity to a real-world identity, then a malicious site can still get whatever keys it wants authorized. seem to be missing a word or two here. nit: "If any page" is more emphatic, I think. Do we want any discussion of the risks when metered bandwidth (pay per byte) is in use? There's probably some room to tighten up the verbiage here; e.g., "the site initiating ICE" is referring to a website that is using a browser API to request ICE against some remote peer (right?).  And "ICE keepalives are indications" is using Indication as the technical term for a message that doesn't get an ACK response, not in its common English usage. A one- or two-sentence summary of the impact of misinterpretation attacks is probably in order, instead of making us follow the reference (which isn't a section reference). nit: "employed" to obfuscate what, exactly? nit: "incorporated" into what? I think I'm a little confused about which legacy actors we're talking about.  Are we still considering the broader situation a webserver-mediated interaction between two browsers or brower-adjacent applications?  (E.g., a WebRTC client calling some other sort of video chat system?) nit: "threat is" Is "answered" supposed to be some interaction with the controlling site? Some rewording for clarity is probably in order; "ordinary operation" is of a website without WebRTC; "sites can cause the browser to provide IP addresses" is when the site uses the browser API to request ICE initiation; etc. [Obligatory note about "Forward Secrecy" vs. "Perfect Forward Secrecy"] To be clear, the authentication that the calling service provides is a binding between identity and the public keys that are input to the key exchange mechanism? nit: "browser to use trusted UI" It's not clear that third-party identity providers actually provide downgrade-resistance -- can't the site mediating the calls just decline to acknowledge that a third-party identity is/was available for the peer? This seems to require extending the TCB from just the local browser to the remote browser as well, which is ... a stretch. (Also, do we really need the first person?) The coordinates for [OpenID] don't seem quite right.

this section provides more background on the existing Web security model.  <ins> In this model, then, the browser acts as a Trusted Coomputing Base </ins> (TCB) both from the user's perspective and to some extent from the server's.  While HTML and JavaScript (JS) provided by the server can cause the browser to execute a variety of actions, those scripts operate in a sandbox that isolates them both from the user's computer and from each other, as detailed below.  <ins> Conventionally, we refer to either web attackers, who are able to </ins> induce you to visit their sites but do not control the network, and  <ins> network attackers, who are able to control your network.  Network </ins> attackers correspond to the RFC3552 "Internet Threat Model".  Note  <ins> that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer.  TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker. </ins> 3.1. user must explicitly select the file and consent to its upload. [Note: in many cases browsers are explicitly designed to avoid dialogs with the semantics of "click here to bypass security checks",  <ins> as extensive research cranor-wolf shows that users are prone to consent under such circumstances.] </ins> Similarly, while Flash programs (SWFs) SWF can access the camera and microphone, they explicitly require that the user consent to that Moreover, the identity of the party the browser is connecting to is all that the browser can meaningfully enforce; if you are calling A, A can simply forward the media to C.  Similarly, if you authorize A  <ins> to place a call to B, A can call C instead.  In either cases, all the </ins> browser is able to do is verify and check authorization for whoever is controlling where the media goes.  The target of the media can of course advertise a security/privacy policy, but this is not something 4.1.3.  <ins> Now that we have described the calling scenarios, we can start to reason about the security requirements. </ins> As discussed in sec.same-origin, the basic unit of Web sandboxing is the origin, and so it is natural to scope consent to origin. The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com  <ins> The attacker forges the response from http://calling- </ins> service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure. site, that JavaScript is executed in the security context of the page finer-grained.  This could lead to compromise of a call even if the parent page is safe.  Note: this issue is not restricted to PAGES  <ins> which contain untrusted content.  If any page from a given origin ever loads JavaScript from an attacker, then it is possible for that </ins> attacker to infect the browser's notion of that origin semi- permanently. 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  <ins> indicates is unlikely), this would require (a) the browser to use the </ins> trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. cannot interfere.  In order to facilitate that, it will be necessary to provide features whereby the site can verifiably give up access to the media streams.  This verification must be possible both from the  <ins> local side and the remote side.  I.e., users must be able to verify that the person called has engaged a secure media mode (see </ins> sec.malicious).  In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the


Abstract <del> The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC".  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 soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges.  For instance, a Web browser might expose a JavaScript API which allows a server to place a video call.  Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera.  This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. </del>  1.

I suspect we'll get dinged here for referring to the RTCWEB WG by name. I'm thinking we can just trim it down to be a one sentence blurb (stolen from overview) and then say this is the threat model/analysis.

Abstract  <ins> WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. </ins> 1.


risk is created by allowing calls at all from a page fetched over HTTP. <del> 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 </del>  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 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 <del> ICE keepalives are indications, they will not work here.  I-D.ietf- rtcweb-stun-consent-freshness describes the mechanism for providing consent freshness. </del>  4.2.2. 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 <del> instance, SRTP RFC3711, DTLS RFC4347 and DTLS-SRTP RFC5763) is well </del>  understood.  However, we must examine this technology to the WebRTC context, where the threat model is somewhat different. provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMES (if generated according to RFC6222 rather than the privacy preserving <del> mode of I-D.ietf-avtcore-6222bis).  In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a source of call linkage I-D.ietf-rtcweb-ip-handling </del>  4.4.2.

I-D nits complained about a couple of outdated and unused references. This fixes them. Note that a few still remain.

risk is created by allowing calls at all from a page fetched over HTTP.  <ins> 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 </ins> 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 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  <ins> ICE keepalives are indications, they will not work here.  RFC7675 describes the mechanism for providing consent freshness. </ins> 4.2.2. 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  <ins> instance, SRTP RFC3711, DTLS RFC6347 and DTLS-SRTP RFC5763) is well </ins> understood.  However, we must examine this technology to the WebRTC context, where the threat model is somewhat different. provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMES (if generated according to RFC6222 rather than the privacy preserving  <ins> mode of RFC7022).  In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a source of call linkage I-D.ietf-rtcweb-ip-handling </ins> 4.4.2.


binary CBOR value is base64-encoded (RFC4648).  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Type, each of the content coding values is appended to the Content- Type value (media type and parameters, if any), separated by a "@" sign, in the order of the content codings were applied (the same <del> order as in RFC7231).  For example (using a content coding value of "deflate" as defined in RFC7230): </del>  If no "@" sign is present after the media type and parameters, then no content coding has been specified, and the "identity" content This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation RFC5234, which contains three new rules and a number of rules collected and adapted <del> from various RFCs RFC7231 RFC6838 RFC5234 RFC8866. </del>  7.

7de7a76 Update the ABNF to refer to httpbis-semantics; include quoted-pair 7775765 Switch from 7230/7231 to httpbis-semantics 0a57952 Address the question Roman Danyliw did not ask :-)

binary CBOR value is base64-encoded (RFC4648).  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor. <ins> 1.1. As with SenML in general, there is no expectation that the creator of a SenML pack knows (or has negotiated with) each consumer of that pack, which may be very remote in space and particularly in time. This means that the SenML creator in general has no way to know whether the consumer knows: each specific media-type-name used each parameter and each parameter value used each content coding in use each Content-Format number in use for a combination of these What SenML, as well as the new fields defined here, guarantees is that a recipient implementation when it needs to be updated to understand these field values and the values controlled by them; registries are used to evolve these name spaces in a controlled way.  SenML packs can be processed by a consumer while not understanding all the information in them, and information can generally be preserved in this processing such that it is useful for further consumers. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Type, each of the content coding values is appended to the Content- Type value (media type and parameters, if any), separated by a "@" sign, in the order of the content codings were applied (the same  <ins> order as in I-D.ietf-httpbis-semantics).  For example (using a content coding value of "deflate" as defined in I-D.ietf-httpbis- semantics): </ins> If no "@" sign is present after the media type and parameters, then no content coding has been specified, and the "identity" content This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation RFC5234, which contains three new rules and a number of rules collected and adapted  <ins> from various RFCs I-D.ietf-httpbis-semantics RFC6838 RFC5234 RFC8866. [[replace: RFC editor: Please replace [RFC-httpbis-semantics] by what gets published from ]] </ins> 7.