jiebi/CodeConvo huggingface dataset:
Change:
Addresses , , and .
Replace Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 with Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2
Add the following to the WANG reference: URL Replace: URL with URL and URL with URL
replace Dell with CIS/Center for Internet Security (CIS)

Discussion:
<del> Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 </del> <ins> Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2 </ins> draft-ietf-tls-md5-sha1-deprecate-07 Abstract
Change:
 We might say that the CABF action was deprecation for use in certificate signatures (not that CABF is likely to be concerned about other uses of SHA1, of course). I don't see much harm in adding "illegal_parameter" to the list of allowed alerts here, as Hubert proposed.  It's otherwise the natural thing to do if an algorithm is received in CertificateVerify that was not advertised in the signature algorithms extension. Sean's proposal at https://mailarchive.ietf.org/arch/msg/tls/rSbXvNPhmr27z0HOBzwv6x0j1mI/ (which makes "illegal_parameter" the only alert) seems like it ought to work.

Discussion:
attacks were practical.  This document updates RFC5246 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> Note that the CABF has also deprecated use of SHA-1 CABF. </del> <ins> Note that the CABF has also deprecated use of SHA-1 for use in certificate signatures CABF. </ins> 1.1.
Change:
replying with handshakefailure when server breaks protocol invariants isn't a good idea, make the behaviour conditional on values in signaturealgorithms (since this is the normal behaviour a client should exhibit when a signature algorithm is disabled, this does not actually increase complexity of the implementation)

Discussion:
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message. If client does receive a MD5 or SHA-1 signature in the <del> ServerKeyExchange message it MUST abort the connection with handshake_failure or insufficient_security alert. </del> <ins> ServerKeyExchange message and it sent one in signature_algorithms extensions it MUST abort the connection with handshake_failure or insufficient_security alert.  If client did not send MD5 nor SHA-1 hash algorithm in signature_algorithms extension and it receives a MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the connection with the illegal_parameter alert. </ins> 5.
Change:
As per discussion on mailing list.
NAME can you please float this change on the mailing list?

Discussion:
on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates <del> RFC5246 and RFC7525 in such as way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </del> <ins> RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </ins> 1.1.

2. <del> Clients SHOULD NOT include MD5 and SHA-1 in the signature_algorithms </del> <ins> Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms </ins> extension.  If a client does not send a signature_algorithms extension, then the server MUST abort the handshake and send a handshake_failure alert, except when digital signatures are not used

3. Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest <del> message. </del> <ins> messages. </ins> 4. <del> Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message. If client does receive a MD5 or SHA-1 signature in the ServerKeyExchange message and it sent one in signature_algorithms extensions it MUST abort the connection with handshake_failure or insufficient_security alert.  If client did not send MD5 nor SHA-1 hash algorithm in signature_algorithms extension and it receives a MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the connection with the illegal_parameter alert. </del> <ins> Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange message it MUST abort the connection with the illegal_parameter alert. </ins> 5. <del> Clients MUST NOT include MD5 and SHA-1 in CertificateVerify message. If the server receives a CertificateVerify message with MD5 or SHA-1 it MUST abort the connection with handshake_failure or </del> <ins> Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1 it MUST abort the connection with handshake_failure or </ins> insufficient_security alert. 6.
Change:
SHA-1 entries in the signature scheme registry should not be recommended this pull request creates an IANA considerations section to remove the recommended status.
Partially addresses .
Please address the following IDNits: -- The document seems to lack an IANA Considerations section. (See Section 2.2 of URL for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7525, but the abstract doesn't seem to mention this, which it should. Section 1. Editorial. -- s/RFC 5246 [RFC5246]/[RFC5246]/ -- s/RFC 6151 [RFC6151]/[RFC6151]/ -- s/RFC7525 [RFC7525]/[RFC7525]/ Section 1. Editorial. For symmetry with the rest of the text: OLD RFC 6151 [RFC6151] details the security considerations, including collision attacks for MD5, published in 2011. NEW In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. Section 1. Please provide a reference for "Wang, et al". Is there a reference to provide for the "the potential for brute-force attack" Section 6. Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/ Section 6. Move the text "In Section 7.4.1.4.1: the text should be revised from" out of the "OLD" block of text to be its own intro paragraph so that the OLD vs. NEW is a clear cut-and-paste. Section 7. Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/ Section 7. SHA-1 is also not mentioned in RFC7525. Recommend: OLD The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated. NEW The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated. Section 7. Editorial. Grammar. OLD In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used NEW In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used Section 10.2 Please make RFC5246 a normative reference.
This looks good to merge!

Discussion:
8. <ins> The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be updated: Other entries of the resgistry remain the same. 9. </ins> Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue.  This draft updates the TLS 1.2 specification to deprecate support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> 9. </del> <ins> 10. </ins> The authors would like to thank Hubert Kario for his help in writing the initial draft.  We are also grateful to Daniel Migault, Martin
Change:
I don't think any of this paragraph should have 2119 language in it. But, even overlooking that minor disagreement, it's important to avoid unintentional requirements. I think my edit guides well-meaning implementors, while making no guarantees.
This editorial change is fine by me.

Discussion:
discard any additional tickets.  Servers SHOULD additionally place a limit on the number of tickets they are willing to send, to save resources.  Therefore, the number of NewSessionTicket messages sent <del> will be the minimum of the server's self-imposed limit and </del> <ins> will typically be the minimum of the server's self-imposed limit and </ins> TicketRequestContents.count. Servers that support ticket requests MUST NOT echo "ticket_request"
Change:
Adding the text proposed in the email
Unless I am missing something, I believe that checking the IP address may be useful to filter packets that are outside the key exchange, but I do not see this as a counter measure to the amplification attack. With a single round trip, unless i am missing something, I do not see how the server can verify the Client's IP address. It receives the ClientHello responds with the ServerHello..Finished,NewSessionTickets. In other cases, the server received from the given IP address the ClientHello and the client Finished which I think proves that IP receives the the ServerHello and responds to it. Yours, Daniel
TLS has a cookie extension for this purpose, for example.
Thanks, looks good to me. Yours, Daniel
I agree with the change below and updated the text. OLD: Server should limit the number of NewSessionTicket messages sent in response to a "ticket_request" should be based on the applicability and the amplification factor of such attack. NEW Servers SHOULD limit the number of NewSessionTicket messages they send until they have verified the client's ownership of its IP address.
Great! We're just waiting on NAME
Approved pending Chris' last suggestion

Discussion:
dispose of pooled tickets after some reasonable amount of time that mimics the ticket rotation period. <ins> In some cases, a server may send NewSessionTicket messages immediately upon sending the server Finished message rather than waiting for the client Finished.  If the server has not verified the client's ownership of its IP address, e.g., with the TLS Cookie extension (see RFC8446; Section 4.2.2), an attacker may take advantage of this behavior to create an amplification attack proportional to the count value toward a target by performing a key exchange over UDP with spoofed packets.  Servers SHOULD limit the number of NewSessionTicket messages they send until they have verified the client's ownership of its IP address. </ins> Servers that do not enforce a limit on the number of NewSessionTicket messages sent in response to a "ticket_request" extension could leave themselves open to DoS attacks, especially if ticket creation is
Change:
"IV" is usually capitalized, and a couple of grammar nits. I couldn't figure out what "PRK" meant in the (generated) output; should that be expanded?
I think Sean had tried to clue me in a while ago, but I only just now realized, that it would be nice if this one could be in the same cluster as the core spec, but doing that (basically) requires going through IETF LC/etc. while the test vectors are still for a draft version. So I'd like to kick things off soon and we can see how long it takes. Please do drop a new rev, though; no need to have genart pester us again.

Discussion:
Examples of TLS 1.3 handshakes are shown.  Private keys and inputs are provided so that these handshakes might be reproduced. <del> Intermediate values, including secrets, traffic keys and ivs are </del> <ins> Intermediate values, including secrets, traffic keys and IVs are </ins> shown so that implementations might be checked incrementally against these values. 1. <del> TLS 1.3 TLS13 defines a new key schedule and a number new </del> <ins> TLS 1.3 TLS13 defines a new key schedule and a number of new </ins> cryptographic operations.  This document includes sample handshakes that show all intermediate values.  This allows an implementation to be verified incrementally, examining inputs and outputs of each

In this example, the simplest possible handshake is completed.  The server is authenticated, but the client remains anonymous.  After connecting, a few application data octets are exchanged.  The server <del> sends a session ticket that permits the use of 0-RTT in any resumed session. </del> <ins> sends a session ticket that permits the use of 0-RTT data in any resumed session. </ins>
Change:
Noticed we had a few oddly long lines, so I hit the rewrap button.
This was Sublime, but many others will attempt to do the same :)
What tool do you use that has a rewrap button?

Discussion:
multiplex HTTP requests over a QUIC connection.  This document defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a manner that conforms with the WebTransport protocol requirements and <del> semantics OVERVIEW.  Using the mechanism described here, multiple </del> <ins> semanticsOVERVIEW.  Using the mechanism described here, multiple </ins> WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/3 connection.
Change:
Fix up references to setting names
The draft uses both but I presume they refer to the same thing, so lets pick one.
Ah, left over from a previous change, I believe. is the correct form, can update to match.
Yep sgtm

Discussion:
from the one used by the server. In addition to the setting above, the server MUST send a <del> SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum </del> <ins> SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter indicating the maximum </ins> number of concurrent sessions it is willing to receive.  The default <del> value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", </del> <ins> value for the SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter is "0", </ins> meaning that the server is not willing to receive any WebTransport sessions.

3.4. <del> This document defines a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter </del> <ins> This document defines a SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter </ins> that allows the server to limit the maximum number of concurrent WebTransport sessions on a single HTTP/3 connection.  The client MUST NOT open more sessions than indicated in the server SETTINGS
Change:
This makes our behavior consistent with the regular CONNECT method.
The spec currently explicitly requires . suggests that any 2xx code should work. Should we change the text accordingly?
I'd suggest server MUST send 200 and client MUST accept any 2XX. That way future extensions can apply meaning to other 2XX codes.
What would happen if we require client to reject 2xx other than 200?

Discussion:
WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by <del> replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del> <ins> replying with a 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </ins> From the client's perspective, a WebTransport session is established <del> when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. </del> <ins> when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. </ins> WebTransport over HTTP/3 does not support 0-RTT. 3.4.
Change:
This PR keeps WebTransport in sync with the latest changes in draft-ietf-masque-h3-datagram.

Discussion:
Both client and server can create a unidirectional stream using a special stream type. <del> A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM. </del> <ins> A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM. </ins> An WebTransport session is terminated when the CONNECT stream that created it is closed.

may be using a version of WebTransport extension that is different from the one used by the server. <del> If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating HTTP/3 DATAGRAM support SHALL result in a H3_SETTINGS_ERROR error. </del> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

perspective, a session is established once it sends a 2xx response. WebTransport over HTTP/3 does not support 0-RTT. <ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM. </ins> 3.4. From the flow control perspective, WebTransport sessions count

4.4. <del> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow Identifier is set to the session ID.  In other words, the format of datagrams SHALL be the session ID, followed by the user-specified payload (fig-datagram). </del> <ins> Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT HTTP Datagram Format Type (see value in iana-format-type).  When using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport datagram payload is sent unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.  When sending a registration capsule using the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format Additional Data" field SHALL be empty. </ins> In QUIC, a datagram frame can span at most one packet.  Because of that, the applications have to know the maximum size of the datagram

WebTransport application error codes. This document. <ins> 7.6. This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM. </ins>
Change:
This change both describes the existing mechanism (SETTINGS). It also adds a header in the unlikely scenario that we would need to change capsule stream format (instead of just defining new capsules).

Discussion:
6. <ins> [[RFC editor: please remove this section before publication.]] WebTransport over HTTP/3 uses two different mechanisms to negotiate versions for the different parts of the draft. The hop-by-hop wire format aspects of the protocol are negotiated by changing the codepoint used for the SETTINGS_ENABLE_WEBTRANSPORT parameter.  Because of that, any WebTransport endpoint MUST wait for the peer's SETTINGS frame before sending or processing any WebTransport traffic.  When multiple versions are supported by both of the peers, the most recent version supported by both is selected. The data exchanged over the CONNECT stream is transmitted across intermediaries, and thus cannot be versioned using a SETTINGS parameter.  To indicate support for different versions of the protocol defined in this draft, the clients SHALL send a header for each version of the draft supported.  The header corresponding to the version described in this draft is "Sec-Webtransport-Http3-Draft02"; its value SHALL be "1".  The server SHALL reply with a "Sec- Webtransport-Http3-Draft" header indicating the selected version; its value SHALL be "draft02" for the version described in this draft. 7. </ins> WebTransport over HTTP/3 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework for client-server communication in cases when the

within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 7. </del> <ins> 8. </ins> <del> 7.1. </del> <ins> 8.1. </ins> The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230:

This document and <del> 7.2. </del> <ins> 8.2. </ins> The following entry is added to the "HTTP/3 Settings" registry established by HTTP3:

This document <del> 7.3. </del> <ins> 8.3. </ins> The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3:

This document <del> 7.4. </del> <ins> 8.4. </ins> The following entry is added to the "HTTP/3 Stream Type" registry established by HTTP3:

Both <del> 7.5. </del> <ins> 8.5. </ins> The following entry is added to the "HTTP/3 Error Code" registry established by HTTP3:

This document. <del> 7.6. </del> <ins> 8.6. </ins> This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM.
Change:
If a connection carrying WebTransport sessions receives a GOAWAY, is the sender allowed to continue 1) sending datagrams 2) creating new WT streams 3) receiving new WT streams I assume it's ok to continue sending data on already open WT streams and the CONNECT stream, but clarification would be good. Also, are the rules any different after sending a GOAWAY? Can the sender continue doing the above?
I'll just note that because in H2 WT streams are contained to a single stream, they are implicitly allowed there unless we forbid them.
Chair: discussed at IETF 113, consensus to have GOAWAY not prevent opening new WT streams on existing WT sessions. NAME will write a PR

Discussion:
datagram SHALL be dropped.  It is up to an implementation to choose what stream or datagram to discard. <ins> 4.6. HTTP/3 defines a graceful shutdown mechanism (Section 5.2 of HTTP3) that allows a peer to send a GOAWAY frame indicating that it will no longer accept any new incoming requests or pushes.  This mechanism applies to the CONNECT requests for new WebTransport sessions.  A GOAWAY frame does not affect data streams for existing WebTransport sessions; those can continue to be opened even after the GOAWAY frame has been sent or received. </ins> 5. A WebTransport session over HTTP/3 is considered terminated when