jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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
Change:
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 .

Discussion:
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> <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 <del> the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </del> <ins> the ICE timers to be used; see RFC7675. </ins> 5.4.
Change:
There were two instances of "MUST not" that need to be "MUST NOT"
Address I-D nits complaints.

Discussion:
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> <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 <del> MUST not be shared even if the application is being shared.  If </del> <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
Change:
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.

Discussion:
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> <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.
Change:
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).

Discussion:
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> <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
Change:
…
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 :)

Discussion:
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> <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 <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> <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.
Change:
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.

Discussion:
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> <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. <del> The authority, which is the IdP domain name.  The authority MAY contain a non-default port number.  Any port number is removed </del> <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 <del> IdP.  The authority MUST NOT include a userinfo sub-component. </del> <ins> IdP. </ins> The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol.  Note that the separator characters '/'
Change:
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

Discussion:
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
Change:
Just some tweaks to consistently use offer/answer exchange and to explain that the offer/answer includes the caller's/callee's assertion, respectively.

Discussion:
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> <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 <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> <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.
Change:
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.)

Discussion:
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
Change:
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.

Discussion:
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
Change:
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

Discussion:
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> <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.
Change:
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.

Discussion:
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.
Change:
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.

Discussion:
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. <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> <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 <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> <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.