Importing External Pre-Shared Keys (PSKs) for TLS 1.3
Extracted elements (24)
Depreciating a hash function for TLS 1.3 is accomplished by simply removing the corresponding KDF from the set of target KDFs used for import. This does not affect the HKDF operation used to derive the imported PSKs themselves.
The "imp binder" label change for imported PSK binder key derivation is introduced to prevent confusion between imported and non-imported PSKs. Without this change, a mismatch between endpoints (one importing, one not) would not be detected at binder verification time.
The Selfie attack arises when multiple nodes share a single PSK and TLS only authenticates group membership, allowing a node to authenticate itself as its own peer. Incorporating client and server roles (e.g., MAC addresses) into ImportedIdentity.context defeats this attack by ensuring redirected ClientHellos produce a different context string and fail.
TLS 1.3 mandates that each PSK be used with only a single hash function to simplify protocol analysis. This constraint motivates the PSK importer interface, which binds external PSKs to a specific KDF, protocol version, and optional context string so that a single external PSK yields distinct imported PSKs per target.
In deployments with PSKs already used under TLS 1.2, incrementally enabling the importer results in the same PSK being used directly as a TLS 1.2 PSK and as an EPSK for TLS 1.3, which means the same KDF and key could be used in two protocol contexts — a non-recommended but potentially necessary transitional configuration.
Applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions. Reusing external PSKs across different TLS versions may produce related outputs and lead to security problems.
Each external PSK fed to the importer process MUST be associated with at most one hash function, analogous to the rules in Section 4.2.11 of RFC 8446.
Endpoints SHOULD generate a compatible ipskx for each target ciphersuite they offer, since each ciphersuite uniquely identifies the target KDF.
Endpoints that import external keys MUST NOT use those input keys for any purpose other than the importer, and MUST NOT use the derived imported PSKs for any purpose other than TLS PSKs.
External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions; the importer is defined only for TLS 1.3 and DTLS 1.3.
For EPSKs imported for early data use, the ALPN value, QUIC transport parameters (if applicable), and any other parameters required for early data MUST be provisioned alongside the EPSKs.
ImportedIdentity.context MUST include the context used to determine the EPSK, if any exists (e.g., peer role information to mitigate Selfie-style reflection attacks). If the EPSK is derived from an external protocol, ImportedIdentity.context MUST include a channel binding for those deriving protocols per RFC 5056.
ImportedIdentity.target_protocol MUST be the (D)TLS protocol version for which the PSK is being imported, e.g., 0x0304 for TLS 1.3 (also used by QUICv1).
The hash function used for HKDF is the one associated with the EPSK. If the EPSK has no associated hash function, SHA-256 SHOULD be used.
The PSK importer interface SHOULD reject any ImportedIdentity that exceeds 2^16 - 1 octets, as exceeding the maximum PSK extension size is likely to cause a decoding error.
External PSK identities are commonly static by design, which means they can serve as persistent tracking identifiers across connections.
ImportedIdentity.context is transmitted in cleartext on the wire as part of the PSK identity. Unless protected by a mechanism such as TLS Encrypted ClientHello, applications SHOULD NOT place sensitive information in this field.
An imported PSK (ipskx) is derived from an EPSK as: epskx = HKDF-Extract(0, epsk); ipskx = HKDF-Expand-Label(epskx, "derived psk", Hash(ImportedIdentity), L), where L is the KDF output length for target_kdf. HKDF-Expand-Label internally uses the label for the target protocol (e.g., "tls13").
Imported PSKs use the binder key derivation label "imp binder" instead of the standard "ext binder" or "res binder". This ensures a client and server negotiate an imported PSK if and only if both import it, or neither does. Since binder_key is a leaf key, this change does not affect any other key.
IANA created the "TLS KDF Identifiers" registry under the "Transport Layer Security (TLS) Parameters" registry. Initial values: 0x0000 (Reserved), 0x0001 (HKDF_SHA256), 0x0002 (HKDF_SHA384). Values 0x0000–0xfeff assigned via Specification Required; 0xff00–0xffff reserved for Private Use.
KDFs modeled as computational extractors require source-independence: the same IKM must not be used for two different KDFs. The PSK importer ensures each imported PSK is used as IKM for at most one KDF by diversifying on ImportedIdentity.target_kdf.
The PSK importer aims to achieve compound authentication: externally provisioned PSKs imported into a TLS connection should authenticate both the external provisioning process and the TLS connection. Context-free PSKs only achieve authentication within a single connection.
The PSK importer does not prevent applications from constructing non-importer PSK identities that collide with imported PSK identities. Applications must avoid such collisions themselves.
The ImportedIdentity structure encodes: external_identity (1..2^16-1 opaque bytes), context (0..2^16-1 opaque bytes), target_protocol (uint16), and target_kdf (uint16). The serialized ImportedIdentity is used as PskIdentity.identity on the wire.