jiebi/CodeConvo huggingface dataset:
Change:
When the server cannot decrypt or does not process the "encrypted_server_name" extension, it continues with the handshake using the cleartext "server_name" extension instead (see server- <del> behavior).  Clients that offer ESNI then verify the certificate with the public name, as follows: </del> <ins> behavior).  Clients that offer ESNI then authenticate the connection with the public name, as follows: </ins> If the server resumed a session or negotiated a session that did not use a certificate for authentication, the client MUST abort

Discussion:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.
Change:
large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <ins> Since QUIC DATAGRAM frames are required to fit within a QUIC packet, implementations that reencode DATAGRAM capsules into QUIC DATAGRAM frames might be tempted to accumulate the entire capsule before reencoding it.  This can cause flow control problems; see capsule- protocol. </ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports

Discussion:
This adds a few statements through the text that explains that data streams are subject to any flow control provided by layers lower down. Wih that in mind, the potential for problem deadlocks should be clearer when we state it.
This is a non-blocking comment from AD review. I have no concerns if the authors choose to close it with no action. It might be worthwhile to discuss the interaction of stream flow control with capsule/datagram conversions. With other HTTP transactions, intermediaries can deliver whatever in-order bytes of the stream they have. When receiving capsules and emitting datagrams, if the stream flow control window is too small to accept the datagram size, there can be a deadlock. A sentence about this special case could avoid a silly implementer mistake.
I think this goes beyond just intermediaries. Instead it applies to any consumer of capsules where they might be tempted to try and buffer the capsule, in the data stream, in its entirety before processing or consuming it. That might be obvious as a "bad thing" for implementers that are already used to handling H2 or H3 frames. However, you identify that the DATAGRAM capsule is particularly tempting to buffer because it should be handled atomically. So I think it might help to briefly point out some deadlock considerations about flow window sizes in relation to capsule sizes, and processing / release of further window credits.
Adding a little bit of text to warn against such cases SGTM
Change:
is provided, the value is computed as: Where Secret is either the early_exporter_secret or the <del> exporter_secret. </del> <ins> exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  When adding TLS 1.3 to TLS 1.2 stacks, the exporter_secret MUST be for the existing exporter interface. </ins> If no context is provided, the value is computed as:

Discussion:
Various changes to make exporters/resumption work better. The rationale is to be able to do stuff in 0/0.5RTT. Add a 0-RTT exporter and change the transcript for the regular exporter (*). Explicitly allow predicting ClientFinished for NST when not doing Client auth.
Change:
New transport parameters can be used to negotiate new protocol behavior.  An endpoint MUST ignore transport parameters that it does not support.  Absence of a transport parameter therefore disables any <del> optional protocol feature that is negotiated using the parameter. </del> <ins> optional protocol feature that is negotiated using the parameter.  As described in transport-parameter-grease, some identifiers are reserved in order to exercise this requirement. </ins> New transport parameters can be registered according to the rules in iana-transport-parameters.

Discussion:
NAME I added IANA considerations, analogous to those in the HTTP doc for the stream type.
We have space for private transport parameters and a process for assigning new standard transport parameters. However, since we do not apply GREASE to transport parameters, we leave ourselves open to that flexibility ossifying. I'm happy to produce a PR to address this in the spec.
During interop in London we found an implementation that failed the handshake upon seeing an unknown transport parameter. I think applying GREASE to transport parameters is a great idea.
Discussed in London, NAME to prepare a PR
NAME any progress here?
I have prepared something. I can open a pr
NAME sorry I totally dropped the ball here! I had text ages ago and was circling back today finally. Thanks NAME for seeing to it.
Thanks Marten!Thanks for writing this up!Need to fix the examples, but otherwise looks good.
Change:
IDevID.  Alternatively, the LDevID may be acquired by a service technician after authentication against the issuing CA. <del> 10. </del> <ins> 11. </ins> We would like to thank the various reviewers for their input, in particular Brian E.  Carpenter, Michael Richardson, Giorgio

Discussion:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.
Change:
And its fields set to: Here, the functions "Signature.Sign" and "Signature.Verify" are <del> defined by the signature algorithm. </del> <ins> defined by the signature algorithm.  If MLS extensions require signatures by group members, they should re-use the SignWithLabel construction, using a distinct label.  To avoid collisions in these labels, an IANA registry is defined in mls-signature-labels. </ins> The ciphersuites are defined in section mls-ciphersuites.

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:
the frame.  These frames are explained in more detail in frame- formats. <ins> The "Packets" column in frame-types does not form part of the IANA registry (see iana-frames).  This column summarizes the types of packets that each frame type can appear in, indicated as up to four characters indicating: Initial (packet-initial) Handshake (packet-handshake) 0-RTT (packet-0rtt) 1-RTT (short-header) A CONNECTION_CLOSE frame of type 0x1c can appear in Initial, Handshake, and 1-RTT packets, whereas a CONNECTION_CLOSE of type 0x1d can only appear in a 1-RTT packet. Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets. </ins> An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR.

Discussion:
It's still slightly odd where we have this setup between TLS and transport, but it seems like replicating the information might be enough.
Would it make sense to add PN space columns to the table of frames with section references, with an X where a frame is applicable? Transport section 12.4 URL
Looks good to me, and thank you for adding this column. Seeing frames like PATH_CHALLENGE/RESPONSE in 0RTT packets is strange, but clearly allowed by the spec. I don't see a reason to changing this, but it's why I think this column is useful.
Change:
An empty payload is considered a malformed request. <ins> The posted link-format document can (and typically does) contain relative references both in its link targets and in its anchors, or contain empty anchors.  The server needs to resolve these references in order to faithfully represent them in lookups.  The Base URI against which they are resolved is the context of the registration, which is provided either explicitly in the "con" parameter or constructed implicitly from the requester's network address.  When resolving relative target references, the server first resolves the context of that link (the in the "anchor" attribute), and then interprets the target as a reference relative to that context (see resolution-rules). </ins> The registration request interface is specified as follows: EP -> RD

Discussion:
The first commit tries to get across the difference between the relative references in the serialization and the URIs in the model more clearly. The second commit adds paragraphs to the descriptions of various operations about how and by whom URIs are resolved in those steps.
Change:
m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> Each "a=tls-id" line MUST stay the same unless the offerer's "a=tls-id" line changed, in which case a new "a=tls-id" value MUST be created, as described in I-D.ietf-mmusic-dtls-sdp, Section 5.2. </ins> Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer.

Discussion:
In section 5.10, the text that says to tear down the old TLS connections seems like it needs a tweek. For the case of a PR_ANS, I would expect it to not get torn down until the resources are freed when the ANS happens.
See: URL
We had a call to discuss and I think reached resolution on the SDP issue. I will prepare a PR and send to the list for approval. Separately we need to close on tls-id size, but that need not hold JSEP if we are willing to have the examples use the longer size (which we all agree is permitted)
Update: we had a call to discuss this and I think have resolution on the SDP semantics. I will prepare a PR for that and send to lists. Separately, we have to discuss the S
JSEP says: values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. But tls-ids are independently generated on each side.
Examples/example generator will also need to get tweaked
Change:
If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" <del> SUDN. </del> <ins> SUDN, to provide a consistent and accurate signal to clients that it does not have a Designated Resolver. </ins> 4.1.

Discussion:
NAME please check!
I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
LGTM!
Change:
due to a problem with the name server."  (Quoted from RFC1035, Section 4.1.1.) <del> "Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced </del> <ins> "Name Error - This code signifies that the domain name referenced </ins> in the query does not exist."  (Quoted from RFC1035, Section 4.1.1.)  RFC2308 established NXDOMAIN as a synonym for Name Error.

Discussion:
There is one typo at "Authoritative data:". Other differences are OK. | , Section 2, defines "Authoritative RRset" which is related | to authoritative data [bu] has a more precise definition. ("bu"is "but" ?)
I missed to change branch and I commited to this branch. please review "f172affe0f5d111af23f8c48f9ed5715e7b314d0".
Change:
section is the algorithm defining which of these options to try, when, and in what order. <del> During Candidate Gathering, an implementation prunes and sorts branches according to the Selection Property preferences (Section 6.2 of I-D.ietf-taps-interface.  It first excludes all protocols and paths that match a Prohibit property or do not match all Require properties.  Then it will sort branches according to Preferred properties, Avoided properties, and possibly other criteria. </del> <ins> During Candidate Gathering (gathering), an implementation prunes and sorts branches according to the Selection Property preferences (Section 6.2 of I-D.ietf-taps-interface.  It first excludes all protocols and paths that match a Prohibit property or do not match all Require properties.  Then it will sort branches according to Preferred properties, Avoided properties, and possibly other criteria. </ins> 4.1.

Discussion:
Raising this issue as part of my review of the the Implementation Draft. To a reader who understands "protocol racing" in the "Happy Eyeballs" sense of near-simultaneous connection establishment attempts, parts of Section 4.1 are confusing. It appears as if "real racing" actually only occurs between Derived Endpoints and not e.g., among Alternate Paths, where we instead have "failover after timeout": Section 4.1.1.2 However, in Section 4.1.1.3 "Protocol Options", the "rank[ing] and attempt[ing]" of options is also referred to as "racing": It seems clear that this kind of information is only useful when connection attempts are not in fact "raced" (nearly) in parallel, but are only conducted in succession, where it makes sense to rank the candidates accordingly. This confusion is only cleared up in Section 4.3, where it says: So it appears as if (in partial departure from the Happy Eyeballs RFC) the term "racing" here is meant to include staggered or failover scenarios, somewhat undermining the original metaphor. Suggestions: Explain the extended scope of the "racing" term earlier Perhaps replace some uses the term "racing" with "failover" or even just "ranking"
Mention that "staggered" is the most common form of racing The main thing with racing is that the first one to succeed wins We should add forward references to sections here: We should also explain in this paragraph that the "Staggered" approach is generally the default for racing, and the first one to finish wins.
LGTM, thanks!
Change:
"ClientECH.cipher_suite", "ClientECH.config_id", and "ClientECH.enc" fields of the payload of the "encrypted_client_hello" extension.  The last parameter, "outer_hello", is computed by serializing <del> ClientHelloOuter with the "encrypted_client_hello" extension removed. Note this does not include the four-byte header included in the Handshake structure. </del> <ins> ClientHelloOuter with the "encrypted_client_hello" extension set to the empty string, i.e., the "extension_data" list has zero length. Note this serialization does not include the four-byte header included in the Handshake structure. </ins> <del> Note the decompression process in encoding-inner forbids </del> <ins> The decompression process in encoding-inner forbids </ins> "encrypted_client_hello" in OuterExtensions.  This ensures the unauthenticated portion of ClientHelloOuter is not incorporated into ClientHelloInner.

Discussion:
Having looked at this, I have a preference for a construction where the outer ClientHello has a placeholder with empty extension data, rather than a placeholder that has an empty payload field. Zeroing out the payload field is not easier in our implementation. It is somewhat more difficult to implement. This is a preference only; anything can be implemented. But this version is preferable.
The position of the ECH extension is not authenticated as part of ClientHelloOuterAAD. This means that it is possible to construct multiple different ClientHello messages that will all be accepted. This probably isn't that interesting, but it might be worth noting.
If we want to fix this (I don't care either way), we can remove the fields prepended to ClientHelloOuterAAD, leave the ECH extension in, and say the AAD is computed by replacing ClientECH.payload with the empty string.
That seems like a reasonable proposal. NAME what do you think? (NAME might also have thoughts on this.)
I can live with either a placeholder or text in the draft that explains the limitation. Extension order doesn't carry any semantics, so I don't see malleability as a real risk. I'd lean toward the placeholder, but only slightly. More so if we were planning to change the AAD anyway.
This seems like a good idea to me.
If we don't really care about this issue, why specify it? Does this add complexity or reduce it?
We don't know of any way this can be a problem, but that doesn't mean there is none. Plus, malleability is generally not great. I don't think this moves the complexity needle in a meaningful way.
I guess it exposes an active distinguishing attack, though I suspect this style of attack has plenty of vectors: Attacker rewrites CH to move the ECH extension to another spot and forwards to server Server responds with SH..Finished. Attacker forwards that to client unmodified If this was negotiating CHOuter, this would break the transcript and the client would reject. If this was negotiating CHInner, the client won't notice and proceed
Yep, nice! Let's definitely make this change, then.
Change:
1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by <del> the sequence number of the received packet's DCID over that path, hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path as path identifier, which corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for </del> <ins> the sequence number of the DCID it uses for sending packets over that path, hence using the path_id 2.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the DCID it uses to send over that path as path identifier, which corresponds to the path_id 1.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for </ins> that path. 7.

Discussion:
Since , we now define the Path ID as (Section 1.1) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path (i.e., the sequence number of the destination Connection ID used for sending packets on that particular path, Sections 8.1 and 8.2). But in Section 6.2, the example states that I believe the current text is unclear and should be fixed. Yet, I see two possible ways of doing so. We should either state that the field of these frames refer to the Path ID used by the receiver of the frame, or add some information to indicate that it refers to the Path ID viewed from the sender's/receiver's viewpoint (that could be encoded as a bit in the frame's type)
Is there any use case for either using the sender's or receiver's ID? If not, I'd prefer we simply choose one and define it clearly.
(P.S.: I think the text in the example is just wrong. I think I messed this up in .)
IMHO it makes more sense to me to use the sender's ID by default, especially if we consider only client-initiated paths.
I would also suggest to slightly update the text related to the field of the PATHABANDON and PATHSTATUS frames to indicate it refers to the sender's Path ID.LGTM