jiebi/CodeConvo huggingface dataset:
Change:
to authenticate when requested.  The requirements for client authentication vary based on application protocol and deployment. <del> A server MUST NOT use post-handshake client authentication (see Section 4.6.2 of TLS13). </del> <ins> A server MUST NOT use post-handshake client authentication (as defined in Section 4.6.2 of TLS13), because the multiplexing offered by QUIC prevents clients from correlating the certificate request with the application-level event that triggered it (see HTTP2-TLS13). More specifically, servers MUST NOT send post-handshake TLS CertificateRequest messages and clients MUST treat receipt of such messages as a connection error of type PROTOCOL_VIOLATION. </ins> 4.5.

Discussion:
Add short explanation and reference to explain why QUIC-TLS bans the use of post-handshake client authentication.
draft-tls section 4.4 (Peer Authentication) states: This sounds like there are security implications, but what they are is unclear. As a reader of the document, this makes me doubt my understanding of the protocol. If we don't have a good justification for banning this, we shouldn't be banning it. (This is me reopening since that was closed for being a question.)
Is the text unclear, or are you asking to re-enable post-handshake authentication?
At least I am curious about the reasoning behind this, not that I am against it.
NAME The best way to understand the rationale is to try to work through how a particular protocol might use this feature. Read , look at the design and discussion and see the sorts of problems it tries to address. In that case, some of the problems are with server-authentication, which you can safely ignore, but the general class of problems related to concurrency and how that relates to the status of authentication produce a fairly complex design. Now I might concede that it is possible to build a protocol that uses this TLS feature well, but I would still hold that are a far superior design.
NAME Thanks for the explantion and pointers. On exported authenticators I guess there is some overlap with OAuth2, Fido, and temporary web service tokens once you get past the handshake.
NAME if we have a good reason (which it sounds like we do), then this issue tracks adding that reason to the draft.
Now that NAME has clearly written this up, perhaps we can resolve this issue by adding a reference to URL in draft-ietf-quic-tls. If that sounds good to the editors I can write a PR.
I'd prefer more direct text. You get references to HTTP/2 doc and that in turn references TLS 1.2 with compression rules etc. that needs to be filtered out.
NAME : that sounds like a good way forward.
I'm going to say that this is editorial-enough to just merge. MUST NOT implies PROTOCOL_VIOLATION, so the new normative language is fine as editorial. I'll give others a chance to disagree though.
Change:
O/A required to establish a new RTP stream, the SFU may decide to reuse previously existing RTP sessions or even pre-allocate a predefined number of RTP streams and choose in each moment in time <del> which participant media will be sending through it.  This means that in the same RTP stream (defined by either SSRC or MID) may carry media from different streams of different participants.  As different keys are used by each participant for encoding their media, the receiver will be able to verify which is the sender of the media coming within the RTP stream at any given point if time, preventing the SFU trying to impersonate any of the participants with another participant's media. </del> <ins> which participant media will be sending through it. This means that in the same RTP stream (defined by either SSRC or MID) may carry media from different streams of different participants.  As different keys are used by each participant for encoding their media, the receiver will be able to verify which is the sender of the media coming within the RTP stream at any given point if time, preventing the SFU trying to impersonate any of the participants with another participant's media. </ins> Note that in order to prevent impersonation by a malicious participant (not the SFU), a mechanism based on digital signature

Discussion:
This PR addresses a few outstanding formatting cleanup issues: Fixes the list formatting problems identified in ... as well as a few others Wraps paragraphs to 80 columns
Merging on my own since these are just formatting changes.
This : ... is probably not a single paragraph. Similar problems and . It might be worth a more thorough proof-read of the document for others similar formatting problems.
Change:
the complete LwM2M model to a summary of how RD is used in there, with a reference to the current specification. <ins> Luminary example: Explain example addresses </ins> impl-info: Add note about the type being WIP Error handling: Place a SHOULD around the likely cases, and make

Discussion:
These fix some missing parts from , and address Erik's SLAAC comments as well as their fall-out on the CTs "knowing" the RD.
Change:
encrypt describes use of operations, administration and management (OAM) information).  Using network-layer approaches also has the advantage that common observation and analysis tools can be <del> consistently used by multiple transport protocols, however, these </del> <ins> consistently used for multiple transport protocols, however, these </ins> techniques are often limited to measurements within one or multiple cooperating domains.

Discussion:
well I don't think transport protocol will be using any of the tools rather those tools can be used to observer multiple protocols
Change:
object and consider the Handshake message invalid. Use the "confirmation_key" for the new group state to compute the <del> finished MAC for this message, as described below, and verify that it is the same as the "finished_mac" field. </del> <ins> "confirmation" MAC for this message, as described below, and verify that it is the same as the "confirmation" field. </ins> If the the above checks are successful, consider the updated GroupState object as the current state of the group.

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:
will never show up when queuing the value of a preference - the effective preference must be returned instead. <del> The implementation MUST ensure a consistent outcome given the same Selection Properties.  Internally, it MUST exclude all protocols and paths that match a Prohibit and exclude all protocols and paths that do not match a Require.  It MUST then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker. Note that the protocols and paths which are available on a specific system may vary, such that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations MUST ensure a deterministic outcome by prioritizing Selection Properties that select paths over those that select protocols.  Therefore, the transport system MUST try the path first, ignoring the protocol preference if the protocol does not work on the path. </del> <ins> The implementation MUST ensure an outcome that is consistent with application requirements as expressed using Require and Prohibit. While preferences expressed using Prefer and Avoid influence protocol and path selection as well, outcomes may vary given the same Selection Properties, as the available protocols and paths may vary across systems and contexts.  However, implementations are RECOMMENDED to aim to provide a consistent outcome to an application, given the same Selection Properties. Note that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations SHOULD prioritize Selection Properties that select paths over those that select protocols.  Therefore, the transport system SHOULD race the path first, ignoring the protocol preference if the protocol does not work on the path. </ins> Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the

Discussion:
In the , people found the normative language in too restrictive and agreed with the original suggestion in . Therefore, this PR moves the selection algorithm text to the implementation draft and removes some normative language in the interface draft. We still want to provide consistency to applications when possible, so there's a sentence in the implementation draft on this now as well.
LGTM modulo the suggestion from NAME which I would accept as-is Great with one minor knit.
Change:
Either the client or server of the connection. The smallest unit of communication on a stream in HTTP/3, <del> consisting of a header and a variable-length sequence of octets </del> <ins> consisting of a header and a variable-length sequence of bytes </ins> structured according to the frame type.  Protocol elements called "frames" exist in both this document and QUIC-TRANSPORT.  Where frames from QUIC-TRANSPORT are referenced, the frame name will be

Discussion:
Probably a bit overkill, but since it wasn't explicitly stated + I thought we had replaced "octets" with bytes everywhere else.
Change:
5. On receiving an ACK-FREQUENCY frame, an endpoint will have an updated <del> maximum delay for sending an acknowledgement, and a packet threshold as well.  The endpoint MUST send an acknowledgement when either of the two thresholds are met. loss and batch section describes exceptions to this strategy. </del> <ins> "max_ack_delay" and a "Packet Tolerance" threshold for sending an acknowledgement.  The endpoint MUST send an acknowledgement when either of the two thresholds are met.  That is, an endpoint MUST send an acknowledgement when one of the following conditions are met: Since the last acknowledgement was sent, the number of received ack-eliciting packets is greater than or equal to "Packet Tolerance". Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. loss and batch section describes exceptions to this strategy. </ins> An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all

Discussion:
merging.
We currently use PNs for ordering, but that runs afoul of requirements at the receiver specified in .
Change:
process, by performing normal ACME transactions and providing a validation response for his own account key.  The risks due to hosting providers noted above are a particular case.  For identifiers <del> where the server already has some public key associated with the </del> <ins> where a web server already has some public key associated with the </ins> domain this attack can be prevented by requiring the client to prove control of the corresponding private key.

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.
Change:
non-member reroutes a connection from the client to the server on the same endpoint. <ins> Entropy properties of external PSKs may also affect TLS security properties.  In particular, if a high entropy PSK is used, then PSK- only key establishment modes are secure against both active and passive attack.  However, they lack forward security.  Forward security may be achieved by using a PSK-DH mode. In contrast, 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 Diffie-Hellman (DH) exchange.  Low entropy keys are only secure against active attack if a PAKE is used with TLS. </ins> 4. <del> Applications MUST use external PSKs that adhere to the following requirements: </del> <ins> Applications MUST adhere to the following requirements for external PSKs: </ins> <del> Each PSK MUST be derived from at least 128 of entropy and MUST be at least 128-bits long unless the TLS handshake is being used with a separate key establishment mechanism such as a Diffie-Hellman exchange.  This recommendation protects against passive attacks using exhaustive search of the PSK. </del> <ins> Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a

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:
opportunistically present Token values to Origins without a corresponding TokenChallenge. <ins> The structure and semantics of the TokenChallenge and Token messages depend on the issuance protocol and token type being used; see AUTHSCHEME for more information. </ins> The challenge provides the client with the information necessary to obtain tokens that the server might subsequently accept in the redemption context.  There are a number of ways in which the token

Discussion:
The token_type field in and determines the remainder of each of these structures. This isn't explicitly stated anywhere, but I think it's an implicit assumption we've all been making.
Change:
If separate entities provide the and , these entities might need an arrangement similar to that between server and relay for managing <del> denial of service; see dos. </del> <ins> denial of service; see dos.  Moreover, the SHOULD apply some form of allowlist to ensure that the is not misused as a relay for HTTP messages to an arbitrary . </ins> Non-secure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway

Discussion:
This change tries to emphasize that OHTTP is a protocol between client, relay, and gateway, and that the target is sort of ancillary to the whole thing. It further clarifies that the relay should not act as an open proxy when it's operated by an entity that is separate from the target server.
This works for me. We can merge this and then I want to take another pass at the other PR.Thanks NAME -- couple nits, otherwise lgtm.LGTM
Change:
given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. <del> Its first argument is a string that is searched for at least one substring that matches the iregexp contained in the string that is the second argument.  The result is "true" if such a substring exists, "false" otherwise. </del> <ins> Its first argument is an optional string that is searched for at least one substring that matches the iregexp contained in the string that is the second argument.  The result is "true" if such a substring exists, "false" otherwise. </ins> The result is "Nothing" if the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf-

Discussion:
Fixes URL
NAME I pushed cb1cf124ab to clarify optional arguments.
NAME raised this in a PR review.
I think the answer is "yes" because that allows the function to be used on a Singular Path rather than on just a literal.
Yes. I would expect any function that can take a path must allow any value.
That should be enough to remove this double-take.
Change:
request.  A client MUST treat a successful response containing any Content-Length or Transfer-Encoding header fields as malformed. <del> The lifetime of the forwarding path is tied to the CONNECT stream. </del> <ins> The lifetime of the forwarding tunnel is tied to the CONNECT stream. </ins> Closing the stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame, <del> or a QUIC RESET_STREAM frame) closes the associated forwarding path. </del> <ins> or a QUIC RESET_STREAM frame) closes the associated forwarding tunnel. </ins> Along with a successful response, the proxy can send capsules to assign addresses and routes to the client (capsules).  The client can

Discussion:
The draft currently mentions an "IP forwarding path" (or elsewhere a "path for proxying IP packets") without defining what that term means. It's ambiguous because "path" is a . I'd propose we replace this use of the word "path" with the word "tunnel" which is .
Yes, "IP forwarding tunnel" sounds fine to me.
Yes tunnel is good. Or maybe association in the context of handling state st the proxy.
Change:
This ciphersuite uses the following primitives: <del> Hash function: P-256 </del> <ins> Hash function: SHA-256 </ins> Diffie-Hellman group: secp256r1 (NIST P-256)

Discussion:
The very first commit from PR (6ba86ff561484a9eb96012e3b55b49f23cb8f9e9) was removed and a separate Issue is filled for unifying the use of "`" and "_".
We inconsistently use the backtick, the underscore or nothing for messages fields or specific operations in the draft. This needs a fix, currently the opinion is to use the TLS style (aka remove everything)
Change:
There are a number of security issues related to resumption that are not described in RFC5216.  The problems, guidelines, and requirements <del> in this section therefore applies to all version of TLS. </del> <ins> in this section therefore applies to EAP-TLS when it is used with any version of TLS. </ins> When resumption occurs, it is based on cached information at the TLS layer.  To perform resumption in a secure way, the EAP-TLS peer and

Discussion:
The PR only fixed some of Alan's comments. I updated the PR to address all Alan's comments that was copied in the issue
From Alan's review: >
Also >
Looks good to merge
Change:
would be achievable with a steadier transmission in the same network. <del> Some receive-side ABR algorithms such as ELASTIC are designed to try to avoid this effect.  Another way to mitigate this effect is by the help of two simultaneous TCP connections is explained in MMSys11 for Microsoft Smooth Streaming.  In some cases, the system-level TCP slow-start restart can be disabled OReilly-HPBN. </del> <ins> Some receiver-side ABR algorithms such as ELASTIC are designed to try to avoid this effect. </ins> <del> 4.3.2. </del> <ins> Another way to mitigate this effect is by the help of two simultaneous TCP connections, as explained in MMSys11 for Microsoft Smooth Streaming.  In some cases, the system-level TCP slow-start restart can also be disabled, for example as described in OReilly- HPBN. 4.4.2. </ins> In the event of a lost packet on a TCP connection with SACK support (a common case for segmented delivery in practice), loss of a packet

Discussion:
This is in existing text, but I'd put a paragraph break after "Some receive-side ABR algorithms such as {{ELASTIC}} are designed to try to avoid this effect." and before "Another way to mitigate this effect is by the help of two simultaneous TCP connections, as explained in {{MMSys11}} for Microsoft Smooth Streaming. In some cases, the system-level TCP slow-start restart can also be disabled, for example as described in {{OReilly-HPBN}}."
Works for me. Updated...
The editors are 2:1 in favor of dropping ECN. Spencer is graciously in the rough. We should be talking more broadly about what happens when you lose any packets, If ECN belongs in the draft, it belongs somewhere else. "Coming improvements in transport behaviors" more broadly - we're talking about BBR and about end-to-end transport encryption now. Maybe we should talk about things like edge computing, etc ... but NAME will talk to the working group about this before we start a major refactor.
The point of these sections (4.3.1 Idle Time Between Segments and 4.3.2 Head of Line Blocking) was to explain how and why your bandwidth measurements can go wrong when you're trying to do ABR things with your bandwidth measurements. By name this seems like perhaps a better fit in the 4.4 Measurement Collection section, there might be a reason to merge some of the discussion there or reorganize the 2 sections together.
We maybe should also add a section along these lines on the wide variability in bitrates as things move, both for wi-fi and LTE and 5g. (or paths in general, with those as examples?)
Note also: "Refactor" here means provide a coherent story for why your ABR measurements can go wrong and what you can do about it.