jiebi/CodeConvo huggingface dataset:
Change:
"blinded_msg" is the Nk-octet request defined above. <del> The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below: </del> <ins> The Client then generates an HTTP POST request to send to the Issuer Request URI, with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below: </ins> 6.2.

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
Push ID that is greater than the maximum Push ID. The Push ID is used in one or more PUSH_PROMISE frames (frame-push- <del> promise) that carry the header section of the request message.  These frames are sent on the request stream that generated the push.  This allows the server push to be associated with a client request.  When the same Push ID is promised on multiple request streams, the decompressed request field sections MUST contain the same fields in the same order, and both the name and the value in each field MUST be identical. </del> <ins> promise) that carry the control data and header fields of the request message.  These frames are sent on the request stream that generated the push.  This allows the server push to be associated with a client request.  When the same Push ID is promised on multiple request streams, the decompressed request field sections MUST contain the same fields in the same order, and both the name and the value in each field MUST be identical. </ins> The Push ID is then included with the push stream that ultimately fulfills those promises; see push-streams.  The push stream

Discussion:
The diff looks larger than it is; I moved some sections around to more closely resemble the TOC of the HTTP/2 spec, and changed a section title that seemed a bit odd a year later. The relocated sections haven't changed. Old TOC: HTTP Request Lifecycle HTTP Message Exchanges Field Formatting and Compression Request Cancellation and Rejection Malformed Requests and Responses The CONNECT Method HTTP Upgrade Server Push New TOC: Expressing HTTP Semantics in HTTP/3 HTTP Message Framing Request Cancellation and Rejection Malformed Requests and Responses HTTP Fields HTTP Control Data Request Pseudo-Header Fields Response Pseudo-Header Fields The CONNECT Method HTTP Upgrade Server Push Comparison H2 TOC: Expressing HTTP Semantics in HTTP/2 HTTP Message Framing Malformed Messages HTTP Fields Field Validity Connection-Specific Header Fields Compressing the Cookie Header Field HTTP Control Data Request Pseudo-Header Fields Response Pseudo-Header Fields Server Push Push Requests Push Responses The CONNECT Method The Upgrade Header Field URL then some further sections as well.
Http-core introduces a new term, "control data," and HTTP/2 has been updated to use this term. HTTP/3 has not. While it was not raised in Auth48, it might be appropriate to align this terminology before we publish these documents together.
This seems like a good change for consistency, even if it might cause the document editor some short term pain.
Closed in .
Change:
transcript of group operations, using the transcript hash from the provisional GroupState object: <ins> [[ OPEN ISSUE: The confirmation data and signature data should probably cover the same data as the one we cover with the GroupState. ]] </ins> HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. Sign uses the signature algorithm indicated by the signer's credential in the roster.

Discussion:
Fixes for points 1, 2, 4, 7 in .
I think a bunch of these are probably relics of previous versions. For reference, the page numbers listed are from the PDF version of draft 3 of the protocol: [x] 1 - p6: is mentioned, but it is not defined anywhere in the specification. Perhaps is intended.[x] 2 - p19: A field is mentioned, but only is present. Also it's unclear which function is supposed to be used here. It can't be ciphersuite-dependent, since it has to be the same for every Participant.[x] 3 - p22: is used in a diagram, but never defined. I think this is important, and it's mentioned elsewhere.[x] 4 - p24: is mentioned, but never defined. Is it supposed to say ?[ ] 5 - p25: The underlying Hash that HMAC uses can't be defined by anyone's ciphersuite. This is group state, and everyone has to agree on this.[x] 6 - p28: Mentioned "update secret" again without explanation.[x] 7 - p29: "identity tree" is mentioned, but I can't tell what that's referring to. Also "update secret" is here.[x] 8 - p35: is mentioned, but never defined. Perhaps is intended.
Thanks a lot for the review, this is very useful. I have a pass planned for this week and will fix these issues :)
NAME A PR was opened with fixes for points 1, 2, 4, 7. Point 8 was already solved. An issue has been opened to solve points 3 and 6 related to the update secret definition. I tried to figure out your point 5 but I didn't understand it, can you give details ?
Sorry for the delay. I think point 5 was a misunderstanding over when a common ciphersuite is established in the protocol. I'm still not 100% clear on it, but I think I'm just missing something simple. Consider it withdrawn.
Ok, then these issues are fixed by and . Thanks
Change:
transmitted with the DATAGRAM frame, like the STREAM frame, MUST be protected either by 0-RTT or 1-RTT keys. <ins> Application protocols that allow DATAGRAM frames to be sent in 0-RTT require a profile that defines acceptable use of 0-RTT; see Section 5.6 of RFC9001. </ins> 7. This document registers a new value in the QUIC Transport Parameter

Discussion:
I put this in Security Considerations, but I can see that is another good choice (perhaps a better one).
I agree this could also be its own subsection of section 5, but given that this really is just reiterating an existing requirement, it's also OK where it is.
Application protocols that use QUIC are required to define how 0-RTT is used. This draft doesn't really change that, but it does add to what 0-RTT can carry. In an abundance of caution, it should link to .
Change:
The "cid_length" field is a single octet containing the length of the connection ID. <del> 6. </del> <ins> 5. </ins> dtls-example2 shows an example exchange where a connection id is used uni-directionally from the client to the server.  To indicate that a

Discussion:
Trying to address URL but also trying to expand the description a bit for clarity.
According URL all records seems to use a . Does this include the ?
Does this PR provide an improvement help? URL
Yes, it clarifies it for me.
Change:
The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored. <del> Specific processing MUST be applied for the following session-level attribute ("a=") lines: </del> <ins> Finally, the attribute lines are processed.  Specific processing MUST be applied for the following session-level attribute ("a=") lines: </ins> Any "a=group" lines are parsed as specified in RFC5888, Section 5, and the group's semantics and mids are stored.

Discussion:
Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place
LGTM (other than the little bad xml issue)
Change:
Disabling 0-RTT entirely is the most effective defense against replay attack. <del> QUIC extensions MUST describe how replay attacks affects their </del> <ins> QUIC extensions MUST describe how replay attacks affect their </ins> operation, or prohibit their use in 0-RTT.  Application protocols MUST either prohibit the use of extensions that carry application semantics in 0-RTT or provide replay mitigation strategies.

Discussion:
Of the TLS doc says: A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This also prevents QUIC from sending 0-RTT data. However, this doesn't explicitly say that it prevents QUIC from receiving 0-RTT data. I suspect this is implied, but it might be worth clarifying. I could imagine a server rejecting 0-RTT data, but attempting to ACK the client's 0-RTT packets in order to deliver a congestion signal to the client. I think this would be a rather terrible idea, so it would be nice to explicitly prohibit it.
Throughout transport, there is the idea that you MUST not acknowledge packets you can't fully process, so this should be against the spec. But it may be worth noting explicitly, probably in transport.
Doing it in transport would make sense. Or perhaps in TLS by noting that if 0-RTT is rejected, 0-RTT keys must not be generated.
NAME I just added text about that to my PR that's targeting .
SG NAME If so, can you update the CL description to indicate what issues it closes?
I'm going so recommend that this be triaged as a design issue, even if it might seem trivial. The prohibition in is the right response.
The spec says RFC 8446 says about rejecting 0-RTT: This doesn't really apply to QUIC, since we don't need a connection that requires us to read the bytes in order. The QUIC equivalent would be to drop all packets of packet type 0-RTT.
It is my understanding the existence of early_data extension in the EncryptedExtensions message indicates if the server has accepted 0-RTT (or not). Merely dropping the packets is not sufficient. This is because the parameters of a connection depends on if 0-RTT has been received; for example, in case of HTTP/3, until the client receives a SETTINGS frame, the settings of previous connection is applied when 0-RTT is accepted, whereas the default settings defined by the specification is applied when 0-RTT is rejected.
PS. What I think we need to clarify is that "use and acceptance" of 0-RTT is communicated the same way as TLS 1.3, by using the earlydata extension.

That includes earlydata extension sent in ClientHello, EncryptedExtensions, NewSessionTicket.
Thanks NAME That confirms my interpretation of how accepting and rejecting is supposed to work. I’ll prepare a PR later.
Change:
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_uni. <ins> A server might provide larger initial stream flow control limits for streams than the remembered values that a client applies when sending 0-RTT.  Once the handshake completes, the client updates the flow control limits on all sending streams using the updated values of initial_max_stream_data_bidi_remote and initial_max_stream_data_uni. </ins> A server MAY store and recover the previously sent values of the max_idle_timeout, max_udp_payload_size, and disable_active_migration parameters and reject 0-RTT if it selects smaller values.  Lowering

Discussion:
If the client has opened a stream in 0-RTT with , and the server increases to , does this apply to this stream as well, or only to streams opened after handshake completion? Consensus in Slack seems to be that the limit should apply to all streams. The text should be explicit about that.
Isn't that already clear enough? states:
NAME This is what the definition of the TP says: Arguably, the stream used in 0-RTT is not a "newly created" stream.
Yeah, let's just be really clear about this. Though NAME quotes the section that is most important, this has proven to be a mistake common enough to spend text on.
Change:
retaining the benefits of a local caching resolver with knowledge of the local topology. <ins> Clients will be aware when the designated resolver has the same IP address as the Do53 (after looking up its name if required).  They can use this information in their decision-making as to the level of trust to place in the designated resolver.  In some networks it will not be possible to deploy encrypted DNS on the same IP address, e.g. because of the increased resource requirements of encrypted DNS. Discovery solutions should work in the presence of a change to a different local IP address. </ins> An additional benefit of using a local resolver occurs with IoT devices.  A common usage pattern for such devices is for it to "call home" to a service that resides on the public Internet, where that

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
HSM-based: A Hardware Security Module (HSM) based cryptoprocessor which hashes one or more streams of security measurements from an Attester within the Attesting Environment.  Maintenance of this <del> hash enables detection of an Attester which is lying about the set of security measurements taken.  An example of a HSM is a TPM2.0 </del> <ins> hash enables detection of an Attester which is not reporting the exact set of security measurements (such as log entries) taken within the Attesting Environment.  An example of a HSM is a TPM2.0 </ins> TPM2.0. Process-based: An individual process which has its runtime memory

Discussion:
Based on request from Yogesh for a new Configuration encoded claim.
Thanks Eric! As you may have guessed, we have an immediate use for this 36 :-)
Change:
A TCP connection error is signaled by abruptly terminating the stream.  A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream <del> error of type H3_CONNECT_ERROR; see errors.  Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.  If the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set. </del> <ins> error of type H3_CONNECT_ERROR; see errors. Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.  If the proxy detects that the client has reset the stream or aborted reading from the stream, it MUST close the TCP connection.  If the stream is reset or reading is aborted by the client, a proxy SHOULD perform the same operation on the other direction in order to ensure that both directions of the stream are cancelled.  In all these cases, if the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set. </ins> Since CONNECT creates a tunnel to an arbitrary server, proxies that support CONNECT SHOULD restrict its use to a set of known ports or a

Discussion:
This looks great to me.
NAME that's a good point. Let me reword it to use the operation terms rather than the v1 frame names.
From ... : URL be improved in h3. Not the TCP RST part, but the bit that leads up to it. Otherwise, we might not get the right behaviour. If the proxy just closes the connection in response to RESET_STREAM, it might then just end the stream (with a FIN bit), which would be wrong. Perhaps instead: Somewhat substantive, unfortunately, and very, very, very late. I'm happy to wait and file an erratum.
This seems like a solid improvement, but it's definitely not editorial. NAME and NAME will need to decide whether this is a change they're willing to accept post-IESG.
Endpoints that overlook the proposed behaviour risk zombie streams. This seems like something worth addressing while we have the opportunity. Can one of you please file create a PR and we'll take it to the AD.
Closed in .
Better than my text :)This looks ready to go, are we merging it soon?
Change:
ones.  DetNet flow ID and flow related parameters/requirements must be converted to a TSN Stream ID and stream related parameters/ requirements.  Note that, as the TSN sub-network is just a portion of <del> the end2end DetNet path (i.e., single hop from IP perspective), some parameters (e.g., delay) may differ significantly.  Other parameters (like bandwidth) also may have to be tuned due to the L2 </del> <ins> the end-to-end DetNet path (i.e., single hop from IP perspective), some parameters (e.g., delay) may differ significantly.  Other parameters (like bandwidth) also may have to be tuned due to the L2 </ins> encapsulation used within the TSN sub-network. In some case it may be challenging to determine some TSN Stream

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
public keys are opaque values in a format defined by the signature scheme. <ins> Note that each new credential that has not already been validated by the application SHOULD be validated against the Authentication Service. [[OPEN ISSUE: 1.  SHOULD vs MUST.  2.  A client that wants to update its identity key can perform the operation UNDER THIS CONDITION by adding a new version of herself using a new credential signed under a new IdentityKey, then performing a remove of the old leaf.  This is fine as long as the credential binds to the same identity for the application.  If this verfication is not met, there is no authentication guarantee at the application layer anyway.]] </ins> 6.4. To allow group members to verify that they agree on the cryptographic

Discussion:
I couldn't find this written anywhere else and this is also related to a discussion about PCS with Cas and al.
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 5 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :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 .
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits.

:hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :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 .
Change:
A typical group messaging scenario might look like this: <del> Alice, Bob and Charlie create accounts with a messaging service and obtain credentials from the AS. </del> <ins> Alice, Bob and Charlie create accounts with a service provider and obtain credentials from the AS. </ins> Alice, Bob and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted

Discussion:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by
Change:
For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  Any <del> additional assignments require IETF Consensus action. </del> <ins> additional assignments require IETF Review. NOTE: IANA, please update the registries to reflect the new policy name. NOTE: RFC editor please delete these two notes prior to publication. IANA, please update these two registries to refer to this document. IANA is requested to assign two values from the NamedCurve registry with names Curve25519(TBD1) and Curve448(TBD2) with this document as reference. </ins> 9.

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519