jiebi/CodeConvo huggingface dataset:
Change:
by the Attesting Environment that has the key material that protects the conveyance channel <del> The root of trust protects both the conveyance channel key material and the Attesting Environment with equivalent strength protections. </del> <ins> A trusted environment protects the conveyance channel's key material which may depend on other Attesting Environments with equivalent strength protections. </ins> As illustrated in I-D.birkholz-rats-uccs, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on

Discussion:
Reworded sections containing root of trust leaving a single parenthetical that associates the term loosely with an attesting environment that is implicitly trusted.
It makes sense to remove the term 'root of trust' since the document doesn't define it. It might make sense to reference other industry specs that have relevant definitions such as NISTIR 8320A.
NAME apparently, this taks has no assignees. Do you want to do that?
OK, assign it to me.
Change:
This document specifies two variants of the the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are <del> privately verifiable, and another that produces tokens that are publicly verifiable. </del> <ins> privately verifiable using the issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key. </ins> 1.

Discussion:
Hexadecimal constants are used as strings without specifying the length or byte order. For example, "0x0001" might be interpreted in a couple of ways. Usually the correct interpretation is clear in context, but I'm not sure it always is.
[ ] Overall: The document is inconsistent about capitalization after colon (":"). [ ] Abstract: I'm not sure the distinction between public/private verifiability is common knowledge. It might be helpful to say plainly who is doing the verifying. E.g.: "one [variant] providing tokens whose validity can be verified by the issuer only; and another for which token validity can be verified by any party with the issuer public key." [ ] 2 Terminology: "We assume that all protocol messages are encoded into raw byte formatt before being sent across the wire" This doesn't need to be mentioned, in my opinion. [ ] 5.1 Client-To-Issuer Request: The psedocode for computing "client_context" hard-codes a particular OPRF suite (0x0004). Is this the only suite that is permitted/recommended by the document? I don't think this is clear until the token types are defined in Section 8.1. [ ] 5.3 Finalization: Constants hardcoded instructs don't a semi-colon after the constant. (See "Token" in this section, for example.) Is this intentional? It looks a bit odd, and I'm wondering if this is "syntactically" correct. [ ] 5.4 Token Verification: I think it's worth pointing out here that creating the server context requires the Issuer Private Key, which is why VOPRF is not publicly verifiable. [ ] 7 Security Considerations: "All security considerations described in the VOPRF document also apply in the Privacy Pass use-case." What about security considerations for BLINDRSA? It might be a bit cleaner to write something like this: "Each protocol described here inherits the security considerations of its base document: For Section 5, this is [VOPRF]; ... " [ ] Acknowledgements: Sofi is acknowledged, but is also a co-author.
I think I caught all of these. Addressed in . Yes, this is much better! Addressed in .

This is addressed by . We explain the constant in the sentence immediately following the pseudocode, so I don't think further clarification is needed. The semi-colon was missing, but we updated this to match what's done in RFC8446. Addressed in . Addressed in . Good catch. This has already been fixed on the editor's branch to say "All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use-case."
Change:
5.9. <del> CertificateVerify and Finished messages have the same format as in TLS 1.3.  Hash calculations include entire handshake messages, including DTLS-specific fields: message_seq, fragment_offset, and fragment_length.  However, in order to remove sensitivity to handshake message fragmentation, the CertificateVerify and the Finished messages MUST be computed as if each handshake message had been sent as a single fragment following the algorithm described in Section 4.4.3 and Section 4.4.4 of TLS13, respectively. 5.10. </del> Section 7.1 of TLS13 specifies that HKDF-Expand-Label uses a label prefix of "tls13 ".  For DTLS 1.3, that label SHALL be "dtls13". This ensures key separation between DTLS 1.3 and TLS 1.3.  Note that

Discussion:
This makes the handshake the same as TLS 1.3 (modulo the version numbers, which are conveniently different.
As discussed at the meeting. NAME PTAL.
This also LGTM. Let's do a brief consensus call before merging.
Change:
[10] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/78 <del> [11] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/56 </del> <ins> [11] https://www.iana.org/assignments/named-information/named- information.xhtml#hash-alg </ins> [12] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/85

Discussion:
To edit notification comments on pull requests, go to your ._
Receive a Callback After Interaction: Editor's note: This should be expandable via a registry of cryptographic options, and it would be good if we didn't define our own identifiers here. Calculating the interaction hash: Editor's note: These hash algorithms should be pluggable, and ideally we shouldn't redefine yet another crypto registry for this purpose, but I'm not convinced an appropriate one already exists. Furthermore, we should be following best practices here whether it's a plain hash, a keyed MAC, an HMAC, or some other form of cryptographic function. I'm not sure what the defaults and options ought to be, but SHA512 and SHA3 were picked based on what was available to early developers.
This is probably the right registry to reference: URL
Please add a changelog, but this looks good to me!
Change:
the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering. <del> The URL of this API will have been provisioned to the User Equipment. </del> <ins> The URI of this API will have been provisioned to the User Equipment. </ins> (Refer to section_provisioning). This architecture expects the User Equipment to query the API when

Discussion:
This replaces any 'URL' terminology with 'URI'. It also adds an informative reference to RFC 3986 , as suggested. Fixes issue
Multiple reviewers have suggested that we use URI instead of URL. I think we should make this change, and add the informative reference.
Change:
IANA, please update these two registries to refer to this document. IANA is requested to assign four values from the NamedCurve registry <del> with names Curve25519(TBD1), Curve448(TBD2), Ed25519(TBD3) and Ed448(TBD4) with this document as reference. </del> <ins> with names ecdh_x25519(TBD1), ecdh_x448(TBD2), eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference. </ins> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.

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:
https://dnsserver.example.net/dns-query to resolve the IN A records. The requests are represented as application/dns-udpwirefomat typed <del> bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del> <ins> bodies. </ins> The first example request uses GET to request www.example.com

Discussion:
The discussion of Accept: header tries too hard to suggest that there will be future formats. We don't actually know that, and the examples in the current draft have confused some developers. See PR URL
Yep, easier to narrow this down than address the implied questions.
Change:
standard types.  Clients SHOULD display the "detail" field of all errors. <del> Authorization and challenge objects can also contain error information to indicate why the server was unable to validate authorization. </del> 6. In this section, we describe the certificate management functions

Discussion:
Also switches the type of the challenge type to be instead of as JSON doesn't have dictionaries. I'll push a follow-up PR that will switch the rest of the -> .
Change:
side media processing. This document proposes a simple HTTP based protocol that will allow <del> WebRTC endpoings to ingest content into streaming servics and/or CDNs </del> <ins> WebRTC endpoints to ingest content into streaming servics and/or CDNs </ins> to fill this gap and facilitate deployment. 1.

Discussion:
Authtentication, bearear, proposse, detailled, endpoings, adption, traditionnal.
Thank you very much!
Change:
least one RTT and congestion control will also be reset on path migration.  Therefore migration usually has a performance impact. <del> As long as the new path is not validated only probing packets can be sent.  However, the probing packets can be used measure path characteristics as input for the switching decision or the congestion controller on the new path. </del> <ins> Probing packets, which cannot carry application data, can be sent on multiple paths at once.  Probing packets can be used to perform address validation, measure path characteristics as input for the switching decision, or prime the congestion controller in preparation for switching to the new path. </ins> Only the client can actively migrate.  However, servers can indicate during the handshake that they prefer to transfer the connection to a <del> different address after the handshake, e.g. to move from an address that is shared by multiple servers to an address that is unique to the server instance.  The server can provide an IPv4 and an IPv6 address in a transport parameter during the TLS handshake and the client can select between the two if both are provided.  See also Section 9.6 of QUIC. </del> <ins> different address after the handshake.  For instance, this could be used to move from an address that is shared by multiple servers to an address that is unique to the server instance.  The server can provide an IPv4 and an IPv6 address in a transport parameter during the TLS handshake and the client can select between the two if both are provided.  See also Section 9.6 of QUIC. </ins> 8.

Discussion:
Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.
Change:
Though a URI might still correctly resolve when the User Equipment makes the request from a different network, it is possible that some functions could be limited to when the User Equipment makes requests <del> using the captive network.  For example, payment options could be </del> <ins> using the Captive Portal.  For example, payment options could be </ins> absent or a warning could be displayed to indicate the payment is not for the current connection.

Discussion:
A reviewer found a problem with some phrasing, and also noticed that we missed a few captive networks. Clean them up.
Change:
If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a <del> Designated Resolver.  The client can still use others records in the </del> <ins> Designated Resolver.  The client can still use other records in the </ins> same response if the client can understand all of their mandatory parameters.  This allows future encrypted deployments to simultaneously support protocols even if a given client is not aware

Discussion:
Thanks for the painless read! Just a few trivial comments. Minor: The editorial commentary in the IANA Considerations section seems out of place -- generally IANA Considerations is, well, requests to IANA, not interesting and fun trivia about the resources being requested. But, IANA are smart enough to disregard the superflous material. Nits: , The client can still use others records in the same response s/others/other/ , provides provides s/provides//
Change:
authenticated negotiation of an application protocol (TLS uses ALPN ALPN for this purpose) <del> An endpoint verifies support for Explicit Congestion Notification (ECN) by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del> <ins> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint verifies support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </ins> The CRYPTO frame can be sent in different packet number spaces (packet-numbers).  The offsets used by CRYPTO frames to ensure

Discussion:
Yeah, this is better.
The sentence observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in {{ecn-validation}}. seems to not belong into that section.
Assuming one enables ECN on Initial and Handshake packets in order to perform ECN validation, then I think it's the right place?
NAME are you OK with NAME explanation, i.e., can we close with no action?
Not really happy with it, tbh. The sentence feels completely out of place as it stands now. I think we should either move it to the ECN section (I think that would make the most sense), or at least add an introductory sentence, along these lines:
I like the introductory sentence.
WFMThis is good, thanks!
Change:
Less ticket waste: Currently, TLS servers use application- specific, and often implementation-specific, logic to determine how many tickets to issue.  By moving the burden of ticket count <del> to clients, servers do not generate wasteful tickets for clients. Moreover, as ticket generation may involve expensive computation, e.g., public key cryptographic operations, avoiding waste is desirable. </del> <ins> to clients, servers do not generate wasteful tickets.  As an example, clients might only request one ticket during resumption. Moreover, as ticket generation might involve expensive computation, e.g., public key cryptographic operations, avoiding waste is desirable. </ins> <del> Decline resumption: Clients may indicate they have no intention of </del> <ins> Decline resumption: Clients can indicate they have no intention of </ins> resuming connections by sending a ticket request with count of zero. 3. <del> Clients may indicate to servers their desired number of tickets for a </del> <ins> Clients can indicate to servers their desired number of tickets for a </ins> single connection via the following "ticket_request" extension: <del> Clients may send this extension in ClientHello.  It contains the </del> <ins> Clients MAY send this extension in ClientHello.  It contains the </ins> following structure: The number of tickets desired by the client. <del> A supporting server MAY vend TicketRequestContents.count NewSessionTicket messages to a requesting client, and SHOULD NOT send more than TicketRequestContents.count NewSessionTicket messages to a requesting client.  Servers SHOULD place a limit on the number of tickets they are willing to vend to clients.  Thus, the number of NewSessionTicket messages sent should be the minimum of the server's self-imposed limit and TicketRequestContents.count.  Servers MUST NOT send more than 255 tickets to clients. </del> <ins> A supporting server MAY use TicketRequestContents.count when determining how many NewSessionTicket messages to send to a requesting client, and SHOULD place a limit on the number of tickets sent.  The number of NewSessionTicket messages sent SHOULD be the minimum of the server's self-imposed limit and TicketRequestContents.count. </ins> Servers that support ticket requests MUST NOT echo "ticket_request" in the EncryptedExtensions message.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in the EncryptedExtensions message. <del> Clients MUST NOT change the value of TicketRequestContents.count in second ClientHello messages sent in response to a HelloRetryRequest. </del> <ins> If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second ClientHello message.  Moreover, if this extension is present, a client MUST NOT change the value of TicketRequestContents.count in the second ClientHello message. </ins> 4.

Discussion:
If they don't enforce a limit, clients can cause them to do a lot of work.
Fixed by .
Approved pending
Change:
additional information using a problem document RFC7807.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the DAP <del> URN namespace "urn:ietf:params:ppm:error:"): </del> <ins> URN namespace "urn:ietf:params:ppm:dap:error:"): </ins> This list is not exhaustive.  The server MAY return errors set to a URI other than those defined above.  Servers MUST NOT use the DAP URN

Discussion:
This change is basically a search-and-replace for /ppm/dap/. However, I have also re-aligned the context strings to match the next draft that will be cut (-01). I think the change is mostly correct, my main concern is the "URN Sub-namespace for PPM (urn:ietf:params:dap)" section. : Does it make sense for all drafts in the PPM WG to share the namespace, or do we want to define one specifically for DAP?
Before merging I would appreciate an answer on the question I raised above. I want to make sure the URN bits are correct.
Separate namespaces seems better, especially if we're thinking of DAP and STAR. Names are cheap, after all.
Separate namespaces, because otherwise I think we'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference. We should avoid spreading the specification across multiple documents more than necessary. Maybe including the WG in the URN path like helps?
Here's the RFC defining URL It's pretty loosely structured, and the existing sub-namespaces from published RFCs appear to just be named after protocols and formats, not working groups. URL
I took NAME suggestion of prefixing the dap space with ppm.
Change:
A public key (with its associated algorithm) The signature on the credential indicates a delegation from the <del> certificate which is issued to the TLS server operator.  The key pair used to sign a credential is presumed to be one whose public key is contained in an X.509 certificate that associates one or more names to the credential. </del> <ins> certificate that is issued to the TLS server operator.  The secret key used to sign a credential is presumed to be one whose corresponding public key is contained in an X.509 certificate that associates one or more names to the credential. </ins> A TLS handshake that uses credentials differs from a normal handshake in a few important ways:

Discussion:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes
Change:
of RFC6241, RFC7950, and RFC8309.  The document uses terms from those documents. <del> Tree diagrams used in this document follow the notation defined in [RFC8340]. </del> <ins> The meanings of the symbols in tree diagrams are defined in RFC8340. </ins> This document uses the term "network model" defined in Section 2.1 of RFC8969.

Discussion:
Check if we need to expose SAPs per servcie-type and if so, how we can easily add support for it OLD: NEW:
Change:
The key and IV for the packet are computed as described in protection-keys.  The nonce, N, is formed by combining the packet <del> protection IV with the packet number.  The 64 bits of the </del> <ins> protection IV with the packet number.  The 62 bits of the </ins> reconstructed QUIC packet number in network byte order are left- padded with zeros to the size of the IV.  The exclusive OR of the padded packet number and the IV forms the AEAD nonce.

Discussion:
In Section 12.3, the transport specs says: But in both 17.2 (Long Header) and 17.3 (Short Header), Packet Number field in the packet is noted as the following format: which suggest it isn't variable-length integers. Can we get some clarification regarding this? Thank you!
Section 17.2/17.3 is correct -- PNs are not encoded using the varint form in Sec 16.
Change:
outputs of the corresponding functions defined in RFC7748, 32 bytes for x25519 and 56 bytes for x448. <del> Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve. </del> <ins> Note: Versions of TLS prior to 1.3 permitted point format negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve. </ins> 4.2.5.

Discussion:
TLS still permits shared point negotiation via ECDH, TLS 1.3 removes point format negotiation.
Change:
processing RFC8152. IANA is requested to register the following new items in the <del> registry. </del> <ins> registry.  For these entries, the Value Registry column will be blank and the Reference column will be [[This Document]]. </ins> IANA is requested to modify the Description field for "counter signature" and "CounterSignature0" to include the words "(Deprecated

Discussion:
Remove the sections from the Examples Applenix that were blank, clean up the Security Considerations, and narrow the table in the IANA considerations.
Looks good to me! Thanks! Let us know if you want us to merge it or you plan to do that yourself.
Change:
fragmentation, <del> demultiplex EDHOC messages from other types of messages, and </del> <ins> demultiplex EDHOC messages from other types of messages, denial-of-service protection, </ins> <del> denial-of-service protection. </del> <ins> message correlation. </ins> <del> Besides these common transport-oriented properties, EDHOC transport additionally needs to support the correlation between EDHOC messages, including an indication of a message being message_1.  The </del> <ins> The Initiator and the Responder need to have agreed on a transport to be used for EDHOC, see applicability. 3.4.1. The transport needs to support the correlation between EDHOC messages and facilitate the retrieval of protocol state during EDHOC protocol execution, including an indication of a message being message_1.  The </ins> correlation may reuse existing mechanisms in the transport protocol. For example, the CoAP Token may be used to correlate EDHOC messages <del> in a CoAP response and an associated CoAP request.  In the absence of correlation between a message received and a message previously sent inherent to the transport, the EDHOC connection identifiers may be added, e.g., by prepending the appropriate connection identifier </del> <ins> in a CoAP response and an associated CoAP request. Connection identifiers may be used to correlate EDHOC messages and facilitate the retrieval of protocol state during EDHOC protocol execution.  EDHOC transports that do not inherently provide correlation across all messages of an exchange can send connection identifiers along with EDHOC messages to gain that required capability, e.g., by prepending the appropriate connection identifier </ins> (when available from the EDHOC protocol) to the EDHOC message. Transport of EDHOC in CoAP payloads is described in coap, which also shows how to use connection identifiers and message_1 indication with CoAP. <del> The Initiator and the Responder need to have agreed on a transport to be used for EDHOC, see applicability. </del> 3.5. EDHOC enables public-key based authentication and supports various

Discussion:
There was quite a lot of overlap between 3.3.2 and 3.4. Tried to integrate 3.3.2 in 3.4 to avoid that.