-----Original Message----- From: Watson Ladd <[email protected]> Date: Thursday, 18 February 2021 at 07:24 To: John Mattsson <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [TLS] Frequent ephemeral Diffie-Hellman in long-term (D)TLS 1.3 connections replacing IPsec
On Fri, Jan 29, 2021 at 7:52 AM John Mattsson <[email protected]> wrote: > > Hi, > > 3GPP has historically to a large degree used IPsec to protect interfaces in > the core and radio access networks. Recently, 3GPP has more and more been > specifying use of (D)TLS to replace or complement IPsec. Most 3GPP usage of > (D)TLS are long-term connections. > > Current best practice for long-term connections is to rerun Ephemeral > Diffie-Hellman frequently to limit the impact of a key compromise. For IPsec, > ANSSI (France) recommends to rerun Ephemeral Diffie-Hellman every hour and > every 100 GB, BSI (Germany) recommend at least every 4 h, and NIST (USA) > recommends at least every 8 h. These recommendations are formally for IPsec > but makes equal sense for any long-term connection such as (D)TLS. > > If I understand correctly, the KeyUpdate handshake message only provides > Forward Secrecy (compromise of the current key does not compromise old keys). > To ensure that compromise of the current key does not compromise future keys > (post-compromise security, backward secrecy, future secrecy) my understanding > is that one would have to frequently terminate the connection and do > resumption with psk_dh_ke. Seems like this would cause a noticeable > interruption in the connection, or? Are there any best practice for how to do > frequent ephemeral Diffie-Hellman for long-term (D)TLS connections? Seems to > me that frequent ephemeral Diffie-Hellman should be the recommendation for > any long-term (D)TLS connection as it is for IPsec. What's the threat model here? [John] The threat model is leakage of application_traffic_secret_N. A passive attacker can then passively eavesdrop on all future application data sent on the connection including application data encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, application_traffic_secret_N+3, etc. That the attacker cannot eavesdrop of application data encrypted with application_traffic_secret_N-1, application_traffic_secret_N-2, etc. is already pretty sweet, but below government requirements for IPsec. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
