jiebi/CodeConvo huggingface dataset:
Change:
entire ClientHello, this design additionally supports encrypting the ALPN extension. <del> 10.9. </del> <ins> 10.10. </ins> Variations in the length of the ClientHelloInner ciphertext could leak information about the corresponding plaintext. padding describes a RECOMMENDED padding mechanism for clients aimed at reducing potential information leakage. <del> 10.10. </del> <ins> 10.11. </ins> This section describes the rationale for ECH properties and mechanics as defenses against active attacks.  In all the attacks below, the

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)
Change:
one server, and that these never switch roles.  If this assumption is violated, then the security properties of TLS are severely weakened. <del> As discussed in use-cases, there are use cases where it is desirable for multiple clients or multiple servers share a PSK.  If this is done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious weaknesses here: </del> <ins> use-cases discusses use cases where it is desirable for multiple clients or multiple servers share a PSK.  If this is done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious weaknesses here: </ins> Any group member can impersonate any other group member.

Discussion:
Discuss the different variants: High entropy PSK+DH High entropy PSK-only Low PSK with strong (balanced) PAKE ... and their security properties. For encodings, mention RFC1751 and Bjorn's draft.
Proposed text: If a high entropy PSK is used, then PSK-only key establishment modes are secure against both active and passive attack, but will not enjoy forward security. Forward security may be achieved by using a PSK-DH mode. If a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search passive attacks which will reveal the traffic keys. PSK-DH modes are subject to active attacks in which the attacker impersonates one side. The exhaustive search phase of these attacks can be mounted offline if the attacker captures a single handshake using the PSK, but those attacks will not lead to compromise of the traffic keys for that connection because those also depend on the DH exhange. Low entropy keys are only secure against active attack if a PAKE is used with TLS.
Change:
If the server negotiates an earlier version of TLS, or if it does not provide an "encrypted_server_name" extension in EncryptedExtensions, <del> the client proceeds with the handshake, verifying the certificate against ESNIKeys.public_name as described in verify-public-name.  The client MUST NOT enable the False Start optimization RFC7918 for this handshake.  If verification or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT treat this as a secure signal to disable ESNI. </del> <ins> the client proceeds with the handshake, authenticating for ESNIKeys.public_name as described in auth-public-name.  If an earlier version was negotiated, the client MUST NOT enable the False Start optimization RFC7918 for this handshake.  If authentication or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT treat this as a secure signal to disable ESNI. </ins> Otherwise, when the handshake completes successfully with the public <del> name verified, the client MUST abort the connection with an </del> <ins> name authenticated, the client MUST abort the connection with an </ins> "esni_required" alert.  The client can then regard ESNI as securely disabled by the server.  It SHOULD retry the handshake with a new transport connection and ESNI disabled.

Discussion:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.
Change:
Structure of this message: <del> %%% Authentication Messages enum { rsa_sign(1), dss_sign_RESERVED(2), rsa_fixed_dh_RESERVED(3), dss_fixed_dh_RESERVED(4), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20), ecdsa_sign(64), (255) } ClientCertificateType; A list of the types of certificate types that the client may offer. </del> <ins> %%% Authentication Messages opaque DistinguishedName<1..2^16-1>; </ins> A list of the hash/signature algorithm pairs that the server is <del> able to verify, listed in descending order of preference. </del> <ins> able to verify, listed in descending order of preference.  Any certificates provided by the client MUST be signed using a hash/ signature algorithm pair found in supported_signature_algorithms. </ins> A list of the distinguished names X501 of acceptable

Discussion:
This PR includes CertificateRequest changes discussed at the TLS WG Interim: Removes certificate_types, which are no longer needed. Adds client cert selection by certificate extension values. This helps make CertificateRequest more specific and eliminate the need for the confusing "Choose a certificate" UI.
Change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses its own definition of client.  When referring to the HTTP definition of client (Section 3.3 of HTTP), the term "HTTP client" is used; see http-usage. </ins> An HTTP request that is encapsulated in an HPKE-encrypted message; see request.

Discussion:
It would be wrong to use "user agent" as this could be used for an HTTP request made by any client toward any server (using the HTTP definitions).
Why don't use "Oblivious Client" and the "OC" acronym, like OAuth does with "Authorization Server"? This would preserve the natural "client" meaning, and could make the document more readable. The same acronym trick could ease readability wrt "Oblivious Request Resource" and "Oblivious Target Resource"...
I know that people like acronyms, but it doesn't really solve this problem. The oblivious HTTP client really is an HTTP client in the sense that HTTP knows; calling it anything else would be more confusing, I think. As it seems like this is a case where more words would help. I've added more words.
Since there are so many occurrencies of I think that's ok :) Probably in the Introduction, "client" means "HTTP client", but anyway the difference is clear to me now :D
since there are various layers, the term "client" can be applicable to both the oblivious proxy/request resource. Maybe the term User agent can be appropriate when we refer to the originating client?
Hi Roberto, Does URL clarify things? I think that "client" still makes a lot of sense here, but you are right that this is not an HTTP client in the strictest sense. (Although, now that I write this, it really is, it's just that this uses something other than a connection as a medium from getting a request to the server...)
LGTM
Change:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-11 </del> <ins> draft-ietf-rtcweb-transports-12 </ins> Abstract

Discussion:
o Added a SHOULD NOT about using deprecated temporary IPv6 addresses. o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657
Some systems keep old IPv6 addresses around even when changing to new for privacy. How should we avoid trying the ones that don't make sense to try?
As documented here: URL and here: URL it appears that the implementers claim everything is working as designed on systems which accumulate several temporary deprecated IPv6 addresses. My assumption here is that using deprecated temp addresses as ICE candidates (additionally to the non deprecated temporary address) is not going to increase the likeliness of establishing a connection. So adding these additional ICE candidates only causes extra over head. Therefore adding a warning/clarification statement for implementers to avoid deprecated temporary IPv6 addresses (in case there is usable non-deprecated temporary IPv6 address available) seem appropriate.
Adding warning in -12: "If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses."
Sounds good to me.
Addressed in (version -12)
Change:
delivered as a routine practice, rather than in exceptional cases for content that was considered "sensitive". <del> 6. </del> <ins> 5. </ins> This document requires no actions from IANA. <del> 7. </del> <ins> 6. </ins> This document introduces no new security issues. <del> 8. Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, and Mike English for their very helpful reviews and comments. </del>

Discussion:
Reverts ietf-wg-mops/draft-ietf-mops-streaming-opcons (still learning github)
Change:
Evidence, and again needs to take into account the maximum permitted clock skew between the Verifier and the Attester. <ins> The Attester does not consume the Attestation Result, but might cache it. </ins> The Relying Party can check whether the Attestation Result is fresh when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v) < Threshold", where the Relying Party's threshold is large enough to

Discussion:
related to There is something foundational I am not following about this section. The interactions described here do not conform behaviors described in the terminology in Section 4 or the high-level reference architecture of Figure 1. I'm not sure how to reconcile this discrepancy. Minimally, these discrepancies in Figure 5 and 6 are not consistent with the roles defined in Section 4. [restated here but same feedback on -13] -- Figure 5. Shows the Attester consuming Attestation Results -- Figure 5. Shows the Attester producing Attestation Results -- Figure 6: Shows Relying party consuming Evidence -- Figure 6: Shows the Relying Party producing/passing Evidence The introductory text states that "[t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns." I don't follow what is being illustrated in the context of RATS. What is the takeaway for implementers or designers from this section? [Author's response] URL [Roman's response on -15] The above github comment addressed a few issues from the -13 review, but not this one.
Reply by email: "The Attester does not consume the Attestation Result, but might cache it. "
The text explains the intent correctly regardless of how the lines are drawn. I can convince myself that it is correct draw the line through the box (or not). The important clarifying point should be that the end-to-end message flow as described in the conceptual architecture is preserved through the various topology models that may exist. Second point is there can be a large variety of topology models (aka hybrids) but none of these hybrids changes the expectation of end-to-end message flow.
also helps.
Change:
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> <ins> detail and out of scope of this document. </ins> For use in signaling, the assertion is serialized into JSON, RFC4648, <del> and used as the value of the "identity" attribute. </del> <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.

Discussion:
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.
Change:
more than hundreds of milliseconds).  Real-time media can be used to support interactive communication. <del> The protocol implementation involved in the SDP offer/answer exchange, as defined in RFC3264 section 3. </del> <ins> The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in RFC3264 section 3. </ins> Communication that happens in order to establish, manage and control media paths and data paths.

Discussion:
This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt
Change:
roster, since this is the number of nodes in a tree with "size" leaves, according to the structure described in ratchet-trees. <del> The "transcript" field contains the list of "GroupOperation" </del> <ins> The "transcript_hash" field contains the list of "GroupOperation" </ins> messages that led to this state. When a new member is added to the group, an existing member of the

Discussion:
Fixes for points 1, 2, 4, 7 in .
I think a bunch of these are probably relics of previous versions. For reference, the page numbers listed are from the PDF version of draft 3 of the protocol: [x] 1 - p6: is mentioned, but it is not defined anywhere in the specification. Perhaps is intended.[x] 2 - p19: A field is mentioned, but only is present. Also it's unclear which function is supposed to be used here. It can't be ciphersuite-dependent, since it has to be the same for every Participant.[x] 3 - p22: is used in a diagram, but never defined. I think this is important, and it's mentioned elsewhere.[x] 4 - p24: is mentioned, but never defined. Is it supposed to say ?[ ] 5 - p25: The underlying Hash that HMAC uses can't be defined by anyone's ciphersuite. This is group state, and everyone has to agree on this.[x] 6 - p28: Mentioned "update secret" again without explanation.[x] 7 - p29: "identity tree" is mentioned, but I can't tell what that's referring to. Also "update secret" is here.[x] 8 - p35: is mentioned, but never defined. Perhaps is intended.
Thanks a lot for the review, this is very useful. I have a pass planned for this week and will fix these issues :)
NAME A PR was opened with fixes for points 1, 2, 4, 7. Point 8 was already solved. An issue has been opened to solve points 3 and 6 related to the update secret definition. I tried to figure out your point 5 but I didn't understand it, can you give details ?
Sorry for the delay. I think point 5 was a misunderstanding over when a common ciphersuite is established in the protocol. I'm still not 100% clear on it, but I think I'm just missing something simple. Consider it withdrawn.
Ok, then these issues are fixed by and . Thanks
Change:
Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection <del> migration; however, these flows can be associated with flows for which a version has been identified; see sec-flow-association. </del> <ins> migration; however, it might be possible to associate a flow with a flow for which a version has been identified; see sec-flow- association. </ins> This document focuses on QUIC Version 1, and this section applies only to packets belonging to Version 1 QUIC flows; for purposes of

Discussion:
This implies that the version of QUIC being used in a given flow can be determined simply by linking that flows to one with a handshake. That assumes that all the work we did to make flows difficult to link was for naught. Maybe "can" should be a "might" or something along those lines. I don't really like the implication that the attempt be made to link flows like this either.
In addition to this, the following text from Section 3.4 is not precise enough to be correct: The assumption that the same flow persists might be good in some cases, but this does not necessarily hold in the case that the endpoint address is used by an endpoint that requires non-zero-length connection IDs. This needs to be more precise if the claim is to hold.
Not sure what you mean by your second comment here. Of course if there is no connection ID you cannot associate it to anything...? What's missing? Can you propose something?
On re-reading, it seems to be a little clearer. It seems to be saying that an observer can match a particular connection ID with a flow and then, if the flow changes address at only one end without changing the connection ID, then it was subject to rebinding and can be assumed to be the same flow. However, it needs to specify that the connection ID association needs to be directional. Maybe that is assumed, but it should be stated. And it needs to say that this is unlikely to apply when the connection ID is empty.
Change:
changes in connection IDs are supported in DTLS 1.3 but not in DTLS 1.2. <del> 6. </del> <ins> 7. 7.1. </ins> Note: This algorithm does not take the off-path scenario into account.

Discussion:
Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature. I think the discussion around interplay between RRC and CID should go in a separate (sub)section.
Change:
a path, or for a period of three PTOs (see Section 6.2 of QUIC- RECOVERY).  If all packets marked with non-zero ECN codepoints are subsequently lost, it can disable marking on the assumption that the <del> marking causes in loss. </del> <ins> marking caused the loss. </ins> An endpoint thus attempts to use ECN and validates this for each new connection, when switching to a server's preferred address, and on

Discussion:
Section 13.4.2: If all packets marked with non-zero ECN codepoints are subsequently lost, it can disable marking on the assumption that the marking causes in loss. s/in/the?
Change:
not configured to use a bearer token, the HTTP Authorization header field must not be sent in any request. <del> 4.6. </del> <ins> 5.1. </ins> Both Simulcast RFC8853 and Salable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent

Discussion:
NAME wdyt?
he usability of the ICE server configuration seem to go far beyond WHIP. Also, in my opinion the way you configure your STUN/TURN servers is slightly outside the scope of core WHIP. But, assuming you want to keep the text: First, you should add references to where the STUN- and TURN server URIs are defined. Second, I believe Link URIs have to be enclosed by . Third, I think the "ice-server" value is misleading. An ICE server is not the same thing as a STUN/TURN server. You don't even have to use ICE in order to support STUN/TURN. Fourth, related to the third issue, perhaps you should use the "urn:ietf:params:whip:" appendix also for the STUN/TURN servers? Fifth, you say that not all webrtc implementations may allow STUN/TURN server re-configuring after the offer has been created. But, does WebRTC even define a mechanism to programmatically configure the servers? If so, please add a reference. If not, please indicate that.
Using WHIP without a valid TURN/STUN server configuration will fail in many cases, so In practice any WHIP service provider will also be providing STUN/TURN services to be used with. WHIP allows sending the STUN/TURN server configuration in the HTTP request in order to not have to manualy configure the configuration manually o the client. Moreover, some WHIP providers may want to restrict the usage of their TURN/STUN server and only provide short lived credentials that are only valid in the context of the WHIP session. The term is taken from the W3C webrtc spec that uses the configuration property when creating the PC. Regarding the and , yes, it is a typo and should be corrected. Regarding the it was originally propossed like that but i was agreed that this could be used to configure other webrtc services and not only WHIP and it could be better to not have the urn be whip-specific WebRTC w3c spec supports reconfiguration of the stun/turn server connection via URL
Won't the WHIP servers have a publicly available IP address in most cases? And, as the WHIP client is the one always establishing the media path, there should be no need for a STUN/TURN server in such cases.

Or? Ok. I suggest adding a note to indicate that. I suggest adding some text and point that out. Thanks! I suggest adding a reference,
Clients may be behind restricted firewalls which block UDP. It is easier to just deploy a TURN server to do TURN over TCP/TLS than implement ICE TCP on the media server (and ICE TLS is not standard anyway). Also, you typically have less TURN servers than media servers, so it is easier to have them allowed by IP on the firewalls. In our case for example, our IPs of the media server pool are dinamic, so we must use TURN server IPs instead. I will add notes for the other comments as suggested