jiebi/CodeConvo huggingface dataset:
Change:
and the validation key material off the device.  Sometimes this procedure is referred to as personalization or customization. <ins> The keys generated in the factory, whether generated in the device or off-device by the factory SHOULD be generated by a Cryptographically Strong Sequence (RFC4086, Section 6.2). </ins> 12.1.2.1. One way to provision key material is to first generate it external to

Discussion:
** Section 12.1.2. I didn't see any of the obvious text that regardless of whether the key is generated on or off device, high quality randomness is needed.
Change:
An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  A <del> certificate_request_context value MUST NOT be repeated for multiple authenticator requests generated by the same party within the scope of a connection (thus preventing replay of authenticators).  The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from pre-computing valid authenticators.  This value is unrelated to the certificate_request_context used in post-handshake authentication and collisions do not need to be avoided. </del> <ins> certificate_request_context value MUST be unique for each authenticator request within the scope of a connection (preventing replay and context confusion).  The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from pre-computing valid authenticators.  This value is unrelated to the certificate_request_context used in post-handshake authentication and collisions do not need to be avoided. </ins> The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in

Discussion:
NAME The crc can be derived in two places: the authenticator request and the unsolicited authenticator. I want to make sure the requirement is clear in both places.
Issue raised by Jonathan Hoyland at IETF 102
So you just wanted to repeat the requirement? Because that first bit already said no repeats.
Change:
5.2. The Service Proxy function maps between App-flows and DetNet flows. <del> It MUST support the TSN Stream identification functions and the related managed objects as defined in IEEE8021CB and IEEEP8021CBdb to recognize the App-flow related packets. </del> <ins> The DetNet Edge Node TSN function MUST support the TSN Stream identification functions and the related managed objects as defined in IEEE8021CB and IEEEP8021CBdb to recognize the App-flow related packets.  The Service Proxy presents TSN Streams as an App-flow to a DetNet Flow. </ins> Implementations of this document SHALL use management and control information to map a TSN Stream to a DetNet flow.  N:1 mapping <del> (aggregating TSN Streams in a single DetNet flow) SHALL be supported. The management or control function that provisions flow mapping SHALL ensure that adequate resources are allocated and configured to provide proper service requirements of the mapped flows. </del> <ins> (aggregating multiple TSN Streams in a single DetNet flow) SHALL be supported.  The management or control function that provisions flow mapping SHALL ensure that adequate resources are allocated and configured to provide proper service requirements of the mapped flows. </ins> Due to the (intentional) similarities of the DetNet PREOF and TSN FRER functions service protection function interworking is possible

Discussion:
Work In progress - Wanted to get the figure changes out for review. Need to check if the overly wording is complete. There was a lot of inter working text - I have commented out.
Change:
The certificate type MUST be X.509v3 RFC5280, unless explicitly negotiated otherwise (e.g., RFC5081). <del> The end-entity certificate's public key (and associated restrictions) has to be compatible with the certificate types listed in CertificateRequest: </del> If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs.

Discussion:
This PR includes CertificateRequest changes discussed at the TLS WG Interim: Removes certificate_types, which are no longer needed. Adds client cert selection by certificate extension values. This helps make CertificateRequest more specific and eliminate the need for the confusing "Choose a certificate" UI.
Change:
from version B.  As an example, if versions A and B are absolutely equal in their wire image and behavior during the handshake but differ after the handshake, then A is compatible with B and B is <del> compatible with A. </del> <ins> compatible with A.  Note that the conversion of the first flight can be lossy: some data such as QUICv1 0-RTT packets could be ignored during conversion and retransmitted later. </ins> Version compatibility is not symmetric: it is possible for version A to be compatible with version B and for B not to be compatible with

Discussion:
This is NAME 's proposed text to fix this issue.
LGTM. I am going to merge this on the basis of it being David's text and my approval.
LGTM
Section 9 is pretty clear that 'compatible versions' might not have commonly usable 0-RTT packets. But Section 3 defines 'compatible' as a translatable first flight. 0-RTT is part of the first flight, so one of these definitions has to change.
That doesn't necessarily follow. You can translate a first flight in a way that 0-RTT is rejected and the 0-RTT packets are just dropped and the handshake will still succeed. I'm not sure I see an inconsistency here.
Having read sec 3 a few times now, I see the subtlety in your point. 0-RTT could fall under the third paragraph as something that can't be included to be compatible. I still don't really like the definition. I'll think on it some more, but I'd prefer something like "A is said to be 'compatible' with B if the first flight of A contains all the information minimally necessary to complete a first flight of B." So to be compatible with v1 , vx needs to contain a TLS 1.3 client hello including TPs for version negotiation and all the other required v1 TPs. For v1 to be compatible with vx, v_x must not have any additional information to complete its first fligth besides the client hello at the v1 TPs. Whether or not there's 0-RTT in the flight doesn't matter. We are drifting into the editorial, but if you like that definition I'm happy to write a PR.
I'm not sure "minimally necessary" is well-defined. How about something like:
Change:
have each other's stateless reset token unless that key has changed in the interim. <del> The Stream Cipher and Block Cipher algorithms need to generate </del> <ins> The Encrypted Short and Encrypted Long algorithms need to generate </ins> different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique

Discussion:
Some have noted that "Stream Cipher" is now a misnomer. So this PR renames them.
Change:
1. <del> An objective of Privacy-Enhanced RTP Conferencing (PERC) is to ensure that endpoints in a multimedia conference have access to the end-to- end (E2E) and hop-by-hop (HBH) keying material used to encrypt and authenticate Real-time Transport Protocol (RTP) RFC3550 packets, while the Media Distributor has access only to the hop-by-hop (HBH) keying material for encryption and authentication. </del> <ins> An objective of Privacy-Enhanced RTP Conferencing (PERC) RFC8871 is to ensure that endpoints in a multimedia conference have access to the end-to-end (E2E) and hop-by-hop (HBH) keying material used to encrypt and authenticate Real-time Transport Protocol (RTP) RFC3550 packets, while the Media Distributor has access only to the hop-by- hop (HBH) keying material for encryption and authentication. </ins> This specification defines a tunneling protocol that enables the media distributor to tunnel DTLS RFC6347 messages between an endpoint

Discussion:
Changes for -07 of the tunnel draft include: Updated references Change status to informational Align terminology with newer UKS draft
LGTM
LGTM
Change:
The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document <del> except DH_anon and PSK).  This message will always immediately follow the EncryptedExtensions message. </del> <ins> except PSK).  This message will always immediately follow the EncryptedExtensions message. </ins> Meaning of this message:

Discussion:
…che).
Aside from the little nits and typo, the text itself looks good to me.
Change:
Specifies a recommended set of elliptic curve domain parameters.  All those values of NamedCurve are allowed that refer to a curve capable of Diffie-Hellman.  With the deprecation of the explicit curves, this <del> now includes all values of NamedCurve except Ed25519(TBD3) and Ed448(TBD4). </del> <ins> now includes all values of NamedCurve except eddsa_ed25519(TBD3) and eddsa_ed448(TBD4). </ins> Specifies the elliptic curve domain parameters associated with the ECDH public key.

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:
value "nonce" using the input challenge and Issuer key identifier as follows: <del> The Client then creates a TokenRequest structured as follows: </del> <ins> If the Blind step fails, the Client aborts the protocol.  Otherwise, the Client then creates a TokenRequest structured as follows: </ins> The structure fields are defined as follows:

Discussion:
draft-irtf-cfrg-voprf-09 went out today, and this just aligns the basic issuance protocol on top of those changes. cc NAME
Change:
Connection establishment implicitly provides address validation for both endpoints.  In particular, receipt of a packet protected with <del> Handshake keys confirms that the client received the Initial packet from the server.  Once the server has successfully processed a Handshake packet from the client, it can consider the client address to have been validated. </del> <ins> Handshake keys confirms that the peer successfully processed an Initial packet.  Once an endpoint has successfully processed a Handshake packet from the peer, it can consider the peer address to have been validated. </ins> <del> Additionally, a server MAY consider the client address validated if the client uses a connection ID chosen by the server and the </del> <ins> Additionally, an endpoint MAY consider the peer address validated if the peer uses a connection ID chosen by the endpoint and the </ins> connection ID contains at least 64 bits of entropy. <ins> For the client, the value of the Destination Connection ID field in its first Initial packet allows it to validate the server address as a part of successfully processing any packet.  Initial packets from the server are protected with keys that are derived from this value (see Section 5.2 of QUIC-TLS).  Alternatively, the value is echoed by the server in Version Negotiation packets (version-negotiation) or included in the Integrity Tag in Retry packets (Section 5.8 of QUIC- TLS). </ins> Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received.  This limits the magnitude of any amplification attack that

Discussion:
The issue suggests that any packet from the server validates the server's address, because it echoes the client's CID. I'm not sure that's correct, because the client might have chosen a zero-length SCID in its initial packet, and the server doesn't echo the ODCID in Initial packets. This PR generalizes the existing rules for servers -- receiving a sufficiently-complex DCID or a valid Handshake packet is actual proof of address ownership.
The address validation section dives right into what a server needs to do to validate the client, but it doesn't really address the client needs. This is pretty simple: any valid packet from the server validates the server address via the client-chosen destination connection ID. We just need to write that down here (it might be elsewhere, I would need to check).
Change:
4. <del> The signed contents of Internet-Drafts are primarily intended to be consumed by people.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by people, implementations MAY perform the steps below during certificate validation: </del> <ins> Our intended use case is people consuming the contents of signed documents.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by people, implementations MAY perform the steps below during certificate validation: </ins> The following procedure is used to examine the KeyPurposeId(s) included in the Extended Key Usage extension.  Restrictions on

Discussion:
Addressing Lars' .
Debating adding more context than just "document". Thanks to Dale Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/1T23l8-kN8pEMqnQvh1ir3MsGVw). Did you mean "documents" here instead of "Internet-Drafts"? All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. File types are normally capitalized. A period is needed after the abbreviation "etc.".
Change:
a context that has a different origin than the top-level browsing context), or a private browsing context. <ins> 6.5. Even when local IP addresses are not exposed, the number of mDNS hostname candidates can still provide a fingerprinting dimension. This is in particular the case for network interfaces with limited connectivity that will not generate server-reflexive or relay candidates. The more mDNS names an endpoint exposes through mDNS hostname candidates, the higher the fingerprinting risk.  One countermeasure is to limit this number to a small value. Note that no additional fingerprinting risk is introduced when restricting mDNS hostname candidates to default route only. </ins> 7. 7.1.

Discussion:
Original text: I'm not sure this provides an actual new fingerprinting surface - assuming the interface is in fact exposed to the outside world, a srflx candidate will also be generated for each mDNS candidate - and in the mode we are most concerned about, Mode 2, there will either be 1 or 2 mDNS candidates.
If we decide that this draft only applies to mode 2 or default routes, I agree that there is no fingerprinting surface. However, that assumption hasn't been called out anywhere in this doc AFAIK.
We still get a srflx and TURN candidate for each interface though.
Ok, good point. I agree, we should remove that paragraph. I'll create a PR
If an interface cannot connect to a STUN server, there will be no srflx candidate. I don’t think we can assume that such interface will also not support multicast.
Right, as noted in the OP, but this seems like an edge case.
I think it is better to mention an issue even though this is an edge case. Something like: If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates might provide a fingerprinting dimension. This is in particular the case for network interfaces whose existence are not exposed through other means like provided STUN servers. No new information is provided when exposing default route candidates.
Filed URL to follow up on that.
Approved with minor suggestions
Change:
Destination Connection ID of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that <del> the Version Negotiation packet was not generated by an off-path attacker. </del> <ins> the Version Negotiation packet was not generated by an entity that did not observe the Initial packet. </ins> Future versions of QUIC could have different requirements for the lengths of connection IDs.  In particular, connection IDs might have

Discussion:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.
Change:
m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. <ins> If present in the offer, an "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4.3. </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5.

Discussion:
Line 2589: "I don't think this is quite right. I imagine this should probably echo the above, e.g. MUST only be added if present in the most recent answer."
So re-review this one and see if you are OK with it as is.
This seems fine.
JSEP should probably point at the draft and include the attribute on every (applicable) media section.
Agreed
Change:
the request SHALL include a single Host header field containing the origin of the UDP proxy. <del> the request SHALL include a single "Connection" header field with value "Upgrade" (note that this requirement is case-insensitive as per HTTP). </del> <ins> the request SHALL include a "Connection" header field with value "Upgrade" (note that this requirement is case-insensitive as per HTTP). </ins> the request SHALL include a single "Upgrade" header field with value "connect-udp".

Discussion:
"Upgrade" (note that this requirement is case-insensitive as per {{Section 7.6.1 of HTTP}}). "Single" implies that there can't be other values (at least in other header lines, and possibly this one). That's an inappropriate constraint.
Thanks for catching this oversight, fixing via .
Change:
The cipher suite identifier. <del> If (EC)DHE is being used, the server's version of "key_share". </del> <ins> If (EC)DHE is being used, the server's version of the "key_share" extension. </ins> If PSK is being used, the server's version of the "pre_shared_key" <del> (indicating the PSK the client is using). </del> <ins> extension (indicating the PSK the client is using). </ins> 6.3.2.5.2.

Discussion:
This should be "chose" not "choosed", which isn't really an accepted word.
Added another commit here for a minor wording fix that snuck in with changing all extensions to be referred to by type ID name.
Ok, I switched it to "chooses" instead & squashed my little fixes together here. There's also a fix for the "will MAY" bit that I think we discussed at some point but its fix didn't get in.
Change:
includes its assigned EST domain in the est-domain attribute. At this stage, the Pledge should be able to establish a TLS channel <del> with the EST Registrar.  The connection may involve crossing the </del> <ins> with the EST server.  The connection may involve crossing the </ins> Internet requiring a DNS lookup on the provided name.  It may also be a local address that includes an IP address literal including both <del> RFC1918 and IPv6 Unique Local Address.  The EST Registrar is validated using the pinned-domain-cert value provided in the voucher as described in BRSKI section 5.6.2.  This involves treating the </del> <ins> RFC1918 and IPv6 Unique Local Address.  The EST server is validated using the pinned-domain-cert value provided in the voucher as described in BRSKI section 5.6.2.  This involves treating the </ins> artifact provided in the pinned-domain-cert as a trust anchor, and <del> attempting to validate the EST Registrar from this anchor only. </del> <ins> attempting to validate the EST server from this anchor only. </ins> There is a case where the pinned-domain-cert is the identical End- <del> Entity (EE) Certificate as the EST Registrar.  It also explicitly includes the case where the EST Registrar has a self-signed EE </del> <ins> Entity (EE) Certificate as the EST server.  It also explicitly includes the case where the EST server has a self-signed EE </ins> Certificate, but it may also be an EE certificate that is part of a larger PKI.  If the certificate is not a self-signed or EE certificate, then the Pledge SHOULD apply RFC6125 DNS-ID validation

Discussion:
what is the "EST Registrar"? It is not defined so far. Wouldn't it be better to use RFC 8995 terminology of "EST server" ? So if the cloud Registrar supplies the Voucher and that redirects to an owner's EST server, we can call that "EST server" or "owner EST server". It's not a Registrar, so not "EST Registrar" or "owner Registrar". The latter term is already used for the server that provides a voucher to the pledge. (Interesting to consider that the owner's EST server could be a Registrar i.e. handing out vouchers in theory, even if the cloud-Registrar-supporting-pledge already got its voucher from the cloud-Registrar. But let's not say such things in the document to avoid complicating it.)
Change:
to the capabilities available to applications.  Therefore, all Application Layer Protocol Negotiation (ALPN) (RFC7301) codepoints specified to operate over QUICv1 can also operate over this version <del> of QUIC. </del> <ins> of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUICv2. </ins> All QUIC extensions defined to work with version 1 also work with version 2.

Discussion:
Now that DoQ is in the RFCEd queue, this draft should specifically state it is compatible with both registered ALPNs.
Change:
Close: The action an application takes on a Connection to indicate that it no longer intends to send data, is no longer willing to receive data, and that the protocol SHOULD signal this state to <del> the remote system if the transport protocol allows this. </del> <ins> the remote system if the transport protocol allows this.  (Note that this is distinct from the concept of "half-closing" a bidirectional connection, such as when a FIN is sent in one direction of a TCP connection.  Indicating the end of a stream in the Transport Services architecture is possible using Message Properties when sending.) </ins> Abort: The action the application takes on a Connection to indicate a Close and also indicate that the transport system

Discussion:
Completes
Close: The way this is written suggests that the API doesn't support half closed connections. That may be reasonable, but it's a limitation. If intended, can it be made explicit.
This is perfect IMO!lgtm, thanks!