jiebi/CodeConvo huggingface dataset:
"psk_key_exchange_modes" from the ClientHelloInner into the ClientHelloOuter. <ins> When the client offers the "early_data" extension in ClientHelloInner, it MUST also include the "early_data" extension in ClientHelloOuter.  This allows servers that reject ECH and use ClientHelloOuter to safely ignore any early data sent by the client per RFC8446, Section 4.2.10. </ins> [[OPEN ISSUE: We currently require HRR-sensitive parameters to match in ClientHelloInner and ClientHelloOuter in order to simplify client- side logic in the event of HRR.  See https://github.com/tlswg/draft-
Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 <del> draft-ietf-tls-md5-sha1-deprecate-04 </del> <ins> draft-ietf-tls-md5-sha1-deprecate-05 </ins> Abstract <del> The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </del> <ins> The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack and this document deprecates their use in TLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1.
recommended) as defined by RFC8447.  The following entries are to be updated: <del> Other entries of the resgistry remain the same. </del> <ins> Other entries of the registry remain the same. </ins> 9. Concerns with TLS 1.2 implementations falling back to SHA-1 is an <del> issue.  This draft updates the TLS 1.2 specification to deprecate </del> <ins> issue.  This document updates the TLS 1.2 specification to deprecate </ins> support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.
2. <del> Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms 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 (for example, when using PSK ciphers). </del> <ins> Clients MUST include the signature_algorithms extension.  Clients MUST NOT include MD5 and SHA-1 in this extension. </ins> 3.
4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. <del> If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange message it MUST abort the connection with the illegal_parameter alert. </del> <ins> If no other signature algorithms are available (for example, if the client does not send a signature_algorithms extension), the server MUST abort the handshake with a handshake_failure alert or select a different cipher suite. </ins> 5.
6. <del> RFC5246, The Transport Layer Security (TLS) Protocol Version 1.2, suggests that implementations can assume support for MD5 and SHA-1 by their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. In Section 7.4.1.4.1: the text should be revised from: OLD: "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." NEW: "Note: This is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports SHA-256." 7. </del> 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
[RFC5246][RFC8447][RFC-to-be] <del> 8. </del> <ins> 7. </ins> Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue.  This document 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> 8. </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
The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not <del> deprecate SHA-1 in HMAC for record protection. </del> <ins> deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1. The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified in RFC5246.  MD5 and SHA-1 have been proven to be insecure, <del> subject to collision attacks.  RFC6151 details the security considerations, including collision attacks for MD5, published in 2011.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms 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 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. </del> <ins> subject to collision attacks Wang.  In 2011, RFC6151 detailed the security considerations, including collision attacks for MD5.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms 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 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.
their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. <ins> In Section 7.4.1.4.1: the text should be revised from: </ins> OLD: <del> In Section 7.4.1.4.1: the text should be revised from " Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </del> <ins> "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </ins> NEW:
(TLS) and Datagram Transport Layer Security (DTLS) recommends use of SHA-256 as a minimum requirement.  This update moves the minimum recommendation to use stronger language deprecating use of both SHA-1 <del> and MD5.  The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated. </del> <ins> and MD5.  The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated.. </ins> Section 4.3:
Servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. <del> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details). Clients MUST indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. </del> <ins> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details).  Clients MUST indicate to servers that they request SHA- 256, by using the "Signature Algorithms" extension defined in TLS 1.2. </ins> 8.
will typically be the minimum of the server's self-imposed limit and TicketRequestContents.count. <del> 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> <ins> A server that supports ticket requests MAY echo the "ticket_request" extension in the EncryptedExtensions message.  If present, it contains a TicketRequestContents structure, where TicketRequestContents.count indicates the number of tickets the server expects to send to the client. Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in either of these messages. </ins> If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second
IANA is requested to Create an entry, ticket_request(TBD), in the existing registry for ExtensionType (defined in RFC8446), with "TLS <del> 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del> <ins> 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </ins> 5.
4.2. <del> WebTransport clients can initiate bidirectional streams by opening an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type </del> <ins> WebTransport endpoints can initiate bidirectional streams by opening an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type </ins> "WEBTRANSPORT_STREAM" (type=0x41).  The format of the frame SHALL be the frame type, followed by the session ID, encoded as a variable- length integer, followed by the user-specified stream data (fig-bidi- client).  The frame SHALL last until the end of the stream. <del> 4.3. </del> <ins> HTTP/3 does not by itself define any semantics for server-initiated bidirectional streams.  If WebTransport setting is negotiated by both endpoints, the syntax of the server-initiated bidirectional streams SHALL be the same as the syntax of client-initated bidirectional streams, that is, a sequence of HTTP/3 frames.  The only frame defined by this document for use within server-initiated bidirectional streams is WEBTRANSPORT_STREAM. </ins> <del> WebTransport servers can initiate bidirectional streams by opening a bidirectional stream within the HTTP/3 connection.  Note that since HTTP/3 does not define any semantics for server-initiated bidirectional streams, this document is a normative reference for the semantics of such streams for all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated.  The format of those streams SHALL be the session ID, encoded as a variable-length integer, followed by the user-specified stream data (fig-bidi- server). </del> <ins> TODO: move the paragraph above into a separate draft; define what happens with already existing HTTP/3 frames on server-initiated bidirectional streams. </ins> <del> 4.4. </del> <ins> 4.3. </ins> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the
Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  Using coding can be a useful way to better deal with tail losses or with networks with non- <del> congestion losses.  However, coding mechanisms could hide congestion signals to the server.  This memo proposes a discussion on how coding and congestion signals could interact and proposes best current practice. </del> <ins> congestion losses.  However, coding mechanisms should not hide congestion signals.  This memo offers a discussion of how coding and congestion control interact. </ins> 1.
it is not an IETF product and is not a standard. There are cases where deploying coding improves the quality of the <del> transmission.  As example, the server may hardly detect tail losses that impact may impact the application layer.  Another example may be the networks where non-congestion losses are persistent and prevent the server from exploiting the link capacity.  RFC5681 defines TCP as a loss-based congestion control and coding mechanisms can hide congestion signals to the server. </del> <ins> transmission.  As an example, the server may hardly detect tail losses that impact may impact the application layer [MICHAEL: I don't understand this.  Why would it not detect them?  And why is detecting them the problem?].  Another example are networks where non- congestion losses are persistent and prevent a sender from exploiting the link capacity.  RFC5681 defines TCP as a loss-based congestion control; because coding repairs such losses, blindly applying it may easily lead to an implementation that also hides a congestion signal to the sender.  It is important to ensure that such information hiding does not occur. </ins> Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  This memo discusses
consider congestion control aspects when proposing coding solutions. The proposed recommendations apply for coding at the transport or <del> application layer and coding for tunnels is out-of-the scope of the </del> <ins> application layer.  Coding for tunnels is out of scope for the </ins> document. 2. fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward <del> Erasure Correction (FEC) channels.  Congestion Control channel carries data packets (from the server to the client) and a potential </del> <ins> Erasure Correction (FEC) channels.  The Congestion Control channel carries data packets (from a server to a client) and a potential </ins> information signaling the packets that have been received (from the <del> client to the server).  Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. </del> <ins> client to the server).  The Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. Inside a host, the CC and FEC entities can be regarded as conceptually separate: As this diagram shows, the inputs to FEC (data to work upon, and signaling from the receiver about losses and/or repaired blocks) are distinct from the inputs to CC.  The latter calculates a sending rate or window from network measurements, and it takes the data to send as input, sometimes along with application requirements such as upper/ lower rate bounds, periods of quiescence, or a priority. It is not clear that the ACK signals feeding into a congestion control algorithm are useful to FEC in their raw form, and vice versa - information about repaired blocks may be quite irrelevant to a CC algorithm.  However, there can be meaningful other interactions (indicated by the horizontal double arrow) between the two entities, usually as a result of their operation rather than by relaying their own raw inputs.  For example, the network measurements carried out by CC can yield a longer-term statistical measure such as a loss ratio which is useful input for a FEC coding scheme.  Similarly, unequal error protection using fountain codes can be used to assign different priorities to blocks of data, and these priorities can be honored by a CC mechanism. </ins> 3.
3.2. <del> The document focuses on end-to-end coding, i.e. in cases where coding is added at the server and client end points.  The discussions should </del> <ins> The document focuses on end-to-end coding, i.e. cases where coding is added at the server and client end points.  The discussions should </ins> then consider fairness with non-coding solutions. 4. <del> The solution can be described as follows: </del> <ins> The solution can be described as follows: [MICHAEL: So far, it hasn't been clear that we're going to describe a "solution".  A solution to which problem?  I thought we're only discussing how FEC and CC relate.] </ins> <del> The client MUST indicate to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </del> <ins> The client indicates to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </ins> <del> The server MUST be able to detect the "repaired packet" signal. </del> <ins> The server must be able to detect the "repaired packet" signal. </ins> The base solution does not describe how the congestion control reacts to such signal. The rationale behind this solution is the following: the server has more information on the congestion status and the application <del> characteristics.  Moreover, congestion control should not be splitted between multiple entities otherwise non-optimized decisions may be taken. </del> <ins> characteristics.  Moreover, congestion control should not be split between multiple entities, as otherwise non-optimized decisions may be taken. </ins> The proposed solution applies for coding in the transport and <del> application layers.  The proposed approach is inline with the one in </del> <ins> application layers.  The proposed approach is in-line with the one in </ins> I-D.swett-nwcrg-coding-for-quic.  The proposed solution does not <del> applies for the interaction between coding under the transport layer </del> <ins> apply for the interaction between coding under the transport layer </ins> (i.e. not end-to-end), such as coding for tunnels. 5.
In this solution, the coded packets are sent on top of what is allowed by a congestion window.  Examples of the solution could be <del> adding a given pourcentage of the congestion window as supplementary </del> <ins> adding a given percentage of the congestion window as supplementary </ins> packets or sending a given amount of coded packets at a given rate. The redundancy flow can be decorrelated from the congestion control <del> that manages source packets : a secondary congestion control can be </del> <ins> that manages source packets: a secondary congestion control can be </ins> introduced, such as in coupled congestion control for RTP media I- D.ietf-rmcat-coupled-cc.  An example would be to exploit a lower than best-effort congestion control RFC6297. <del> The advantage of such solution is that coding would help in challenges cases where transmission losses are persistent. </del> <ins> The advantage of such a solution is that coding would help in challenging cases where transmission losses are persistent. </ins> <del> The drawback of such solution is that it may result in coding </del> <ins> The drawback of such a solution is that it may result in coding </ins> solutions being unfair towards non-coding solutions.  This solutions may result in adding congestion in congested networks.
or preferably send coded packets instead of the following packets in the send buffer. <del> The advantage of this solution is that it does not contribute in adding more congestion than the congestion window allows.  Indeed, all traffic (source and redundancy) is controlled by one congestion control only and TCP metrics for fairness can be indifferently applied in this case. </del> <ins> The advantage of this solution is that it does not add more traffic than the congestion window allows.  Indeed, all traffic (source and redundancy) is controlled by one congestion control only and TCP metrics for fairness can be indifferently applied in this case. </ins> The main drawback is the decrease of goodput if coded packets are sent but are not used at the client side. 6. <del> Delay-based congestion controls ignore packets that have been repaired with coding.  There is no need to define best current </del> <ins> [MICHAEL: I would remove this section entirely: it only adds to confusion.  If the inputs are seen as distinct, and we say that the raw inputs shouldn't be shared, then why would one even think about what delay-based CC does with this input?  It's just not the right input.]  Delay-based congestion controls ignore packets that have been repaired with coding.  There is no need to define best current </ins> pratices in this case.  However, more discussions are required for congestion controls that use loss as congestion signals (potentially among other congestion detection mechanism). 6.1. <del> In this solution, the server reacts to repaired packet signals as to congestion-implied packet losses.  That being said, this does not necessarily means that the packets have actually been lost.  The server may have other means to identify that the packet was just out- of-ordered and ignore the repaired packet signals. </del> <ins> [MICHAEL: As above, lets remove all of this please.  This text gets in the way of a clean separation.]  In this solution, the server reacts to repaired packet signals as to congestion-implied packet losses.  That being said, this does not necessarily mean that the packets have actually been lost.  The server may have other means to identify that the packet was just out-of-order and ignore the repaired packet signals. </ins> The advantages of the solution are (1) that coding mechanisms do not hide congestion signals, such as packets voluntary dropped by a AQM <del> RFC7567 and (2) packets may be repaired faster than with traditionnal retransmission mechanisms. </del> <ins> RFC7567 and (2) packets may be repaired faster than with a traditional retransmission mechanisms. </ins> The drawback of this solution is that, if there is a high non- congestion loss rate, the congestion control throughput may decrease
6.2. <del> In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </del> <ins> [MICHAEL: this is even just a terrible idea.  There's no good rationale to back off less when a packet is repaired.]  In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </ins> The advantage of the solution is that in cases where there is no actual congestion, coding could help in improving the transmission