Thanks Thom! >IKEv2 has a similar mechanism for SA rekeying of which I am not aware of >analysis (extra complication: IKEv2 supports full renegotiation of everything)
SSH and TLS 1.2 also have similar mechanisms for rekeying. Two high-level differences are: - IKEv2, TLS 1.2, and TLS 1.3 support mutual reauthentication, while SSH do not. - IKE SA rekey and ExtendedKeyUpdate chain the new keys to previous key material, whereas SSH and TLS 1.2 do not. Child SA rekey includes the IKE SA key, but it does not form a long chain. A similar but different mechanism is establishing multiple sequencial TLS 1.3 connections. This comes in three variants: - Without resumption - With resumption - With RFC 8773, using the resumption key as an external PSK One difference from the mechanisms above is that the ECDHE key shares used when establishing a new TLS 1.3 connection is sent in the clear as part of the handshake, rather than inside an already encrypted channel. >I need to worry about malicious ExtendedKeyUpdate and what that means It may also be interesting to analyze the case of honest ExtendedKeyUpdate where an attacker compromises a key afterwards. Ekerå [1] writes: "Options for making it harder for the adversary to mount store-now-decrypt-later attacks hence include using channels with a high data rate and fill signalling, whilst avoiding to send high-value messages directly over channels where such messages can be easily identified and intercepted. This by adopting a layered defense-in-depth approach, where data is encrypted multiple times for different reasons. Additional options include continuously re-negotiating the encryption keys, and chaining the negotiations, so that the adversary has to record and store an uninter- rupted sequence of negotiations, and then break them in sequence. Preferably, this is done in such a way that data transmitted to re-negotiate keys is computationally indistinguishable from encrypted fill and payload data to the adversary." The same reasoning applies to classical attacks on the key exchange. IKE SA rekey and ExtendedKeyUpdate appear to follow this model of continuously renegotiated and chained keys, but the others not. --- Frequent rekeying (e.g., every hour or every 1–100 GB of data) is common in IKEv2 and SSH. Regardless of the Extended Key Update work, I would like to see more research in this area to better understand the security implications of different designs. Reauthentication seems important because an attacker who compromises session key 1 while it is in use could otherwise gain access to session key 2. Currently, in TLS 1.3 and IKEv2, it is left to the application to handle rekeying and reauthentication independently, which does not seem optimal. One limitation of TLS 1.3 is that it does not support in-band mutual reauthentication. In many cases, modifying the application layer is not feasible. --- After reading these slides, I am beginning to believe that the approach in draft-kohbrok-mls-two-party-profile, draft-housley-tls-using-mls-handshake, draft-kohbrok-mls-tls, draft-tian-quic-quicmls is the correct one also for normal two-party MTLS in symmetric paths. It always combines rekeying with in-line reauthentication, chains keys across updates, and ensures the key exchange is encrypted. Cheers, John Preuß Mattsson [1] https://www.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf From: Thom Wiggers <[email protected]> Date: Saturday, 7 March 2026 at 14:45 To: <[email protected]> Subject: [TLS] FATT update on draft-ietf-tls-extended-key-update Hi TLS working group, Draft [draft-ietf-tls-extended-key-update] proposes to add a public-key exchange-based method that can be used in place of the regular KeyUpdate mechanism in TLS (which only hashes the application keys). In this manner, Extended Key Update (EKU) aims to achieve post-compromise security. The Formal Analysis Triage Team [FATT] was asked to form an opinion on draft-ietf-tls-extended-key-update. This was briefly discussed between ourselves and I was asked to be "point person” for this draft: i.e., I will be presenting a summary of the discussion and its conclusion. This report can be found at [slides] and I will present these slides in the second meeting of the TLS wg next week (Friday). Our conclusion is that the extension proposed changes the security properties of TLS 1.3 and does not fit will in existing analyses of TLS 1.3 – the slides try to explain this gap. I have also included an example of the subtleties that can have an effect on the ability to (easily) prove things. Note that this does not mean that the mechanism proposed is or was insecure. We also thank the authors for their quick feedback when I had questions. It is also important to note that the FATT is not a gate keeper for any TLS working group consensus call; it only intends to inform it. Cheers, Thom Wiggers [draft-ietf-tls-extended-key-update]: https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/ [FATT]: https://github.com/tlswg/tls-fatt [report]: https://datatracker.ietf.org/meeting/125/materials/slides-125-tls-sessa-fatt-report-on-eku-00
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
