jiebi/CodeConvo huggingface dataset:
Change:
4.7. <del> [EDITOR'S NOTE: this is a bit speculative; keep?] QUIC does not provide any additional information on requirements on Quality of Service (QoS) provided from the network.  QUIC assumes that all packets with the same 5-tuple {dest addr, source addr, protocol, dest port, source port} will receive similar network treatment.  That means all streams that are multiplexed over the same QUIC connection require the same network treatment and are handled by the same congestion controller.  If differential network treatment is desired, multiple QUIC connections to the same server might be used, given that establishing a new connection using 0-RTT support is cheap and fast. QoS mechanisms in the network could also use the connection ID for service differentiation, as a change of connection ID is bound to a change of address which anyway is likely to lead to a re-route on a different path with different network characteristics. Given that QUIC is more tolerant of packet re-ordering than TCP (see packetnumber), Equal-cost multi-path routing (ECMP) does not necessarily need to be flow based.  However, 5-tuple (plus eventually connection ID if present) matching is still beneficial for QoS given all packets are handled by the same congestion controller. </del> <ins> It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not per-packet) and as such that all packets belonging to the same QUIC connection get uniform treatment.  Using ECMP to distribute packets from a single flow across multiple network paths or any other non- uniform treatment of packets belong to the same connection could result in variations in order, delivery rate, and drop rate.  As feedback about loss or delay of each packet is used as input to the congestion controller, these variations could adversely affect performance. Depending of the loss recovery mechanism implemented, QUIC may be more tolerant of packet re-ordering than traditional TCP traffic (see packetnumber).  However, it cannot be known by the network which exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. </ins> 5.

Discussion:
(hopefully)
okay, next try. Moved some text to applicability and rewrote stuff in manageability... please review again...
Discussion in closed PR
Change:
Moreover, implementers of this specification need to be aware that if other authentication mechanisms are used to set up OSCORE between the same client and RS, that do not rely on AS assigning identifiers, <del> collisions may happen and need to be mitigated. </del> <ins> collisions may happen and need to be mitigated.  A mitigation example would be to use distinct namespaces of identifiers for different authentication mechanisms. </ins> Note that in oscore-setup C sets the Sender ID of its Security Context to the clientId value received and the Recipient ID to the

Discussion:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)
Change:
Update the leaf at index "index" with the private key corresponding to the public key in the node. <ins> If the "path_secret" value is set in the GroupSecrets object: </ins> Identify the lowest common ancestor of the leaves at "index" and at "GroupInfo.signer_index".  Set the private key for this <del> node to the private key derived from the "path_secret" in the GroupSecrets object. </del> <ins> node to the private key derived from the "path_secret". </ins> For each parent of the common ancestor, up to the root of the tree, derive a new path secret and set the private key for the

Discussion:
When we converted to the Proposal/Commit scheme, one of the consequences was that Adds became O(N) instead of O(1), since they had to Committed and commits encrypt the committer's direct path to the remainder of the tree. This is ~log(N) in the nice case and ~N in the worst case. At the time, we noted that one could special-case Add-only Commits in the future and make the update to the direct path optional in that case. This PR implements that suggestion. The leaf KeyPackage for the Commit is moved into the DirectPath struct, and the whole DirectPath is made optional. The optional value MUST be provided for: A Commit committing an update or remove A "just update my path" Commit covering no proposals
So we do go forward one epoch, but with an all-zero commit secret. Do I understand that correctly?
NAME That's correct. The idea is that you don't need to send the current group any additional entropy, you just need them to hash forward. Note that this could change the FS/PCS guarantees available. But I don't think we ever proposed that Add would cause any FS/PCS changes to the group, so maybe this doesn't matter.
Add should give FS guarantees in so far as that the new member shouldn't be able to decrypt old messages or derive old keys. But I think ratcheting forward should do the trick. We should note, though, that this breaks the (implicit) assumption that a commit always introduces fresh key material to the group. As far as I can see, that's not breaking anything right now, but we should keep it in mind.
Note: The latest commit fixes a gap that was discovered in .
See the flexibility question.
Change:
an entity applying for a certificate with a given identifier actually controls that identifier. <del> Challenges provide the server with assurance the an account key </del> <ins> Challenges provide the server with assurance that an account key </ins> holder is also the entity that controls an identifier.  For each type of challenge, it must be the case that in order for an entity to successfully complete the challenge the entity must both:

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
connection should fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <ins> Further QUIC-HTTP provides security considerations specific to HTTP. However, discussions such as on cross protocol attacks, traffic analysis and padding, or migration might be relevant for other applications using QUIC as well. </ins> 14. This work is partially supported by the European Commission under

Discussion:
to the security considerations section?
Cross protocol attacks, traffic analysis, and migration are discussed as well in the transport draft, so this pointer might not be absolutely necessary. However, we might still want to have it and then I think these are the relevant sections to refer to.
Applicability to me seems to be mostly targeted to non-H3 users of QUIC, so I'm not sure the H3-specific considerations need to be mentioned here.
My thinking was to add that as reference for other applications that might need to consider similar attacks/security issues. At least half of the points in the hhtp/3 sec considerations are really http specific and probably don't have value for other applications but there are a number of points which are more general. Those points are to some extend probably also covered by the transport draft but may be explained in more detail in the h3 draft.
Change:
possession for the associated private key that was used when creating the push subscription. <del> A push service MUST reject a message that omits mandatory credentials with a 401 (Unauthorized) status code.  A push service MAY reject a message that includes invalid credentials with a 403 (Forbidden) status code.  Credentials are invalid if: </del> <ins> A push service MUST reject a message sent to a restricted push subscription if that message includes no "vapid" authentication or invalid "vapid" authentication.  A 401 (Unauthorized) status code might be used if the authentication is absent; a 403 (Forbidden) status code might be used if authentication is invalid. "vapid" authentication is invalid if: </ins> either the authentication token or public key are not included in the request,

Discussion:
This looks a lot worse than it really is. Reflowing text causes massive diffs, which github somehow manages to make look like entirely new text.
Change:
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode.  This highly restricts what the user can do <del> until the user has satified the Captive Portal conditions. </del> <ins> until the user has satisfied the captive portal conditions. </ins> This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some <del> sort of captive-portal enforcement device, and that they will need to </del> <ins> sort of captive portal enforcement device, and that they will need to </ins> satify the Captive Portal conditions to get Internet access.  It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a

Discussion:
2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...) [Gahforthe_hyphens a87eb8d] 2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...)
Change:
Listen: The action of marking a Listener as willing to accept incoming Connections.  The Listener will then create Connection <del> objects as incoming connections are accepted (events). </del> <ins> objects as incoming connections are accepted (events).  Listeners by default register with multiple paths and local endpoints, unless constrained by Selection Properties.  Connections can be accepted on any of the available paths or endpoints. </ins> Rendezvous: The action of establishing a peer-to-peer connection with a Remote Endpoint.  It simultaneously attempts to initiate a

Discussion:
Address
meh okay if we must. :P nah this is great, already merged it.Fine - works
Change:
necessary to prevent downgrade attacks.  [[OPEN ISSUE: We looked at ignoring the extension but concluded this was better.]] <del> If more than one KeyShareEntry has been provided, or if that share's group does not match that for the SNI encryption key, it MUST abort the connection with an "illegal_parameter" alert. </del> <ins> If the EncryptedSNI.key_share group does not match one in the ESNIKeys.keys, it MUST abort the connection with an "illegal_parameter" alert. </ins> If the length of the "encrypted_server_name" extension is inconsistent with the advertised padding length (plus AEAD

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.
Change:
The client MUST continue to use the previously-advertised configurations for subsequent connections.  This avoids introducing pinning concerns or a tracking vector, should a malicious server <del> present client-specific retry keys in order to identify the client in a subsequent ECH handshake. </del> <ins> present client-specific retry configurations in order to identify the client in a subsequent ECH handshake. </ins> If none of the values provided in "retry_configs" contains a supported version, the client can regard ECH as securely disabled by

Discussion:
The reference to "retry keys" comes from when the field was called retrykeys and the type ESNIKeys. We've since renamed them to retryconfig and ECHConfig, so the prose should match.
Change:
header fields or capsules to register contexts.  Depending on the method being used, it is possible for datagrams to be received with Context IDs which have not yet been registered, for instance due to <del> reordering of the datagram and the registration packets during transmission. </del> <ins> reordering of the packet containing the datagram and the packet containing the registration message during transmission. </ins> 5.

Discussion:
There's a danger people read too much into "datagram packets" or "registration packets". I think it would be clearer to say something like "due to reordering of packets that contain datagrams or registration messages"
Change:
victim's .well-known/core content in the RD.  Mitigation for this is recommended in simple. <ins> The Registration Resource path is visible to any client that is allowed endpoint lookup, and can be extracted by resource lookup clients as well.  The same goes for registration attributes that are shown as target attributes or lookup attributes.  The RD needs to consider this in the choice of Registration Resource paths, and administrators or endpoint in their choice of attributes. </ins> 8.3. Access control SHOULD be performed separately for the RD registration

Discussion:
This is a result of the discussion following Roman's "> But why expose them at all if they're not going to be accessible?" comment.
Change:
the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state. <del> The implementation reads a ACK from the peer: upon receiving an </del> <ins> The implementation reads an ACK from the peer: upon receiving an </ins> ACK for a partial flight (as mentioned in sending-acks), the implementation transitions to the SENDING state, where it retransmits the unacked portion of the flight, resets the

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
A Retry packet (shown in retry-format) does not contain any protected fields.  The value in the Unused field is selected randomly by the <del> server.  In addition to the long header, it contains these additional fields: </del> <ins> server.  In addition to the fields from the long header, it contains these additional fields: </ins> An opaque token that the server can use to validate the client's address.

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.
Change:
The "tree_hash" is updated to represent the current tree and credentials <del> The "transcript_hash" is updated with the data for an MLSPlaintext message encoding a group operation in two parts: </del> <ins> The "confirmed_transcript_hash" is updated with the data for an MLSPlaintext message encoding a group operation in two parts: </ins> This structure incorporates everything in an MLSPlaintext up to the confirmation field in the transcript that is included in that confirmation field (via the GroupContext).  The confirmation and signature fields are then included in the transcript for the next <del> operation.  The intermediate hash enables implementations to in corporate a plaintext into the transcript without having to store the </del> <ins> operation.  The interim transcript hash is passed to new members in the WelcomeInfo struct, and enables existing members to incorporate a handshake message into the transcript without having to store the </ins> whole MLSPlaintextOpAuthData structure. When a new one-member group is created (which requires no <del> GroupOperation), the "transcript_hash" field is set to an all-zero vector of length Hash.length, where the Hash algorithm is defined by the ciphersuite. </del> <ins> GroupOperation), the "interim_transcript_hash" field is set to the zero-length octet string. </ins> 6.5.

Discussion:
While trying to implement , I noticed that the confirmation and transcript hash calculations in draft-06 do not actually allow a new participant to join the transcript hash. Since the value is sent, and not the value, the new joiner is missing the auth data necessary to compute the next value. To fix this and clarify terminology, this PR makes the following changes: becomes , since this is what goes into the confirmation MAC becomes is updated to refer to the
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 1 issues have been closed and 1 issues are still open. :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 2 pull requests were created, updated or merged. Last week, 1 pull request was updated. :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
This looks ok. If we want, merging and messages like in the TreeKEM paper would probably avoid some pain here. Merging.
Change:
result.  Received data is decrypted and verified, reassembled, and then delivered to higher-level clients. <del> Four protocols that use the record protocol are described in this </del> <ins> Three protocols that use the record protocol are described in this </ins> document: the handshake protocol, the alert protocol, and the application data protocol.  In order to allow extension of the TLS protocol, additional record content types can be supported by the

Discussion:
Four instead of three ? (hs, alert, app_data) Allusion to CCS ... ? Cheers, B.
Change:
The key and nonce used for the encryption of the message depend on the content type of the message.  The sender chooses the handshake <del> key for a handshake message or an ununsed generation from its (per- </del> <ins> key for a handshake message or an unused generation from its (per- </ins> sender) application key chain for the current epoch, according to the type of message being encrypted.

Discussion:
Yeah, I noticed that too as I was implementing. I will fix it in a “reconciliation with implementation” PR I’m working on.
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments.

- - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .