PQ key exchange for TLS

Summary. TrustBridge adds a second layer of protection to every connection between two partners: a post-quantum secret that is created independently of TLS. On every connected host, a key agent regularly agrees on a fresh secret with the counterpart's agent using ML-KEM; both agents authenticate with ML-DSA certificates. A local key broker hands the secret to the TLS adapter, which feeds it into the TLS 1.3 handshake as an external pre-shared key (PSK) per RFC 9973, on top of a hybrid key agreement and mutual certificate authentication. Anyone who records a connection would later have to break two independent key agreements. Authentication stays with the certificates; the additional secret does not replace it.

• External PSK – a secret agreed outside TLS that both sides feed into the TLS 1.3 key schedule (RFC 8446, Section 2.2).
• psk_dhe_ke – the TLS 1.3 mode in which the PSK is used in addition to an (EC)DHE key agreement; the forward secrecy of the key agreement is preserved.
• Hybrid group – a TLS 1.3 key agreement built from a classical algorithm and ML-KEM, such as SecP256r1MLKEM768 (RFC 10024).
• tls_cert_with_extern_psk – the TLS extension (codepoint 33) from RFC 9973 that lets a handshake combine certificate authentication and an external PSK in the key schedule.
• Key agent – a service on a connected host that runs the post-quantum key exchange with the counterpart's agent.
• Key broker – a local component that hands the agreed secret to the TLS adapter on the same host.
• TLS adapter – a local service that opens or accepts the TLS connection to the counterpart on behalf of an existing application.
• Peer binding – binding the key exchange to the counterpart's verified identity.
• Connection rotation – the scheduled replacement of an existing TLS connection with a new one that carries a fresh secret, without the application noticing an interruption.

For confidentiality against later decryption, TLS 1.3 has a standardized path: hybrid groups made of ECDHE and ML-KEM (RFC 10024). The BSI lists SecP256r1MLKEM768 and SecP384r1MLKEM1024 among them (TR-02102-2). TrustBridge uses these groups on every connection. The additional secret complements them in three ways:

The additional secret is defense in depth. It does not make TLS redundant, does not replace certificates, and is not a new TLS protocol: it uses an interface that TLS 1.3 explicitly provides for through RFC 9973.

graph TD
  subgraph HA [Host at organization A]
    AA[Application]
    TA[TLS adapter A]
    KBA[Key broker A<br/>local]
    AGA[Key agent A]
  end
  subgraph HB [Host at organization B]
    AB[Application]
    TB[TLS adapter B]
    KBB[Key broker B<br/>local]
    AGB[Key agent B]
  end
  subgraph PKI [Certificate authorities of both organizations]
    CA[CA worker A and B<br/>each with its own trusted computing base]
  end
  AGA ==>|ML-KEM, both sides authenticated with ML-DSA| AGB
  AGA ==>|secret| KBA
  AGB ==>|secret| KBB
  KBA ==>|external PSK| TA
  KBB ==>|external PSK| TB
  AA --> TA
  TA -->|TLS 1.3: certificates, external PSK, hybrid group| TB
  TB --> AB
  CA -.->|agent and service certificates| AGA
  CA -.->|agent and service certificates| AGB
  classDef tcb fill:#fde7e9,stroke:#a4262c,color:#201f1e
  classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef pq fill:#dff6dd,stroke:#107c10,color:#201f1e
  class CA tcb
  class TA,TB onl
  class AA,AB par
  class AGA,AGB,KBA,KBB pq
  style HA fill:#ffffff,stroke:#8a8886,color:#201f1e
  style HB fill:#ffffff,stroke:#8a8886,color:#201f1e
  style PKI fill:#ffffff,stroke:#8a8886,color:#201f1e

The key broker is explicitly local. A central service that distributes session keys to endpoints would become a target with access to every connection. TrustBridge has no such service; even an operating partner in the Managed model knows none of the agents' secrets.

RFC 9973 (July 2026, Standards Track) defines exactly the connection that TrustBridge needs: certificate authentication in TLS 1.3 with an external PSK also entering the key schedule. Without this extension, PSK and certificate are mutually exclusive in TLS 1.3.

sequenceDiagram
  participant AA as Agent A
  participant AB as Agent B
  participant TA as TLS adapter A
  participant TB as TLS adapter B
  AA->>AB: ML-KEM exchange, both sides authenticated with ML-DSA
  AB-->>AA: shared secret, PSK identity, validity
  AA->>TA: PSK via local key broker
  AB->>TB: PSK via local key broker
  TA->>TB: ClientHello with tls_cert_with_extern_psk, pre_shared_key, psk_dhe_ke, hybrid key_share
  TB-->>TA: ServerHello with tls_cert_with_extern_psk, pre_shared_key, key_share
  TB-->>TA: CertificateRequest, Certificate, CertificateVerify, Finished
  TA->>TB: Certificate, CertificateVerify, Finished
  Note over TA,TB: All traffic keys depend on the PSK and on the hybrid secret

RFC 9257 (guidance for external PSKs) and RFC 9258 (binding imported external PSKs to protocol and hash function) apply as well.

TLS 1.3 takes in a new external secret only when a connection is established. Within an existing connection, KeyUpdate derives new traffic keys solely from the previous traffic secret and brings in no fresh material. TrustBridge therefore renews the protection through the connection itself:

sequenceDiagram
  participant AP as Application
  participant TA as TLS adapter A
  participant TB as TLS adapter B
  Note over TA,TB: Connection 1 with secret n
  TA->>TB: open connection 2 with secret n+1
  TB-->>TA: handshake complete
  AP->>TA: new requests
  TA->>TB: over connection 2
  Note over TA,TB: Connection 1 accepts nothing new and closes after the last response

• A new TLS protocol or a replacement for TLS 1.3. TrustBridge uses the extension provided by RFC 9973.
• Quantum-safe authentication through the PSK. Authentication is provided by the certificates; their post-quantum properties are described in Cryptography and the post-quantum transition.
• Protection of the leg between TLS adapter and application on the same host.
• Authorization. A connection with a valid secret does not yet permit any operation; that is governed by the target application; see Trust model.

• RFC 8446 – TLS 1.3; Section 2.2 on PSKs, Section 4.6.3 on KeyUpdate, Section 7.1 on the key schedule.
• RFC 9973 – TLS 1.3 extension for certificates with an external PSK (July 2026, Standards Track, obsoletes RFC 8773); explicitly separates confidentiality from authentication.
• RFC 10024 – hybrid ECDHE and ML-KEM key agreement for TLS 1.3.
• RFC 9257 – guidance for external PSK usage.
• RFC 9258 – importing external PSKs into TLS 1.3.
• FIPS 203 – ML-KEM.
• FIPS 204 – ML-DSA.
• BSI TR-02102 – TR-02102-2 (edition 2026-01), Section 3.4.2: recommendation of the hybrid groups SecP256r1MLKEM768 and SecP384r1MLKEM1024.