jiebi/CodeConvo huggingface dataset:
Change:
removes it from the candidate report set and does not process it further. <del> If the type is "finished", then the leader aborts with "unrecognizedMessage".  If the type is "continued", then the leader </del> <ins> If the type is "finished" and the Leader's preparation of this report share is also finished, then the report share is aggregated and can now be collected (see collect-flow).  If the Leader is not finished, then the report cannot be processed further and MUST be removed from the candidate set. If the Helper's "PrepareStep" is of type "continued", then the Leader </ins> proceeds as follows. Let "leader_outbound" denote the leader's prepare message and

Discussion:
This PR includes several text cleanups previously folded into : The upload section explicitly describes the call to An obsolete TODO in the aggregation section is removed Text that incorrectly instructed leaders to abort if the helper finishes aggregation is corrected.
Change:
device which has voluntarily joined a network for purposes of communicating beyond the constraints of the captive network. <del> Captive Portal Server: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. </del> <ins> User Portal: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. </ins> Captive Portal API: Also known as API.  An HTTP API allowing User Equipment to query its state of captivity within the Captive Portal.

Discussion:
To replace "web-portal" and "Captive Portal Server" Address issue
Note: this actually fixed
Sorry, don't know where I got 45 from
Some reviewers have found "Captive Portal Server" to be confusing when read alongside "Captive Portal API Server". Let's change it to something a bit more distinct. Tommy Pauly has suggested "user portal", which seems reasonable. While we're in there, make sure we're consistent with this use. It was also pointed out that we used "web portal" in quite a few places (e.g. sec 2.6, section 4).
A reasonable URL
Change:
header fields are defined in Section 8.1.2.3 and 8.1.2.4 of HTTP2. Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in HTTP2.  The <del> restrictions on the use of pseudo-header fields in Section 8.1.2.1 of HTTP2 also apply to HTTP/3. </del> <ins> restrictions on the use of pseudo-header fields in Section 8.1.2 of HTTP2 also apply to HTTP/3.  Messages which are considered malformed under these restrictions are handled as described in malformed. </ins> HTTP/3 uses QPACK header compression as described in QPACK, a variation of HPACK which allows the flexibility to avoid header-

Discussion:
The constraints of 8.1.2.1 apply to all requests, but I missed that there are additional requirements in 8.1.2.3 for requests and 8.1.2.4 for responses. I've broadened the statement to "the restrictions on the use of pseudo-headers in Section 8.1.2" to sweep them all up. Does anyone think we need pointers to each specific subsection? At Lucas's suggestion, I've also cross-referenced handling of malformed messages here, since those restrictions talk about what is malformed in a given context.
I'm carefully parsing the wording in quic-http sec. 4.1.1 and don't think it's right: In RFC 7540, 8.1.2.1 says This notably does NOT include the further restrictions in 8.1.2.3: I am far from an expert on HTTP headers, but I suspect it's not right that clients could send quantities of :method, :scheme, and :path other than 1. We should probably fix the section reference, though I haven't reviewed 8.1.2 carefully enough to know exactly how that should read.
Good point.
The cited HTTP/2 sections mention malformed requests and response, so we probably also want to add some text to the H3 spec that links to it's section 4.1.3 on how to deal with these.
Change:
Normally, clients will open streams sequentially, as explained in stream-id.  However, when several streams are initiated at short <del> intervals, transmission error may cause STREAM DATA frames opening streams to be received out of sequence.  A receiver is obligated to open intervening streams if a higher-numbered stream ID is received. Thus, on a new connection, opening stream 2000001 opens 1 million streams, as required by the specification. </del> <ins> intervals, loss or reordering may cause STREAM frames that open streams to be received out of sequence.  On receiving a higher- numbered stream ID, a receiver is required to open all intervening streams of the same type (see stream-recv-states).  Thus, on a new connection, opening stream 4000000 opens 1 million and 1 client- initiated bidirectional streams. </ins> The number of active streams is limited by the initial_max_streams_bidi and initial_max_streams_uni transport

Discussion:
The Stream Commitment Attack part was added in draft-ietf-quic-transport-03, when unidirectional streams were not used. In draft-ietf-quic-transport-08, streams were split into unidirectional and bidirectional, but this example of stream commitment attack was missed.
Thanks, NAME I've done some editorializing, and merging.
Change:
enc contains the encapsulated key as output by SetupBaseS; and <del> encrypted_ch contains the HPKE encapsulated key (enc) and the ClientHelloInner ciphertext (encrypted_ch_inner). </del> <ins> encrypted_ch contains the AEAD-encrypted ClientHelloInner. </ins> The client MUST place the value of "ECHConfig.public_name" in the ClientHelloOuter "server_name" extension.  See outer-clienthello for

Discussion:
While reading the draft, I'm confused with ClientEncryptedCH structure. Section : The "encryptedclienthello" extension says... ~ >enc : The HPKE encapsulated key, used by servers to decrypt the corresponding field. >encryptedch : The serialized and encrypted ClientHelloInner structure, encrypted using HPKE as described in {{send-ech}}. and Section : Sending an encrypted ClientHello says... >The encrypted ClientHello value is then computed as: ~ Cause output of the context.Seal() function is ciphertext output of AEAD encryption (According to draft-irtf-cfrg-hpke-05), I think encryptedch has only ciphertext value of the ClientHelloInner, not the enc value. But the same section also says... >encryptedch contains the HPKE encapsulated key (enc) and the ClientHelloInner ciphertext (encryptedchinner). Q. Does encryptedch have enc and encryptedchinner? Or it just has the ciphertext of ClientHelloInner and encryptedch_inner is just mistype?
Nice catch! should just be the AEAD ciphertext. The following text is wrong: ciphertext (encryptedch_inner). It should be: cc/ NAME
OK, there's no .. thanks!
Change:
If the signature fails to verify, discard the updated GroupState object and consider the Handshake message invalid. <del> If the signature verifies successfully, consider the updated </del> <ins> Use the "confirmation_key" for the new group state to compute the finished MAC for this message, as described below, and verify that it is the same as the "finished_mac" field. If the the above checks are successful, consider the updated </ins> GroupState object as the current state of the group. <ins> The "finished_mac" value is computed over the provisional group state and the current handshake message (with the confirmation value set to zero): HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. </ins> [[ OPEN ISSUE: The Add and Remove operations create a "double-join" situation, where a participants leaf key is also known to another participant.  When a participant A is double-joined to another B,

Discussion:
At the MLS interim, the major feedback regarding authentication was that it would be good practice to provide explicit key confirmation. This PR adds an explicit confirmation field to Handshake messages, containing a MAC over the proposed (updated) state of the group, together with the latest handshake message.
Reflecting on offline conversation here: This PR derives a new key, then calculates the MAC over both the HS message and the group state; that others verify. PR 72 derives a new key, then sends that to the others to verify they all got the same key. We assume that, as the key was derived from a tree with this group state, it must be correct. These appear to test basically the same property, but I probably prefer this PR unless we can formally verify that they have the same properties (or at least the relevant ones); in which case 72 is a little more efficient.
So one question would be under what circumstances would this verify something that won't be verified by failing AEAD on any associated messages that decrypt? Or is it more just that we've now decoupled updates and message sending, so without a failing AEAD we need this to confirm too?
Thanks, NAME Absolutely agree that this needs more discussion. I'll send a ping on the list shortly.
NAME To answer your question, yes, the idea here is to fail before you get to the AEAD stage. In the spec before this PR merged, group members that arrived at different states would have different keys, but they would never find out that was the case until there was an AEAD failure. With this PR (or ), a peer know that if processing of a Handshake message succeeds, then it has the same GroupState as the sender.
Agreed that we need further discussion with academics, and modelling of the properties, but this seems good to provisionally merge.
Change:
Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not <del> necessary for security with Curve25519. </del> <ins> necessary for security with X25519. </ins> 6.

Discussion:
Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec
Change:
This is explicitly defined as the signature algorithm specified by the associated key material and the content digest is calculated <del> using sha-512. </del> <ins> using sha-256. </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would

Discussion:
To edit notification comments on pull requests, go to your .
Nothing more than yaron's feedback
From IETF115 comments: Change the default hash for interaction_hash to sha256, and change the MTI profile to use the same.
Please search for some remaining occurrences of "sha-512".
Change:
MLS Credential Types (mls-credential-types) <ins> MLS Signature Labels (mls-signature-labels) MLS Exporter Labels (mls-exporter-labels) </ins> All of these registries should be under a heading of "Messaging Layer Security", and assignments are made via the Specification Required policy RFC8126.  See de for additional information about the MLS

Discussion:
Also copies the "Recommended" field by reference, instead of reciting it in each registry. Note that this has a conflict with that will not catch -- "MLSContentTBS" will have to be changed to whatever new name is agreed in that PR.
The of absolutely needs to be unique for every signature happening in the protocol, for security and avoid signature ambiguity. That includes signatures happening in extensions. Should this be referenced in a IANA considerations to ensure there is no conflict in the future? Or at least say something about this somewhere? We have to think how to design things well here to be future-proof: the structure must be used for every signature done with the leaf signature keys, which includes what might happen in extensions but also in future versions of MLS. If future versions of MLS could avoid doing , that would be great!
This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS (otherwise there's no risk of confusion) and if so, whether this spec has any influence on that usage. If you're using your MLS key to sign Bitcoin transactions, we can't do much to help that. Note that there is not an issue for future version of MLS here. The label is constructed as , so a future version could just increment the part of that. Given all that, I might prefer a recommendation that signature keys not be reused across contexts, rather than trying to accommodate reuse. If we do something here, we should do something analogous to the registry, which are similarly intended for domain separation between different use cases. We should probably consider making an exporter label registry anyway.
I agree, we shouldn't do anything about someone using the MLS signature key in another protocol. About future MLS versions: I agree, but note that there is a length tag before that. It means that we impose to all signature of future MLS versions to start with (including the quic integer) Is it something acceptable or not, I don't now. I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions. About extensions: in the extensions document, there is a signature computed with If two extensions were to use the same label then this could lead to security problems, this is why I think the labels should be in some registry to ensure they are all unique.

One other thing we could do is to separate all extensions signatures from the core MLS signatures, for exemple using the label "MLS 1.0 extension [label from extension]"? Like that a bogus extension can't introduce a security flaw in core MLS that way?
Change:
challenges with some non-zero probability.  Likewise, origins SHOULD randomly choose to not challenge clients for tokens with some non- zero probability.  Moreover, origins SHOULD include random token <del> types in token challenges with some non-zero probability. </del> <ins> types, from the Reserved list of "greased" types (defined in token- types), with some non-zero probability. </ins> 4.

Discussion:
The spec recommends some greasing in Section 3 In section 5.2, several token types are reserved as greased values. Is the expectation really that origins pick "random" token types, or with non-zero global probability across clients, randomly pick from the set of reserved token types?
This should probably read from the list of reserved GREASE values, rather than random token types (the latter can cause interop issues).
Yeah, that sounds good,
Change:
draft-10 <ins> Allow new members to join via an external Commit (*) Enable proposals to be sent inline in a Commit (*) </ins> Re-enable constant-time Add (*) <ins> Change expiration extension to lifetime extension (*) Make the tree in the Welcome optional (*) PSK injection, re-init, sub-group branching (*) Require the initial init_secret to be a random value (*) Remove explicit sender data nonce (*) Do not encrypt to joiners in UpdatePath generation (*) Move MLSPlaintext signature under the confirmation tag (*) Explicitly authenticate group membership with MLSPLaintext (*) Clarify X509Credential structure (*) Remove uneeded interim transcript hash from GroupInfo (*) IANA considerations Derive an authentication secret Use Extract/Expand from HPKE KDF Clarify that application messages MUST be encrypted </ins> draft-09 Remove blanking of nodes on Add (*)

Discussion:
We have a changelog for the document by I-D release, but haven't been updating it as we go. This PR updates the changelog based on merged PRs and the few we expect to close before releasing draft-10. Marking this as draft right now, until the other PRs have merged.
Change:
the contents of the SVCB SvcParams.  This document provides the mapping for the "dns" service type, allowing DNS servers to offer alternative endpoints and transports, including encrypted transports <del> like DNS over TLS and DNS over HTTPS. </del> <ins> like DNS over TLS (DoT) and DNS over HTTPS (DoH). </ins> 2.

Discussion:
This wording avoids the complexity of a URI construction algorithm and is more direct and compact.
The DoH URI Template algorithm currently works like so: where $DOHPATH is "a URI Template ] encoded in UTF-8 ]." This seems not restrictive enough. For example, a valid $DOHPATH template could be "URL{?dns}," and following the algorithm above would yield "URL{?dns}," which obviously seems like not the intended result. There's text that says "The "dohpath" value MUST be chosen such that the resulting URI Template is valid for use with DNS over HTTPS," but note that the algorithm above is presented with the word MAY which, to me, implies that clients could construct the URI Template some other way. Unless there's a good reason to do so, we should be more restrictive with what $DOHPATH contains (it might be just a path component of a URI Template, or something), and how clients construct the Template.
Yes. Surely this normatively constrains the value in the way you're asking? Yes. People don't like it when you normatively require implementation of a specific algorithm, because it artificially constrains implementation. In this case, for example, a client could choose to omit the port number when it is unspecified, instead of setting it explicitly to 443. This would undeniably result in a different DoH URI Template, although the resulting calculated URIs for each request would be equivalent in some sense. A client could even skip computation of the full URI template, and instead perform substitution for each request directly on the string, plugging and and the path into their HTTP client library without ever constructing a URI.
Maybe it would be better to say that is a URI template that expands to the for each HTTP request, and remove the discussion about forming a full URL?
Change:
Strategies for sequencing messages in CP and AP systems are described in the next two subsections. <del> However, note that a Delivery Service could also reorder messages or provide an inconsistent view to different users not just accidentally, but maliciously.  The protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </del> <ins> However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </ins> Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply

Discussion:
This PR pulls in the CAP theorem-related discussion from URL which is a more helpful way to frame DS design.
Change:
address, it ought to provide an A record for an IPv4 address of the Designated Resolver; similarly, if it is accessible using an IPv6 address, it ought to provide a AAAA record for an IPv6 address of the <del> Designated Resolver.  The Designated Resolver can support more address families than the Unencrypted Resolver, but it ought not to </del> <ins> Designated Resolver.  The Designated Resolver MAY support more address families than the Unencrypted Resolver, but it SHOULD NOT </ins> support fewer.  If this is not done, clients that only have connectivity over one address family might not be able to access the Designated Resolver.

Discussion:
CC NAME I might suggest a slightly less binding wording where port 53 is concerned for the Unencrypted Resolver definition. Perhaps: "A DNS resolver using a transport without encryption, historically TCP or UDP port 53." I'd be in favor of using more RFC 8174 "SHOULD/SHOULD NOT" text in place of "ought [not] to". Specifically, for the text about address family support, consider perhaps something like: OLD: ... The Designated Resolver can support more address families than the Unencrypted Resolver, but it ought not to support fewer. NEW: ... The Designated Resolver MAY support more address families than the Unencrypted Resolver, but it SHOULD NOT support fewer. I wonder if it's good to require that clients MUST NOT/SHOULD NOT accept certificates claiming to be for URL This might be over-specifying things and/or it might be a check against some types of misconfigurations.
Change:
After this point, any pending send operation is resumed to the bound peer address. <del> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. </del> <ins> path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </ins> 7.2.

Discussion:
Section 5 title "Off-path packet forwarding" should be "Attack model" instead? Also, is this the right position? ISTM this should go after we discuss the base challenge/response mechanics. There is also a missing premise, I think: "RRC is not designed to counter on-path attackers. These can never be distinguished from, for example, a genuine network device. However, RRC can resist off-path attackers when enhanced path validation ({{enhanced}}) is used."
Change:
draft-06 <ins> Reorder blanking and update in the Remove operation (*) </ins> Rename the GroupState structure to GroupContext (*) draft-05

Discussion:
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :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 .
Change:
alert" and "abort the handshake with a X alert" mean that the implementation MUST send alert X if it sends any alert.  All alerts defined in this section below, as well as all unknown alerts, are <del> universally considered fatal as of TLS 1.3 (see alert-protocol). The following error alerts are defined: </del> <ins> universally considered fatal as of TLS 1.3 (see alert-protocol).  The implementation SHOULD provide a way to facilitate logging the sending and receiving of alerts. </ins> An inappropriate message (e.g., the wrong handshake message, premature application data, etc.) was received.  This alert should

Discussion:
I disagree with this. Equally valid advice is to do as little as possible except abort the connection when receiving an alert. Some implementations will not send alerts at all.
NAME can you please raise this on the list in response to Kathleen's comments? Thanks
Per Kathleen's AD review