jiebi/CodeConvo huggingface dataset:
SHA-256 MUST be used.  Diversifying EPSK by ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the <del> requirements in RFC8446. Endpoints generate a compatible ipskx for each target ciphersuite they offer.  For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary. The resulting IPSK base key 'ipskx' is then used as the binder key in TLS 1.3 with identity ImportedIdentity.  With knowledge of the supported KDFs, one may import PSKs before the start of a connection. EPSKs may be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. </del> <ins> requirements in RFC8446.  See security-considerations for more details. Endpoints SHOULD generate a compatible "ipskx" for each target ciphersuite they offer.  For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary. EPSKs may be imported before the start of a connection if the target KDFs, protocols, and context string(s) are known a priori.  EPSKs may also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means ALPN, QUIC transport parameters (if used for QUIC), etc., must be provisioned alongside these EPSKs. </ins> 4.2. <del> To prevent PSK Importers from being confused with standard out-of- band PSKs, imported PSKs change the PSK binder key derivation label. In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: </del> <ins> To prevent confusion between imported and non-imported PSKs, imported PSKs change the PSK binder key derivation label.  In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: </ins> Imported PSKs replace the string "ext binder" with "imp binder" when <del> deriving "binder_key".  This means the binder key is now computed as </del> <ins> deriving "binder_key".  This means the binder key is computed as </ins> follows: <del> This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an </del> <ins> This new label ensures a client and server will negotiate use of an </ins> external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  As "binder_key" is a leaf key, changing its computation does not affect any other key.
algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers.  However, critically, the derived PSK will not be the same since the importer <del> differentiates the PSK via the identity, target protocol, and target KDF.  Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this </del> <ins> differentiates the PSK via the identity and target KDF and protocol. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this </ins> does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. 7. <del> The Key Importer security goals can be roughly stated as follows: </del> <ins> The PSK Importer security goals can be roughly stated as follows: </ins> avoid PSK re-use across KDFs while properly authenticating endpoints. When modeled as computational extractors, KDFs assume that input keying material (IKM) is sampled from some "source" probability
authentication protocols, wherein at least one is uncompromised, jointly authenticates all protocols.  Authenticating with an externally provisioned PSK, therefore, should ideally authenticate <del> both the TLS connection and the external provision process. </del> <ins> both the TLS connection and the external provisioning process. </ins> Typically, the external provision process produces a PSK and corresponding context from which the PSK was derived and in which it <del> should be used.  We refer to an external PSK without such context as "context free". </del> <ins> should be used.  If available, this is used as the ImportedIdentity.context value.  We refer to an external PSK without such context as "context-free". </ins> Thus, in considering the source-independence and compound <del> authentication requirements, the Key Import API described in this document aims to achieve the following goals: </del> <ins> authentication requirements, the PSK Import interface described in this document aims to achieve the following goals: </ins> <del> Externally provisioned PSKs imported into TLS achieve compound authentication of the provision step(s) and connection. </del> <ins> Externally provisioned PSKs imported into a TLS connection achieve compound authentication of the provisioning process and connection. </ins> Context-free PSKs only achieve authentication within the context of a single connection. <del> Imported PSKs are used as IKM for two different KDFs. </del> <ins> Imported PSKs are not used as IKM for two different KDFs. </ins> Imported PSKs do not collide with existing PSKs used for TLS 1.2 and below.
way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done. Applications SHOULD provision separate PSKs for TLS 1.3 and prior <del> versions. </del> <ins> versions.  In cases where this is not possible, e.g., there are already deployed external PSKs or provisioning is otherwise limited, re-using external PSKs across different versions of TLS may produce related outputs, which may in turn lead to security problems; see RFC8446, Section E.7. </ins> <del> To mitigate against any interference, this document specifies a PSK </del> <ins> To mitigate against such problems, this document specifies a PSK </ins> Importer interface by which external PSKs may be imported and subsequently bound to a specific key derivation function (KDF) and hash function for use in TLS 1.3 RFC8446 and DTLS 1.3 DTLS13.  In
and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details. <del> Endpoints 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. </del> <ins> Endpoints which import external keys MUST NOT use the keys that are input to the import process for any purpose other than the importer, and MUST NOT use the derived keys for any purpose other than TLS PSKs.  Moreover, each external PSK fed to the importer process MUST be associated with at most one hash function.  This is analogous to the rules in Section 4.2.11 of RFC8446.  See security-considerations for more discussion. </ins> 3.1. <ins> The following terms are used throughout this document: </ins> External PSK (EPSK): A PSK established or provisioned out-of-band, i.e., not from a TLS connection, which is a tuple of (Base Key, External Identity, Hash).
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, target protocol, and target KDF. </del> <ins> Imported PSK (IPSK): A PSK derived from an EPSK, optional context string, target protocol, and target KDF. </ins> Imported Identity: A sequence of bytes used to identify an IPSK. <ins> This document uses presentation language from RFC8446, Section 3. </ins> 4. This section describes the PSK Importer interface and its underlying
PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for incremental deployment. <del> ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  For example, ImportedIdentity.context may </del> <ins> ImportedIdentity.context MUST include the context used to determine the EPSK, if any exists.  For example, ImportedIdentity.context may </ins> include information about peer roles or identities to mitigate Selfie-style reflection attacks Selfie.  See mitigate-selfie for more details.  If the EPSK is a key derived from some other protocol or
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, <del> i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. </del> <ins> e.g., 32 octets for SHA256.  This is required for the IPSK to be of length suitable for supported ciphersuites.  Internally, HKDF-Expand- Label uses a label corresponding to ImportedIdentity.target_protocol, e.g., "tls13" for TLS 1.3, as per RFC8446, Section 7.1, or "dtls13" for DTLS 1.3, as per I-D.ietf-tls-dtls13, Section 5.10. </ins> The identity of "ipskx" as sent on the wire is ImportedIdentity, i.e., the serialized content of ImportedIdentity is used as the content of PskIdentity.identity in the PSK extension.  The <del> corresponding TLS 1.3 binder key is "ipskx". </del> <ins> corresponding PSK input for the TLS 1.3 key schedule is 'ipskx'. </ins> As the maximum size of the PSK extension is 2^16 - 1 octets, an Imported Identity that exceeds this size is likely to cause a
The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with ImportedIdentity.target_kdf.  If no hash function is specified, <del> SHA-256 SHA2 MUST be used.  Diversifying EPSK by </del> <ins> SHA-256 SHA2 SHOULD be used.  Diversifying EPSK by </ins> ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the requirements in RFC8446.  See security-considerations for more
TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are <del> supported, only one derived key is necessary. </del> <ins> supported, only one derived key is necessary.  Each ciphersuite uniquely identifies the target KDF.  Future specifications that change the way the KDF is negotiated will need to update this specification to make clear how target KDFs are determined for the import process. </ins> EPSKs MAY be imported before the start of a connection if the target KDFs, protocols, and context string(s) are known a priori.  EPSKs MAY <del> also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means Application-Layer Protocol Negotiation RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </del> <ins> also be imported for early data use if they are bound to the protocol settings and configuration that are required for sending early data. Minimally, that means Application-Layer Protocol Negotiation value RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </ins> 4.2.
6. <del> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers.  However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and target KDF and protocol. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment.  Specifically, existing applications using TLS 1.2 with non-imported PSKs can safely enable TLS 1.3 with imported PSKs in clients and servers without interoperability risk. </del> <ins> The mechanism defined in this document requires that an EPSK is only ever used as an EPSK and not for any other purpose.  In particular, this requirement disallows direct use of the EPSK as a PSK in TLS 1.2.  The importer process produces distinct IPSKs derived from the target protocol and KDF, which in turn protects against cross- protocol collisions for protocol versions using this process by ensuring that each IPSK can only be used with one protocol and KDF. This is a distinct contrast to TLS 1.2, where a given PSK might be used with multiple KDFs in different handshakes, and importers are not available.  Furthermore, the KDF used in TLS 1.2 might be the same KDF used by the importer mechanism itself. In deployments that already have PSKs provisioned and in use with TLS 1.2, attempting to incrementally deploy the importer mechanism would then result in concurrent use of the already provisioned PSK both directly as a TLS 1.2 PSK and as an EPSK, which in turn could mean that the same KDF and key would be used in two different protocol contexts.  There are no known related outputs or security issues that would arise from this arrangement.  However, only limited analysis has been done, and as such is not a recommended configuration. However, the benefits of using TLS 1.3 and of using PSK importers may prove sufficiently compelling that existing deployments choose to enable this noncompliant configuration for a brief transition period while new software (using TLS 1.3 and importers) is deployed. Operators are advised to make any such transition period as short as possible. </ins> 7.
Imported PSKs do not collide with future protocol versions and KDFs. <del> There is no known interference between the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3. </del> <ins> There are no known related outputs or security issues caused from the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below, as noted in rollout.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.
Update the "Reference" to also refer to this document. <del> Add the following notes: Experts are to verify that there is in fact a publicly available standard.  An Internet Draft that is posted and never published or a standard in another standards body, industry consortium, university site, etc. suffices. As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </del> See expert-pool for additional information about the designated expert pool.
extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED.  IESG Approval is REQUIRED for a Yes->No transition. <ins> IANA [SHALL update/has added] the following notes: Experts are to verify that there is in fact a publicly available specification.  An Internet Draft that is posted and never published or a specification in another standards body, industry consortium, university site, etc. suffices. As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. Extensions marked as "Yes" are those allocated via Standards Track RFCs.  Extensions marked as "No" are not. If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> The following is from I-D.ietf-tls-tls13 and is included here to ensure alignment between these specifications.
groups marked "No" range from "good" to "bad" from a cryptographic standpoint. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> The designated expert RFC8126 only ensures that the specification is publicly available.  An Internet Draft that is posted and never published or a standard in another standards body, industry
Exporters Labels marked as "Yes" are those allocated via Standards Track RFCs.  Exporter Labels marked as "No" are not. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> IANA [SHALL update/has updated] the reference for this registry to also refer to this document.
Certificate Types marked as "Yes" are those allocated via Standards Track RFCs.  Certificate Types marked as "No" are not. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> IANA [SHALL update/has updated] the reference for this registry to also refer this document.
SignatureAlgorithm registries to also refer to this document. [SHALL update/has updated] the TLS HashAlgorithm Registry to list <del> values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </del> <ins> values 7 and 9-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-6 and 9-223 as "Reserved". </ins> Despite the fact that the HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still important to warn implementers
4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. <del> 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. </del> <ins> If the client receives a ServerKeyExchange message indicating MD5 or SHA-1, then it MUST abort the connection with an illegal_parameter alert. </ins> 5. Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1 it <del> MUST abort the connection with handshake_failure or insufficient_security alert. </del> <ins> MUST abort the connection with an illegal_parameter alert. </ins> 6.
Connection racing: Happy Eyeballs V2 RFC8305 describes techniques for performing connection racing.  The Transport Services <del> Architecture implementation from I-D.ietf-taps-impl also describes how connections may race across interfaces and address families. In cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket </del> <ins> Architecture implementation from TAPS also describes how connections may race across interfaces and address families.  In cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket </ins> invalidation by racing. Connection priming: In some systems, connections may be primed or
e.g., public key cryptographic operations, avoiding waste is desirable. <ins> Decline resumption: Clients may indicate they have no intention of resuming connections by sending a ticket request with count of zero. </ins> 3. <del> Clients may indicate to servers their desired number of tickets via the following "ticket_request" extension: </del> <ins> Clients may indicate to servers their desired number of tickets for a single connection via the following "ticket_request" extension: </ins> Clients may send this extension in ClientHello.  It contains the following structure:
send more than 255 tickets to clients. Servers that support ticket requests MUST NOT echo "ticket_request" <del> in the EncryptedExtensions. </del> <ins> 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. Clients MUST NOT change the value of TicketRequestContents.count in second ClientHello messages sent in response to a HelloRetryRequest. </ins> 4.
meaning that the server is not willing to receive any WebTransport sessions. <ins> Because WebTransport over HTTP/3 requires support for HTTP/3 datagrams and the Capsule Protocol, both the client and the server MUST indicate support for HTTP/3 datagrams by sending a SETTINGS_H3_DATAGRAM value set to 1 in their SETTINGS frame (see Section 2.1.1 of HTTP-DATAGRAM). WebTransport over HTTP/3 also requires support for QUIC datagrams. To indicate support, both the client and the server MUST send a max_datagram_frame_size transport parameter with a value greater than 0 (see Section 3 of QUIC-DATAGRAM). </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by
From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. <del> Both endpoints MUST NOT open any streams or send any datagrams on a given session before that session is established.  WebTransport over HTTP/3 does not support 0-RTT. </del> <ins> WebTransport over HTTP/3 does not support 0-RTT. </ins> 3.4.