Summary

  • RFC 9973 lets TLS 1.3 combine certificate authentication with an externally provisioned PSK and an (EC)DHE secret in one key schedule. It deliberately leaves the external secret's generation, distribution and management outside the wire protocol.
  • A selected PSK identity and a valid binder establish that the parties used the same selected key in this handshake. They do not establish the secret's lineage, exclusive custody, intended purpose, authorization scope or downstream business effect.
  • A credible control record therefore separates secret provenance and custody, negotiation and certificate validation, session establishment, application authorization, commit and independently observed result.

Consider a manufacturer enrolling a new device in an enterprise network. The device has a public key and a factory-provisioned secret. The enterprise wants a first secure connection before the device has an ordinary account, and it also wants a path that improves the confidentiality of archived traffic if future asymmetric cryptography becomes vulnerable. A team installs certificate material, provisions a secret at both ends, enables a TLS flag and sees successful connections.

That is a sensible beginning. It is not a finished authority model.

The secret may have been created by a factory process, copied into a fulfillment system, delivered to an integrator, loaded into a device, retained in a backup and exposed to a support tool. The certificate may identify a legitimate endpoint while a different team controls the secret catalogue. The TLS library may accept the selected identity while the application must still decide whether this device is allowed to enroll, which tenant it belongs to and what command it may issue. A durable system has to make those handoffs reviewable rather than compress them into “TLS passed.”

What RFC 9973 actually composes

RFC 9973, published as an IETF Standards Track document in July 2026, obsoletes the earlier Experimental RFC 8773. It defines the tls_cert_with_extern_psk extension for TLS 1.3. The design joins two previously separate roles: certificate-based authentication continues to use the certificate and signature mechanisms, while a selected external PSK becomes an input to the TLS 1.3 key schedule alongside the (EC)DHE shared secret.

That is narrower than an assertion that two credentials have merged into one authority. TLS still distinguishes a resumption PSK, created by a previous handshake, from an external PSK, created by some other process. The extension is designed for initial handshakes. It requires companion mechanisms including key_share, supported_groups, psk_key_exchange_modes and pre_shared_key; it cannot be combined with early_data. The client's PSK list must contain external PSKs, and an attempted mix with a resumption PSK leads to an illegal_parameter abort.

The sequence makes the division visible. A client offers identities and binders. If the server is willing to use one offered external PSK and to perform certificate authentication, it returns the extension in ServerHello. For the initial handshake, the client must offer psk_dhe_ke and the server must select it. The server's selected identity points into the offered list; it validates the corresponding binder. The shared external PSK and the (EC)DHE result then participate in the key schedule.

Each statement has a deliberately modest meaning. The binder says the parties associated the same selected key with the identity in this transcript. It does not say that the identity is a legal name, that only two parties know the key, that the secret was generated well, or that the party who offered it is authorized to perform a future action. The IANA TLS ExtensionType registry makes code point 33 interoperably named; it does not report which client or server has implemented it.

One secret, several owners

The phrase “external PSK” can conceal the main operational question: external to which authority? It is external to the TLS handshake's normal resumption path. It is not external to the risks created by a supply chain, a key-management service, a device factory, an incident-response archive or a deployment operator.

RFC 9973 makes the boundary explicit. Generation, distribution and management of the external PSK are outside its scope. Yet its long-term confidentiality rationale depends on the secret's confidentiality, entropy and authenticity. The RFC requires a secure key-management technique for generation and warns that a weak pseudorandom process can reduce security to a small reproducible search. RFC 4086 is useful here because it makes randomness a systems property rather than a label added after deployment.

This creates a governance chain with no single magical witness. A manufacturing authority can attest to an intended device population. A key-management operator can show how a value was derived or injected. A device operator can show an access boundary and a rotation event. A TLS capture can show the selected identity and the negotiated extension. A certificate validator can show the signature and peer-name result. None can replace the others.

Reuse changes the chain further. RFC 9973 says that a single-session secret known only to client and server has different separation properties from a secret reused across many sessions or known to a group. It does not forbid group knowledge, because certificate signatures remain the authentication mechanism. But more custodians mean more opportunities for theft; if an attacker later obtains the secret and a sufficiently capable quantum computer, stored traffic may be at risk under the RFC's stated model. Secret custody is therefore not a metadata field. It is part of what the confidentiality claim means.

Authentication did not move into the PSK

The extension's most useful discipline is negative: it refuses to let the external PSK become the sole basis of authentication. Server authentication still depends on a signature that validates against a certificate public key; client certificate authentication is again possible when the extension is negotiated. A raw public key is an alternative form described in RFC 7250, but that too requires an application-defined trust decision.

That separation matters for long-term cryptography. RFC 9973 explains that a strong external PSK can add a confidentiality condition against the future loss of the usual key-agreement algorithm: an attacker would need the PSK as well as the recovered agreement secret to recover session secrets. It also says plainly that adding the PSK does not improve certificate authentication against that future threat. Calling the whole connection “quantum-safe” hides the part that the RFC leaves unchanged.

The same restraint applies to device enrollment. RFC 9973 cites RFC 9966 as one motivation: a public key plus a factory-provisioned secret can support initial enterprise enrollment. The protocol does not decide whether the factory record is accurate, whether the device has been reassigned, whether the device's owner consented, or which enterprise policy should admit it. Enrollment is a decision after cryptographic evidence, not a synonym for it.

Privacy and the identifier trail

The extra secret can also leave a visible trail. External PSK identities travel in the pre_shared_key extension in the plaintext ClientHello. If an identity is reused, an observer can use it to track a client or server across connections. RFC 9973 names rotation and Encrypted Client Hello as mitigations. A key inventory that records only secret values and expiry dates will miss this public correlation surface.

The operational response should not be “rotate everything constantly.” It should be to specify purpose and scope. Is the identity per device, per enterprise, per service, per enrollment epoch or per temporary incident channel? Which observer is in the threat model? Who can cause rotation, and how does a device safely obtain the next value? What must be retained for forensic attribution without preserving a durable tracking label? Those are local design decisions, which is exactly why the RFC does not pretend to settle them.

Heng Lu's running-code principle is practical here. A configuration screen stating that a service supports external PSKs is not the proof. The proof is a bounded record of the actual offer, selected identity class, negotiated extension, certificate decision, Finished outcome, policy evaluation and resulting action. His distinction between technical and practical control adds a harder question: a secret may be registered to one entity while a different operator, backup job or contractor can still read it. Nominal ownership cannot repair a broad custody path.

A closeout record for security owners

For each external-PSK-enabled service or enrollment flow, retain a purpose statement and a key lineage record: generation or derivation class, intended peer population, permitted protocol version and hash, distribution route, custodians, rotation rule and destruction rule. Store the PSK value only under the appropriate secret-management controls; the audit record should preserve identifiers and evidence, not reproduce secrets.

For a sampled or high-risk handshake, record the client and server identities at the policy layer, the fact that tls_cert_with_extern_psk was offered and accepted, the selected identity index or safe correlation handle, psk_dhe_ke, certificate-validation outcome, negotiated TLS version, alert or Finished result and the time window. Then retain the separate application decision: why this peer was allowed to enroll, read, update or invoke an operation; what freshness and replay constraints applied; whether the request committed; and what independent probe or ledger observed afterward.

This record is intentionally more demanding than a green padlock. It matches the separation of authority in the system. The protocol can prove a disciplined cryptographic transition. It cannot choose the owner of a secret's lifecycle or accept the consequences of an application action.

Sources