jiebi/CodeConvo huggingface dataset:
Change:
cipher suite interoperability testing and it's suggested that IANA use these values for assignment. <del> [[TODO: How do I write IANA instructions to reserve all ALPN identifiers that begin with "ignore/"?  Perhaps it would be better to reserve a concrete handful of identifiers instead.]] </del> <ins> This document updates the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry, available from <https://www.iana.org/assignments/tls-extensiontype-values/tls- extensiontype-values>: </ins> 7.

Discussion:
Also fix the build. Some references were a little off.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .
THere's a TODO for reserving "ignore/" ALPN.
NAME are you thinking: Protocol: ignore/1 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 Reference: (This document) ... Protocol: ignore/10 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 0x30 Reference: (This document)
I didn't have a particularly clear picture in my mind, TBH. We're not sending fake ALPN values or anything right now. ignore/[numbers] seems fine. Or maybe it would be better to drop the "ignore/" thing and just use the same two-byte pattern. "ignore/" makes it look like you should do a prefix check, which isn't really what we want...
NAME NAME NAME NAME NAME NAME PTAL because I think this is really the last "technical" point remaining.
NAME not sure what you mean by two-byte pattern. You mean things like "qz" "db" "r$" etc? If so, I agree that that is better.
Yeah. For the sake of consistency, I figure it could just be the same old 0x?a, 0x?a pattern that everything else does. (Though they then wouldn't be ASCII. Could pick some pattern that's ASCII if that's preferred.)
i think two random bytes is good (testing for non-ascii seems greasy as well)
I also prefer the two-byte pattern, since ignore/ might indicate to people that this is somehow meant to be special-cased.
Two bytes it is! URL
Change:
1.4. <del> The GNAP protocol can be used in a variety of ways to allow the core delegation process to take place.  Many portions of this process are </del> <ins> GNAP can be used in a variety of ways to allow the core delegation process to take place.  Many portions of this process are </ins> conditionally present depending on the context of the deployments, and not every step in this overview will happen in all circumstances.

Discussion:
I attempted to rephrase all occurrences of the redundant "GNAP protocol" in a way that made sense. Most of the time it was changing "the GNAP protocol" to just "GNAP", but there are a few cases where it sounded weird and required some more context.
Change:
specified in RFC8392. In order to facilitate offline processing of access tokens, this <del> draft uses the "cnf" claim from I-D.ietf-ace-cwt-proof-of-possession and specifies the "scope" claim for both JSON and CBOR web tokens. </del> <ins> document uses the "cnf" claim from I-D.ietf-ace-cwt-proof-of- possession and specifies the "scope" claim for JWT- and CWT-encoded tokens. </ins> The "scope" claim explicitly encodes the scope of a given access token.  This claim follows the same encoding rules as defined in

Discussion:
Based on the review by Steffi I updated the text in Section 5.8.1.1 "Verifying an Access Token".
Change:
completion; i.e. when the Message was not sent before its Lifetime (see msg-lifetime) expired.  This is separate from SendError, as it is an expected behavior for partially reliable transports.  The <del> Expired Event contains a reference to the Message to which it applies. </del> <ins> Expired Event contains a reference to the Message Context of the Message to which it applies. </ins> 7.2.2.3.

Discussion:
Also spotted some further small nits while reviewing the document, will create a pull request for those.
Change:
The string "http-01" A random value that uniquely identifies the challenge.  This value <del> MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </del> <ins> MUST have at least 128 bits of entropy.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and

Discussion:
Per feedback from Zach Shepherd[0] on the mailing list the justification for the 128 bits of required token entropy from section 8.2 is at odds with the actual rationale (as I understand it). This commit updates the justification for the entropy requirement to not mention being secret from an attacker, but instead not predictable by a naive challenge response server that would complete challenges without having been a party to the authz/chal creation.
It seems like whatever change is made should be applied to sections 8.2, 8.3, and 8.4.
Based on zjs' feedback, I think it makes more sense for the individual token fields to just say "MUST have 128 bits", and explain why in one place in the Security Considerations section.
NAME NAME Updated. Thanks for the feedback!
Change:
hash is referred to as the authenticator hash. To avoid key synchronization attacks, Exported Authenticators MUST <del> NOT be generated or accepted on TLS 1.2 connectons that did not </del> <ins> NOT be generated or accepted on TLS 1.2 connections that did not </ins> negotiate the extended master secret RFC7627. 5.2. An authenticator is formed from the concatenation of TLS 1.3 TLS13 <del> Certificate, CertificateVerify, and Finished messages. </del> <ins> Certificate, CertificateVerify, and Finished messages.  These messages are encoded as TLS handshake messages, including length and type fields. </ins> If the peer creating the certificate_request_context has already created or correctly validated an authenticator with the same value,

Discussion:
Proposal to fix Issue
cc NAME
The Introduction limits this to TLS 1.2 and later, but DTLS is similar. Do you want to take that into account now, or ignore it? DTLS has additional fields to support fragmentation: URL URL
Exported authentication are meant to be embedded in a higher-layer protocol, so there's no need to support fragmentation.
The draft states that there should be no "TLS framing" but what is meant is that the handshake messages shouldn't be encapsulated by TLS Record Framing (which does the encryption of the handshake messages).
Change:
packets, and the more out-of-order the packets are, the more important it is to send an updated ACK frame quickly, to prevent the peer from declaring a packet as lost and spuriously retransmitting <del> the frames it contains. </del> <ins> the frames it contains.  An ACK frame is expected to fit within a single QUIC packet.  If it does not, then older ranges (those with the smallest packet numbers) are omitted. </ins> ack-tracking and ack-limiting describe an exemplary approach for determining what packets to acknowledge in each ACK frame.

Discussion:
If so, don't serialize the oldest ranges, as previously specified.
This isn't the right section; Section 13.2.4 already has context for this. I'll make a small PR.
NAME In terms of which is the right section, I'll explain my thinking. In my mind, I think of the subsequent two sections as examples of how one could limit ACK frame size, but not really required reading, because I think that's how they were originally written? However, there's quite a bit of normative text in there, so maybe I have an obsolete mental model. An easy alternative to doing what's in those sections is to set a max number of ACK ranges(ie: 3), which I think should be considered acceptable, even if it might not be optimal.
Let's land this and handle any redundancies in an editorial pass along with .
In trying to do a simple fix for , I found other irrelevant or poorly-written recommendations in how a receiver could limit ACK ranges it sends. This section needs to be rewritten. Specifically, the sentence below is a poor recommendation and contradicts earlier recommendation on acking until the ACK frame is acknowledged. The recommendation below is fine, but the rationale does not make sense: This should be a design change.
I'm not in love with this (entire) section either, but I'd like to better understand this issue. I agree that sentence is mis-written, though I think the intent was fine. On the rationale, can you clarify why it does not make sense?
The of the Transport Draft should explain what to do when generated ACK is too large to fit in a packet: Generate a shorter ACK frame (instead of aborting connection or erroring out). To generate the shorter frame, don't include older (smaller) packet numbers. (As opposed to not including newer packet numbers.)
There is a good amount of existing text about what ranges to send, ie "ACK frames SHOULD always acknowledge the most recently received packets," I think this can be solved with some editorial additions to 13.2.2. URL
The text we already have in 13.2.4 has the right context:
Ok, this became a bigger fix. See and .
Seems fine.A few suggestions
Change:
All other DCIDs are routable. Load balancers MUST forward packets with routable DCIDs to a server <del> in accordance with the chosen routing algorithm. </del> <ins> in accordance with the chosen routing algorithm.  Exception: if the load balancer can parse the QUIC packet and makes a routing decision depending on the contents (e.g., the SNI in a TLS client hello), it MAY route in accordance with this instead.  However, load balancers MUST always route long header packets it cannot parse in accordance with the DCID (see version-invariance). </ins> Load balancers SHOULD drop short header packets with unroutable DCIDs.

Discussion:
Upon further consideration, any TP to provide CIDs for future connections should be in a different document.
LBs that are doing SNI routing are a special case. (1) If the Initial CID is routable, they can't just take that as good; they have to assume that it was random and inspect the SNI to make a decision. Section 4.1 doesn't allow this, and it should. (2) that mode doesn't work for unknown QUIC versions, obviously. (3) For QUIC versions the SNI-LB doesn't understand, I think this is the best we can do: a) For QUIC versions it understands, the LB MAY find the SNI. It MAY use the SNI for unroutable CIDs. If a routable CID, it may override the encoded SID if that SID does not correspond to the provided SNI. b) The QUIC-LB config explicitly states that the LB is doing SNI routing and the versions it supports c) The server MAY send a TP that means "next time you connect with me, please use one of the connection IDs I provided in a NEWCONNECTIONID frame." This may also be useful for some persistence use cases. The worst case is an unsupported version with a randomly generated CID. In this case, the LB will spray it and will only get lucky if it happens to get to the right tenant. Sec 11.4 may also need a revision here. Or maybe SNI routing is just incompatible with version-independent QUIC-LB?
The down side of just saying "don't do that' is that then SNI Load balancing can't work with version aliasing, which would be sad because VA helps hide the SNI.
Maybe specify a unique quic transport param is a better choice? For a web service, all requests just have same SNI, help nothing for distinguishing the Initial CID
Further more, there is a draft about encrypted client hello(URL)if it becomes RFC, maybe LB cannot get information about clientHello or there must be some ways to synchronize the server private-key to LB
synchronizing the server private-key is exactly what happens; that is what the "client-facing server" is in that draft.
I'm not sure what you're proposing here.

My hope is not introduce a regression relative to current capabilities, but it sounds like you're talking about an L7 load balancer that's doing deep packet inspection. If so, that's out of scope for this document.
OK, I got it
Change:
13.1.8. Add and Remove proposals can be constructed and sent to the group by <del> a party that is outside the group, indicated by an "external" SenderType.  This is useful in cases where, for example, an automated service might propose to remove a member of a group who has been inactive for a long time, or propose adding a newly-hired staff </del> <ins> a party that is outside the group in two cases.  One case, indicated by an "external" SenderType is useful in cases where, for example, an automated service might propose to remove a member of a group who has been inactive for a long time, or propose adding a newly-hired staff </ins> member to a group representing a real-world team. ReInit proposals can also be sent to the group by an "external"

Discussion:
Add new newproposalmember SenderType and rename newmember to newcommit_member. This restores the External Proposal Add functionality which was present in the protocol for some years but clarifies how the authorization and signing takes place in this case.
Interim 2022-06-02: Could punt to extensions, but this is partly just because we moved a little too fast on the removal No objections to reverting Once conflicts and comments resolved, good to merge
LGTM, though would still prefer etc. One minor suggestion to lock down the content.
Change:
used RST injection to interrupt BitTorrent Traffic Winter-2012.  In 2020, Iran deployed an allowlist protocol filter, which only allowed three protocols to be used (DNS, TLS, and HTTP) on specific ports and <del> censored any connection it could not identify Bock-2020. </del> <ins> censored any connection it could not identify Bock-2020.  In 2022, Russia seemed to have used protocol identification to block most HTTP/3 connections Elmenhorst-2022. </ins> 4.4.

Discussion:
This pull request adds findings about QUIC censorship. The changes are the following: References to my 2021 paper and 2022 OTF blog post on QUIC and HTTP/3 censorship. Details about QUIC's initial encryption of the ClientHello with a non-secret key. This initial encryption differs from traditional TLS over TCP. Requirements for the censor to apply Deep Packet Inspection to QUIC packets. Case of SNI blocking of QUIC traffic in Russia. Shallow packet inspection of QUIC traffic: IP blocking, UDP endpoint blocking, protocol blocking. Packet dropping as only observed interference method. Considerations on packet injection and connection reset in the context of QUIC.
Change:
7.2. <del> This section shows a typical example of a session between two JSEP endpoints setting up an audio channel and a data channel.  Trickle ICE is used in full trickle mode with a bundle policy of max-bundle, an RTCP mux policy of require, and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </del> <ins> This section shows a more involved example of a session between two JSEP endpoints.  Trickle ICE is used in full trickle mode, with a bundle policy of "max-bundle", an RTCP mux policy of "require", and a single TURN server.  Initially, both Alice and Bob establish an audio channel and a data channel.  Later, Bob adds two video flows, one for his video feed, and one for screensharing, both supporting FEC, and with the video feed configured for simulcast.  Alice accepts these video flows, but does not add video flows of her own, so they are handled as recvonly.  Alice also specifies a maximum video decoder resolution. </ins> The SDP for |offer-B1| looks like: <del> The SDP for |offer-B1-candidate-1| looks like: </del> <ins> |offer-B1-candidate-1| looks like: </ins> <del> The SDP for |offer-B1-candidate-2| looks like: </del> <ins> |offer-B1-candidate-2| looks like: </ins> <del> The SDP for |offer-B1-candidate-3| looks like: </del> <ins> |offer-B1-candidate-3| looks like: </ins> The SDP for |answer-B1| looks like: <del> The SDP for |answer-B1-candidate-1| looks like: </del> <ins> |answer-B1-candidate-1| looks like: </ins> <del> The SDP for |answer-B1-candidate-2| looks like: </del> <ins> |answer-B1-candidate-2| looks like: </ins> <del> The SDP for |answer-B1-candidate-3| looks like: </del> <ins> |answer-B1-candidate-3| looks like: </ins> <del> The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate the local candidate that was selected) </del> <ins> The SDP for |offer-B2| is shown below.  In addition to the new m= sections for video, both of which are offering FEC, and one of which is offering simulcast, note the increment of the version number in the o= line, changes to the c= line, indicating the local candidate that was selected, and the inclusion of gathered candidates as a=candidate lines. </ins> <del> The SDP for |answer-B2| looks like: (note the use of setup:passive to maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) </del> <ins> The SDP for |answer-B2| is shown below.  In addition to the acceptance of the video m= sections, the use of a=recvonly to indicate one-way video, and the use of a=imageattr to limit the received resolution, note the use of setup:passive to maintain the existing DTLS roles. </ins> 8.

Discussion:
a=simulcast, a=rid a=imageattr (maybe) differing codecs/preferences for either side
I started on this; should be straightforward
Change:
address other than the one initially used, it is necessary to set the "advertisesAltaddr" property (see altaddr below). <del> Setting this property to "Active", can have privacy implications: It </del> <ins> Setting this property to "Active" can have privacy implications: It </ins> enables the transport to establish connectivity using alternate paths that might result in users being linkable across the multiple paths, even if the "advertisesAltaddr" property (see altaddr below) is set

Discussion:
Review the use of and markdown in the API document, and make it consistent.
A fantastic PR! The best ever!
Change:
[RFCthis] <ins> 10.9. IANA is requested to add [RFCthis] to the references for the following entries registered by RFC7959 in the "CoAP Option Numbers" sub-registry defined by RFC7252: </ins> 11.  References 11.1.  URIs

Discussion:
Add to Updates Updated Abstract Added IANA section to update related references for Block1 and Block2
: 3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc. My sense is that we should treat this as an update to RFC7959 based on the original language: and the use of "extension" in coap-tcp-tls: This also requires an IANA addition, since the entries for Block1 and Block2 need to also reference coap-tcp-tls in addition to RFC7959.
Change:
contains the x coordinate for the EC point.  The integer is converted to an octet string as defined in SEC1.  Zero octets MUST <del> NOT be removed from the front of the octet string.  [CREF15] </del> <ins> NOT be removed from the front of the octet string.  [CREF13] </ins> contains either the sign bit or the value of y coordinate for the EC point.  For the value, the integer is converted to an octet

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.
Change:
Endpoint type (optional).  Used for group, endpoint and resource lookups. <del> Link attribute parameters (optional).  Any link target attribute as defined in Section 4.1 of RFC6690, used for resource lookups. </del> <ins> Link parameters (optional).  Any link parameter as defined in Section 4.1 of RFC6690, including href, used for resource lookups. </ins> application/link-format (optional)

Discussion:
I think that rt is not an attribute of a registration; the first commit reflects that. (The second is more bycatch from that). Possibly we can simplify the whole section; as everything in the result is links, we're only applying the same link filtering that 6690 already specifies (plus pagination).
Absolutely right. After all commits by Christian, I will look at these examples again together with discovery text and other details. cabo schreef op 2017-10-19 16:57:
Change:
5. <ins> Given the desired security goals from TODO, applications which make use of external PSKs MUST adhere to the following requirements: 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 server MUST use distinct PSKs when acting as the client from when it is acting as the server. Nodes SHOULD use external PSK importers I-D.ietf-tls-external-psk- importer when configuring PSKs for individual TLS connections. Each PSK MUST be at least 128-bits long. </ins> 6. <del> TODO </del> <ins> PSK privacy properties are orthogonal to security properties described in sec-properties.  Traditionally, TLS does little to keep PSK identity information private.  For example, an adversary learns information about the external PSK or its identifier by virtue of it appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when using external PSKs if these risks. In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can link successive connections that use the same external PSK together. Preventing this type of linkability is out of scope, as PSKs are explicitly designed to support mutual authentication. </ins> 7. <del> TODO </del> <ins> This document makes no IANA requests. </ins>

Discussion:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .
Change:
As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA <del> records, at its discretion.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS. </del> <ins> records.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non- intuitive manner, the challenge must be completed over HTTP, not HTTPS. </ins> The string "http-01"

Discussion:
This looks fine to me, and consistent with the list discussions. (I have a couple of minor issues, which I filed as .) I am merging this in preference to , which got negative feedback on the list.
The format should be specified more clearly, by reference to a couple of RFCs The "peer" provision seems kind of awkward. For server implementations where the validation is done by a separate entity than the ACME interactions (like ), this means that the challenge no longer has all the information that the validation agent needs to do the validation. I'm inclined to drop it and put the burden on the client.