jiebi/CodeConvo huggingface dataset:
"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, <del> as shown here.  All TLS notation comes from RFC8446; Section 3. </del> <ins> as shown here.  All TLS notation comes from RFC8446, Section 3. </ins> 3.
maximum_name_length is greater than 256. A list of extensions that the client can take into consideration <del> when generating a Client Hello message.  The purpose of the field is to provide room for additional features in the future.  The format is defined in RFC8446; Section 4.2.  The same interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block.  An extension may be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.  A client which receives a mandatory extension they do not understand must reject the ECHOConfig content. </del> <ins> when generating a ClientHello message.  The purpose of the field is to provide room for additional functionality in the future. See config-extensions for guidance on what type of extensions are appropriate for this structure. The format is defined in RFC8446, Section 4.2.  The same interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block.  An extension can be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.  A client which receives a mandatory extension they do not understand MUST reject the ECHOConfig content. </ins> Clients MUST parse the extension list and check for unsupported mandatory extensions.  If an unsupported mandatory extension is
9.2. A more serious problem is MITM proxies which do not support this <del> extension.  RFC8446; Section 9.3 requires that such proxies remove </del> <ins> extension.  RFC8446, Section 9.3 requires that such proxies remove </ins> any extensions they do not understand.  The handshake will then present a certificate based on the public name, without echoing the "encrypted_client_hello" extension to the client.
IANA is requested to create an entry, echo_required(121) in the existing registry for Alerts (defined in RFC8446), with the "DTLS-OK" column being set to "Y". <ins> 12. Any future information or hints that influence the outer ClientHello SHOULD be specified as ECHOConfig extensions, or in an entirely new version of ECHOConfig.  This is primarily because the outer ClientHello exists only in support of ECHO.  Namely, it is both an envelope for the encrypted inner ClientHello and enabler for authenticated key mismatch signals (see server-behavior).  In contrast, the inner ClientHello is the true ClientHello used upon ECHO negotiation. </ins>
match a value provided in the corresponding "ECHConfig.cipher_suites" list. <del> A cryptographic hash of the "ECHConfig" structure from which the ECH key was obtained, i.e., from the first byte of "version" to the end of the structure.  This hash is computed using the hash function associated with "cipher_suite", i.e., the corresponding HPKE KDF algorithm hash. </del> <ins> Equal to "Expand(Extract("", config), "ech_config_digest", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF. (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "encrypted_ch" field.
When sending ClientHello, the client first computes ClientHelloInner, including any PSK binders, and then MAY substitute extensions which it knows will be duplicated in ClientHelloOuter.  To do so, the <del> client computes a hash of the entire ClientHelloInner message with the same hash as for the KDF used to encrypt ClientHelloInner.  Then, the client removes and replaces extensions from ClientHelloInner with a single "outer_extensions" extension.  The list of "outer_extensions" include those which were removed from </del> <ins> client computes a hash of the entire ClientHelloInner message as: where "inner" is the ClientHelloInner structure and "Extract", "Expand", and "Nh" are as defined by the KDF API in I-D.irtf-cfrg- hpke.  Then, the client removes and replaces extensions from ClientHelloInner with a single "outer_extensions" extension.  The list of "outer_extensions" include those which were removed from </ins> ClientHelloInner, in the order in which they were removed.  The hash contains the full ClientHelloInner hash computed above.
server in the same session. Set the "config_digest" field to a randomly-generated string of <del> hash_length bytes, where hash_length is the length of the hash function associated with the chosen HpkeCipherSuite. </del> <ins> "Nh" bytes, where "Nh" is the output length of the "Extract" function of the KDF associated with the chosen cipher suite.  (The KDF API is specified in I-D.irtf-cfrg-hpke.) </ins> Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM.
ClientEncryptedCH.encrypted_ch.  This matching procedure should be done using one of the following two checks: <del> Compare ClientEncryptedCH.config_digest against cryptographic hashes of known ECHConfig and choose the one that matches. </del> <ins> Compare ClientEncryptedCH.config_digest against digests of known ECHConfig and choose the one that matches. </ins> Use trial decryption of ClientEncryptedCH.encrypted_ch with known ECHConfig and choose the one that succeeds.
When a client wants to establish a TLS session with the backend server, it constructs its ClientHello as usual (we will refer to this as the ClientHelloInner message) and then encrypts this message using <del> the ECH public key.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with the encrypted ClientHelloInner in an </del> <ins> the public key of the ECH configuration.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with an </ins> "encrypted_client_hello" extension, which this document defines <del> (encrypted-client-hello).  Finally, it sends ClientHelloOuter to the server. </del> <ins> (encrypted-client-hello).  The extension's payload carries the encrypted ClientHelloInner and specifies the ECH configuration used for encryption.  Finally, it sends ClientHelloOuter to the server. </ins> Upon receiving the ClientHelloOuter, the client-facing server takes one of the following actions:
"encrypted_client_hello" extension and proceeds with the handshake as usual, per RFC8446, Section 4.1.2. <del> If it supports ECH but cannot decrypt it, then it ignores the extension and proceeds with the handshake as usual.  This is </del> <ins> If it supports ECH but does not recognize the configuration specified by the client, then it ignores the extension and terminates the handshake using the ClientHelloOuter.  This is </ins> referred to as "ECH rejection".  When ECH is rejected, the server sends an acceptable ECH configuration in its EncryptedExtensions message. <del> If it supports ECH and can decrypt it, then it forwards the ClientHelloInner to the backend, who terminates the connection. This is referred to as "ECH acceptance". </del> <ins> If it supports ECH and recognizes the configuration, then it attempts to decrypt the ClientHelloInner.  It aborts the handshake if decryption fails; otherwise it forwards the ClientHelloInner to the backend, who terminates the connection.  This is referred to as "ECH acceptance". </ins> Upon receiving the server's response, the client determines whether ECH was accepted or rejected and proceeds with the handshake
If sending a second ClientHello in response to a HelloRetryRequest, the client copies the entire "encrypted_client_hello" extension from <del> the first ClientHello. </del> <ins> the first ClientHello.  The identical value will reveal to an observer that the value of "encrypted_client_hello" was fake, but this only occurs if there is a HelloRetryRequest. </ins> If the server sends an "encrypted_client_hello" extension in either HelloRetryRequest or EncryptedExtensions, the client MUST check the
extension.  It MUST NOT save the "retry_config" value in EncryptedExtensions. <del> [[OPEN ISSUE: Depending on what we do for issue#450, it may be appropriate to change the client behavior if the HRR extension is present.]] </del> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in real-ech.  In particular, the client MAY offer to resume sessions established without ECH.
The backend server begins by generating a message ServerHelloECHConf, which is identical in content to a ServerHello message with the exception that ServerHelloECHConf.random is equal to 24 random bytes <del> followed by 8 zero bytes.  It then computes a string where Derive-Secret and Handshake Secret are as specified in RFC8446, Section 7.1, and ClientHelloInner...ServerHelloECHConf refers to the sequence of handshake messages beginning with the first ClientHello and ending with ServerHelloECHConf.  Finally, the backend server constructs its ServerHello message so that it is equal to </del> <ins> followed by 8 zero bytes.  It then computes an 8-byte string where HKDF-Expand-Label and Transcript-Hash are as defined in RFC8446, Section 7.1, "0" indicates a string of Hash.length bytes set to zero, and ClientHelloInner...ServerHelloECHConf refers to the sequence of handshake messages beginning with the first ClientHelloInner and ending with ServerHelloECHConf.  (Note that ClientHelloInner and ServerHelloECHConf messages replace the ClientHello and ServerHello messages in the transcript hash sequence as specified in Section 4.1.1 of RFC8446.  Finally, the backend server constructs its ServerHello message so that it is equal to </ins> ServerHelloECHConf but with the last 8 bytes of ServerHello.random <del> set to the first 8 bytes of accept_confirmation. </del> <ins> set to "accept_confirmation". </ins> The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or below.  Note that doing so would overwrite the downgrade
First four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure starting from the first octet of "keys" to the <del> end of the stucture. </del> <ins> end of the structure. </ins> The list of keys which can be used by the client to encrypt the SNI.  Every key being listed MUST belong to a different group. The length to pad the ServerNameList value to prior to encryption. This value SHOULD be set to the largest ServerNameList the server <del> expects to support rounded up the nearest multiple of 16. [[OPEN ISSUE: An alternative to padding is to instead send a hash of the server name.  This would be fixed-length, but have the disadvantage that the server has to retain a table of all the server names it supports, and will not work if the mapping between the client-facing server and hidden server uses wildcards.]] </del> <ins> expects to support rounded up the nearest multiple of 16.  If the server supports wildcard names, it SHOULD set this value to 256. </ins> The moment when the keys become valid for use.  The value is represented as seconds from 00:00:00 UTC on Jan 1 1970, not
expansion) the server MAY abort the connection with an "illegal_parameter" alert without attempting to decrypt. <del> Assuming that these checks succeed, the server then computes K_sni and decrypts the ServerName value.  If decryption fails, the server MUST abort the connection with a "decrypt_error" alert. </del> <ins> Assuming these checks succeed, the server then computes K_sni and decrypts the ServerName value.  If decryption fails, the server MUST abort the connection with a "decrypt_error" alert. </ins> If the decrypted value's length is different from the advertised padding_length or the padding consists of any value other than 0,
5.3. <ins> A server operating in Shared Mode uses PaddedServerNameList.sni as if it were the "server_name" extension to finish the handshake.  It SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. 5.4. </ins> The Hidden Server ignores both the "encrypted_server_name" and the "server_name" (if any) and completes the handshake as usual.  If in Shared Mode, the server will still know the true SNI, and can use it for certificate selection.  In Split Mode, it may not know the true <del> SNI and so will generally be configured to use a single certificate </del> <ins> SNI and so will generally be configured to use a single certificate. </ins> communicating-sni describes a mechanism for communicating the true <del> SNI to the hidden server.  [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but gets in the way of stock servers.]] </del> <ins> SNI to the hidden server. Similar to the Shared Mode behavior, the hidden server in Split Mode SHOULD pad the Certificate message, via padding at the record layer such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but gets in the way of stock servers.]] </ins> 6.
Records are signed via a server private key, ESNIKeys have no authenticity or provenance information.  This means that any attacker which can inject DNS responses or poison DNS caches, which is a <del> common scenario in client access netowrks, can supply clients with </del> <ins> common scenario in client access networks, can supply clients with </ins> fake ESNIKeys (so that the client encrypts SNI to them) or strip the ESNIKeys from the response.  However, in the face of an attacker that controls DNS, no SNI encryption scheme can work because the attacker
for the "encrypted_client_hello" extension.  Clients MUST ignore any "ECHConfig" structure with a version they do not support. <del> The length, in bytes, of the next field. </del> <ins> The length, in bytes, of the next field.  This length field allows implementations to skip over the elements in such a list where they cannot parse the specific version of ECHConfig. </ins> An opaque byte string whose contents depend on the version.  For this specification, the contents are an "ECHConfigContents"
ECHClientHello.config_id since it can be used as a tracking vector. In such cases, the second method should be used for matching the ECHClientHello to a known ECHConfig.  See optional-configs.  Unless <del> specified by the application using (D)TLS or externally configured, implementations MUST use the first method. </del> <ins> specified by the application profile or otherwise externally configured, implementations MUST use the first method. </ins> The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension:
Abstract <del> This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. </del> <ins> This document describes an interface for importing external Pre- Shared Keys (PSKs) into TLS 1.3. </ins> 1. <del> TLS 1.3 RFC8446 supports pre-shared key (PSK) authentication, wherein </del> <ins> TLS 1.3 RFC8446 supports Pre-Shared Key (PSK) authentication, wherein </ins> PSKs can be established via session tickets from prior connections or externally via some out-of-band mechanism.  The protocol mandates that each PSK only be used with a single hash function.  This was
key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. <del> To mitigate these problems, external PSKs can be bound to a specific KDF and hash function when used in TLS 1.3, even if they are associated with a different hash function when provisioned.  This document specifies an interface by which external PSKs may be imported for use in a TLS 1.3 connection to achieve this goal.  In particular, it describes how KDF-bound PSKs can be differentiated by the target (D)TLS protocol version and KDF for which the PSK will be used.  This produces a set of candidate PSKs, each of which are bound to a specific target protocol and KDF.  This expands what would normally have been a single PSK identity into a set of PSK identities. </del> <ins> To mitigate these problems, this document specifies a PSK Importer interface by which external PSKs may be imported and subsequently bound to a specific KDF and hash function for use in TLS 1.3.  In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string.  This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </ins> 2.
3. <del> Key importers mirror the concept of key exporters in TLS in that they diversify a key based on some contextual information before use in a connection.  In contrast to key exporters, wherein differentiation is done via an explicit label and context string, the key importer defined herein diversifies external one PSK into one or more PSKs for use via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs. Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. Endpoints may incrementally deploy PSK importer support by offering </del> <ins> The PSK Importer interface mirrors that of the TLS Exporters interface in that it diversifies a key based on some contextual information.  In contrast to the Exporters interface, wherein differentiation is done via an explicit label and context string, the PSK Importer interface defined herein takes an external PSK and identity and "imports" it into TLS, creating a set of "derived" PSKs and identities.  Each of these derived PSKs are bound a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder keys are modified with a new derivation label to prevent confusion with non-imported PSKs. Imported keys do not require negotiation for use since a client and server will not agree upon identities if imported incorrectly. Endpoints may incrementally deploy PSK Importer support by offering </ins> non-imported keys for TLS versions prior to TLS 1.3.  Non-imported and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details. <del> Clients which import external keys TLS MUST NOT use these keys for any other purpose.  Moreover, each external PSK MUST be associated with at most one hash function. </del> <ins> Clients which import external keys MUST NOT use either the external keys or the derived keys for any other purpose.  Moreover, each external PSK MUST be associated with at most one hash function, as per the rules in Section 4.2.11 from RFC8446.  See security- considerations for more discussion. </ins> 3.1.
Target KDF: The KDF for which a PSK is imported for use. <del> Imported PSK (IPSK): A PSK derived from an EPSK, external identity, optional context string, and target protocol and KDF. </del> <ins> Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, and target protocol and KDF. </ins> Imported Identity: A sequence of bytes used to identify an IPSK. 4. <del> A key importer diversifies an input EPSK into one or more PSKs advertised on the wire via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs.  This section describes the diversification mechanism and binder key computation change. </del> <ins> This section describes the PSK Importer interface and its underlying diversification mechanism and binder key computation modification. </ins> 4.1. <del> A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on supported (target) protocols and KDFs.  In particular, for each supported target protocol "target_protocol" and KDF "target_kdf", the importer </del> <ins> The PSK Importer interface takes as input an EPSK with External Identity "external_identity" and base key "epsk", as defined in terminology, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on target protocols and KDFs.  In particular, for each supported target protocol "target_protocol" and KDF "target_kdf", the importer </ins> constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in
and QUICv1 QUIC use 0x0304.  Note that this means future versions of TLS will increase the number of PSKs derived from an external PSK. <del> An Imported PSK derived from an EPSK with base key 'epsk' bound to this identity is then computed as follows: </del> <ins> Given an ImportedIdentity and corresponding EPSK with base key "epsk", an Imported PSK IPSK with base key "ipskx" is computed as follows: </ins> <del> L is corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in IANA.  For hash-based KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash function output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. </del> <ins> L corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in IANA.  For hash-based KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash function output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. </ins> <del> The identity of 'ipskx' as sent on the wire is ImportedIdentity, </del> <ins> The identity of "ipskx" as sent on the wire is ImportedIdentity, </ins> i.e., the serialized content of ImportedIdentity is used as the <del> content of PskIdentity.identity in the PSK extension. </del> <ins> content of PskIdentity.identity in the PSK extension.  The corresponding TLS 1.3 binder key is "ipskx". </ins> The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with