Summary

  • The current draft-ietf-tls-extended-key-update-13 proposes a three-message exchange that contributes fresh key-exchange input to new client and server application traffic secrets inside an existing TLS 1.3 or DTLS 1.3 session.
  • Capability negotiation, a response, a derived successor secret and even a decryptable new-generation record are different receipts. None alone proves that old material was erased, both directions completed, or a persistent attacker lost access.
  • Recovery claims should join negotiation, request/response/finish order, fresh-share generation, secret derivation, local deletion, directional record transitions, failure handling and bidirectional application canaries.

The source moved while the recovery question stayed

The commission began with revision 11. The IETF Datatracker now marks it as old: revision 12 followed in April, and the active text is revision 13, posted on 4 July 2026 and expiring on 5 January 2027. Its intended status is Proposed Standard, but its IESG state remains "I-D Exists"; it has no responsible area director or telechat date.

An Internet-Draft may be changed, replaced or abandoned. Revision 13 itself renamed message subtype 2 from new_key_update to key_update_finish and sharpened the active-attacker discussion. A support claim must name the revision and observed behaviour. "IETF approved" or "RFC-compliant" would be false.

Ordinary TLS 1.3 KeyUpdate derives the next traffic secret from the current one. It can enforce key-usage limits and protect earlier generations after deletion, but an attacker holding the current secret can follow the chain forward. Extended Key Update tries to break that inheritance by contributing a new shared secret.

Negotiated capability is only the first boundary

The draft uses a TLS flags extension. A client proposes Extended_Key_Update in ClientHello; a supporting and configured server acknowledges it in EncryptedExtensions. Without that acknowledgement, the procedure does not exist for the session. An application requiring post-compromise security must use a full handshake instead.

Once EKU is agreed, classic KeyUpdate must not appear; receiving it requires unexpected_message and connection termination. Request and response must use the key-exchange group selected in the original handshake. A different group is not agility—it is illegal_parameter.

Operators therefore need three separate facts: code supports the function, policy enables it, and this session negotiated it. A version string proves none of the latter two.

One exchange, four temporary views

The initiator sends key_update_request with a fresh key share. The responder returns key_update_response with its share; it may defer under load, without a progress message. After sending the response, the responder switches its send keys.

The initiator receives the response, derives successor secrets, changes its receive keys and sends an empty key_update_finish. It then changes its send keys. The responder does not change its receive keys until it receives that finish.

All three EKU messages are protected with the old application keys. In particular, the responder must authenticate the old-key finish before accepting new-key records. During the exchange, one endpoint may have new send keys and old receive keys while the other has new receive keys and old send keys. There is no single atomic "connection key version".

If requests cross, the lower lexicographic key_exchange value loses; equality is a protocol violation. A monitor that logs only "started" and "complete" cannot explain which request survived or which direction moved first.

Fresh input changes the cryptographic claim

The new exchange is not decorative. Revision 13 mixes the newly computed shared secret with a value derived from the previous main secret and a transcript hash covering the original handshake and successive EKU exchanges. From the new main secret, the endpoints derive both application traffic secrets, an exporter secret and a resumption main secret. That is the essential difference from ordinary KeyUpdate: the successor state is no longer determined solely by the compromised chain.

Yet “fresh” has an implementation boundary. A trace may show new key shares and compatible records. It cannot show that the random generator was healthy, that ephemeral material was never reused, or that an HSM, kernel offload path or crash image released every earlier copy. The draft says implementations SHOULD delete prior secrets and keys as soon as possible; it cannot remotely attest that deletion.

The right operational unit is therefore a joined receipt. Each endpoint should record the negotiated draft revision and group, a non-secret generation identifier for its ephemeral material, hashes or identifiers for request/response/finish, successor-secret generation identifiers, destruction results for old slots, and the first accepted record under the new keys in each direction. Those facts must join to one session without logging secret material.

The attacker has to leave

The draft’s post-compromise claim assumes a transient exposure. Confidentiality can recover if the adversary no longer has access to either peer when the fresh exchange occurs. A persistent attacker that still controls an endpoint can simply read the new state. An active attacker holding current traffic keys may also substitute EKU messages and preserve a man-in-the-middle position unless the additional authentication described in Section 11 is used.

Post-handshake certificate authentication and a modified Exported Authenticator can help bind authentication to the post-EKU state. They are not automatic receipts. Availability, policy, execution, peer identity and success must each be observed. Nor does recovery of one connection repair a compromised long-term identity key; future handshakes can remain impersonable.

For DTLS 1.3 the evidence is different again. Loss and reordering introduce retransmission, ACKs and temporary retention of old epochs. The initiator does not complete its send switch until the new-epoch acknowledgement arrives. A TLS stream dashboard cannot be reused as a DTLS recovery dashboard merely by changing the protocol label.

Sources