jiebi/CodeConvo huggingface dataset:
Change:
value in more than one report if the leader responds with status 200 and an empty body. <ins> The leader responds to requests with out-of-date "HpkeConfig.id" values, indicated by "EncryptedInputShare.config_id", with status 400 and an error of type 'outdatedConfig'.  Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </ins> 4.2.3. Each UploadReq carries a list of extensions that clients may use to

Discussion:
It seems silly to have clients revalidating the HPKE key for each request, so we probably want some kind of caching. I'm not sure HTTP Caching is quite what we want, but something... NAME NAME recommendations?
I'm going to need a little more context to provide good advice. If we don't need key consistency (it doesn't appear so) and you only need correctness, then the client should just be able to talk directly to the collector and get keys periodically. HTTP caching works fine for that purpose. This would also need a rejection message so that the collector (or the leader on their behalf - the leader is more likely to learn about bad key identifiers before clients) can reject an out-of-date key in case the cache needs to be invalidated.
We do not need key consistency. The rejection message seems like a good idea.
Change:
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

Discussion:
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
Change:
The application can set a minIncompleteLength value to indicates the smallest partial Message data size in bytes that should be delivered in response to this Receive.  By default, this value is infinite, <del> which means that only complete Messages should be delivered.  If this value is set to some smaller value, the associated receive event will be triggered only when at least that many bytes are available, or the Message is complete with fewer bytes, or the system needs to free up memory.  Applications should always check the length of the data delivered to the receive event and not assume it will be as long as minIncompleteLength in the case of shorter complete Messages or memory issues. </del> <ins> which means that only complete Messages should be delivered (see receive-partial and receive-framing for more information on how this is accomplished).  If this value is set to some smaller value, the associated receive event will be triggered only when at least that many bytes are available, or the Message is complete with fewer bytes, or the system needs to free up memory.  Applications should always check the length of the data delivered to the receive event and not assume it will be as long as minIncompleteLength in the case of shorter complete Messages or memory issues. </ins> The maxLength argument indicates the maximum size of a Message in bytes the application is currently prepared to receive.  The default

Discussion:
1 tiny fix suggested to make the text a little clearer (because the default "complete message" delivery may need a de-framer, or the whole Connection may function as a message), and pointed at a possible error when delivering partial data (it's already written elsewhere, but the suggestion makes a sentence more correct, I believe).
Looks good, thanks!
lgtm
Change:
of the attacker is to learn private information about the inner ClientHello, such as the true SNI value. <del> 10.8.1. </del> <ins> 10.7.1. </ins> This attack uses the client's reaction to an incorrect certificate as an oracle.  The attacker intercepts a legitimate ClientHello and

Discussion:
The misrouting content no longer applies since the backend server sees the full CH, with the true SNI.
Change:
H3_STREAM_CREATION_ERROR; see errors. Each Push ID MUST only be used once in a push stream header.  If a <del> push stream header includes a Push ID that was used in another push stream header, the client MUST treat this as a connection error of type H3_ID_ERROR; see errors. </del> <ins> client detects that a push stream header includes a Push ID that was used in another push stream header, the client MUST treat this as a connection error of type H3_ID_ERROR; see errors. </ins> 6.2.3.

Discussion:
Adds the all-important conditional.
For clients that have sent CANCEL_PUSH, they don't know if server's push stream will still arrive or not. They have to remember Push IDs forever in order to differentiate between cancelled push and completed push.
I would appreciate some quick discussion if this issue is important to address before I approve or not.
We could make this a MAY. The other formulation we've used is "MUST ... if the client detects", making the response mandatory if the condition is detected, but not specifying the required level of effort to detect it.
I don't know that this issue is critical to address, but I agree that with certain (reasonable) implementation strategies this particular MUST becomes unenforceable / unachievable.
+1 for "MUST if the client detects" if we're going to make a change.
I think "MUST if detects" is suitable here - it points at the core problem. Simply s/MUST/MAY doesn't help people appreciate that might not be able to detect the condition. I'd also suggest that "MUST if detects" is an editorial change.
NAME can you confirm if addresses your issue?
Looks good!
Thanks. In that case I believe we have addressed this issue with an editorial change. NAME please confirm if we can merge the related PR and incorporate the change in during the RFC editor process.
Yes, the change looks good. I could actually include it as an RFC-edtior note in my approval message.
An elegant solution :)
Change:
It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this mechanism prevents version downgrade attacks where an attacker would <del> actively rewrite messages messages with a lower protocol version than the ones originally offered by the endpoints.  When multiple versions of MLS are available, the negotiation protocol guarantees that the version agreed upon will be the highest version supported in common by the group. </del> <ins> actively rewrite messages with a lower protocol version than the ones originally offered by the endpoints.  When multiple versions of MLS are available, the negotiation protocol guarantees that the version agreed upon will be the highest version supported in common by the group. </ins> 3.2.

Discussion:
In the section 3.1.7. Compatibility with future versions of MLS, the word "messages" is duplicated.
Thanks
Change:
error of type 0x16d (equivalent to a fatal TLS missing_extension alert, see tls-errors). <del> While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the handshake completes, and reliance on them should be minimized. However, any tampering with the parameters will cause the handshake to fail. </del> <ins> Transport parameters become available prior to the completion of the handshake.  A server might use these values earlier than handshake completion.  However, the value of transport parameters is not authenticated until the handshake completes, so any use of these parameters cannot depend on their authenticity.  Any tampering with transport parameters will cause the handshake to fail. </ins> Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in TLS13).  A

Discussion:
This is OK, but only in a limited fashion.
NAME said: parameters are not delivered until the handshake is complete. In 8.2 it says that the TPs are "available" but "not fully trusted" before completion. The latter is certainly true; but the server can't send 0.5-RTT packets (e.g. a SETTINGS frame) without any indication of the client transport parameters. I would suggest a clarification in 4.1.3 and letting the language in 8.2 stand.
Proposed resolution is
I think the limitations could be a be clearer, but heading in a good direction.I think the changes add clarity.
Change:
token's own key or, in the case of bearer tokens, the client instance's key. <del> [[ See issue #105 [33] ]] </del> <ins> [[ See issue #105 [31] ]] </ins> In the following sections, unless otherwise noted, the "RS256" JOSE Signature Algorithm is applied using the following RSA key (presented

Discussion:
update token rotation response and requirements add considerations for the difficulties of rotating and revoking stateless tokens add considerations on rotation in unreliable networks
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 2284ffefdc540b8743400e9463fb65fc99070d4a Inspect the deploy log: Browse the preview:
Rotation the Access Token: Editor's note: The net result is that the client's always going to use the management URL that comes back. But should we let the server omit it from the response if it doesn't change? That seems like an odd optimization that doesn't help the client.
Close by making inclusion of URI REQUIRED.
Rotating the Access Token: Editor's note: We could also use different verbs to signal whether or not the old token should be kept around or not, instead of using a token flag to do this.
Keep "MUST if possible" here. If you want two access tokens, use the grant API not the token rotation API. The rotation mechanism should be for getting a new value for an existing token and replacing it, not for minting entirely new separate tokens (which is what the grant continuation/update API is for). We need to keep "if possible" for the case of using stateless tokens (fully self-contained JWTs), and add a discussion on when it might not be possible.
a few minor comments
Change:
absent.  A client MUST treat a failed validation as a connection error of type TRANSPORT_PARAMETER_ERROR. <del> A Retry packet does not include a packet number and cannot be explicitly acknowledged by a client. </del> 17.3. This version of QUIC defines a single packet type which uses the

Discussion:
This was getting a little long. You could get lost in there. The text was fine, it was mostly well structured. All it needed was one small move and some headers.
Change:
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier <del> draft-ietf-tls-rfc4492bis-03 </del> <ins> draft-ietf-tls-rfc4492bis-04 </ins> Abstract

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519
Change:
3.5. <del> SRTP - Secure RTP - is a profile for RTP that provides confidentiality, message authentication, and replay protection for data and control packets RFC3711.  SRTP packets are encrypted using a session key, which is derived from a separate master key.  Master keys are derived and managed externally, e.g., via DTLS, as specified in RFC 5763 RFC5763, under the control of a signaling protocol such as SIP RFC3261 or WebRTC I-D.ietf-rtcweb-security-arch. </del> <ins> Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets and RTP control protocol (RTCP) packets RFC3711. </ins> 3.5.1. SRTP adds confidentiality and optional integrity protection to RTP data packets, and adds confidentially and mandatory integrity <del> protection to RTP control (RTCP) packets.  For RTP data packets, this is done by encrypting the payload section of the packet and optionally appending an authentication tag (MAC) as a packet trailer, with the RTP header authenticated but not encrypted.  The RTP header itself is left unencrypted to enable RTP header compression RFC2508 RFC3545.  For RTCP packets, the first packet in the compound RTCP packet is partially encrypted, leaving the first eight octets of the header as cleartext to allow identification of the packet as RTCP, while the remainder of the compound packet is fully encrypted.  The entire RTCP packet is then authenticated by appending a MAC as packet trailer. </del> <ins> protection to RTCP packets.  For RTP data packets, this is done by encrypting the payload section of the packet and optionally appending an authentication tag (MAC) as a packet trailer, with the RTP header authenticated but not encrypted (the RTP header was left unencrypted to enable RTP header compression RFC2508 RFC3545).  For RTCP packets, the first packet in the compound RTCP packet is partially encrypted, leaving the first eight octets of the header as clear-text to allow identification of the packet as RTCP, while the remainder of the compound packet is fully encrypted.  The entire RTCP packet is then authenticated by appending a MAC as packet trailer. </ins> Packets are encrypted using session keys, which are ultimately <del> derived from a master key and some additional master salt and session </del> <ins> derived from a master key and an additional master salt and session </ins> salt.  SRTP packets carry a 2-byte sequence number to partially identify the unique packet index.  SRTP peers maintain a separate <del> rollover counter (ROC) for RTP data packets that is incremented </del> <ins> roll-over counter (ROC) for RTP data packets that is incremented </ins> whenever the sequence number wraps.  The sequence number and ROC together determine the packet index.  RTCP packets have a similar, yet differently named, field called the RTCP index which serves the

Discussion:
This attempts to make the description of DTLS+SRTP keying less confusing.
The description of how DTLS is used for establishing SRTP connections is confusing: is mutual auth in DTLS ever used, or is an OOB fingerprint via SIP always used? The text here needs to be clarified.
Change:
4.3. <ins> SFrame encryption uses an AEAD encryption algorithm and hash function defined by the ciphersuite in use (see ciphersuites).  We will refer to the following aspects of the AEAD algorithm below: "AEAD.Encrypt" and "AEAD.Decrypt" - The encryption and decryption functions for the AEAD.  We follow the convention of RFC 5116 RFC5116 and consider the authentication tag part of the ciphertext produced by "AEAD.Encrypt" (as opposed to a separate field as in SRTP RFC3711). "AEAD.Nk" - The size of a key for the encryption algorithm, in bytes "AEAD.Nn" - The size of a nonce for the encryption algorithm, in bytes </ins> 4.3.1. <del> Each client creates a 32 bytes secret key K and share it with with other participants via an E2EE channel.  From K, we derive 3 secrets: </del> <ins> Each client creates a secret key "base_key" and shares it with the other participants via an E2E secure channel.  From "base_key", we derive the following values using HKDF RFC5869: </ins> <del> 1- Salt key used to calculate the IV </del> <ins> A Salt key used to calculate the IV </ins> <del> 2- Encryption key to encrypt the media frame </del> <ins> An encryption key to encrypt the media frame </ins> <del> 3- Authentication key to authenticate the encrypted frame and the media metadata </del> <ins> An authentication key to authenticate the encrypted frame and the media metadata </ins> <del> The IV is 128 bits long and calculated from the CTR field of the Frame header.  First the var int CTR is decoded into 16 bytes long field, where CTR fills the the 8 most significant bytes and low 8 bytes are always filled with zeros: </del> <ins> Each SFrame KID value identifies a "base_key", and thus both the "sframe_secret" and "sframe_salt" values to be used for encryption and decryption. </ins> 4.3.2.

Discussion:
This PR revises the encryption procedures in a few ways: Ciphersuites for AES-GCM are now included The combination of AES-CM and SHA2 is spelled out, including an AAD length prefix to guard against confusion attacks We use the RFC 5116 AEAD interface (in particular, no separate auth tag) ... and as a result the tag truncation is internal to the AES-CM+SHA combination SFrame encryption now includes the encoded header as AAD Depends on
Change:
in RFC5245, Section 15.5, and the set of specified options is stored. <del> Any "a=fingerprint" lines are parsed as specified in RFC4572, </del> <ins> Any "a=fingerprint" lines are parsed as specified in RFC8122, </ins> Section 5, and the set of fingerprint and algorithm values is stored.

Discussion:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.
Change:
The ACME client MAY request other formats by including an Accept header field RFC7231 in its request.  For example, the client could <del> use the media type "application/pkix-cert" RFC2585 or "applicaiton/ </del> <ins> use the media type "application/pkix-cert" RFC2585 or "application/ </ins> pkcs7-mime" RFC5751 to request the end-entity certificate in DER format.  Server support for alternate formats is OPTIONAL.  For formats that can only express a single certificate, the server SHOULD

Discussion:
Change "applicaiton" to "application"
With any luck we'll have to catch this in the RFC editor queue; hopefully there won't be another draft.
Thanks NAME
Change:
If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.3. <del> If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error. </del> For each specified RTP header extension, establish a mapping <del> between the extension ID and URI, as described in section 6 of RFC5285.  If any indicated RTP header extension is not supported, this MUST result in an error. </del> <ins> between the extension ID and URI, as described in RFC5285, Section 6. </ins> If the MID header extension is supported, prepare to demux RTP streams intended for this m= section based on the MID header

Discussion:
The local description can never be wrong, because it is constructed by the browser. I also explicitly added text to make clear that the mux state for any m= line cannot change.
LGTM
Section 5.8 describes the behavior of an implementation processing its own unmodified SDP. It contains significant error language that should have been removed when SDP munging was removed. In particular, please remove all of the following: • "If an error is returned, the session MUST be restored to the state it was in before performing these steps." • "If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error." • "If any indicated RTP header extension is not supported, this MUST result in an error." • "If any indicated media format is not supported, this MUST result in an error." • "If any referenced primary payload types are not present, this MUST result in an error." The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only.
I think Adam is right about this, but I wonder if this actually belongs elsewhere, so further study needed.
This is already duplicated. This seems to be a prohibition that is stricter than RFC 5761, and if we remove it here we have removed it generally, unless I have missed somewhere else we say it. This is not appropriate for remote descriptions. We say this in 5.9. >The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only. Yeah, I think Adam is right about this and it's probably the result of some section refactor
Made some progress on it. Editor discussion on the mux piece. Once an m= line has mux or non-mux negotiated, that's immutable.
LG with nits
Change:
draft-02 <del> Change public key type (*) </del> <ins> Change public key type. (*) </ins> <del> Change DelegationUsage extension to be NULL. </del> <ins> Change DelegationUsage extension to be NULL and define its object identifier. </ins> Drop support for TLS 1.2.

Discussion:
The suggested OID for the DelegationUsage extension will be 1.3.6.1.4.1.44363.44.