Re: [TLS] Frequent ephemeral Diffie-Hellman in long-term (D)TLS 1.3 connections replacing IPsec

[John Mattsson <[e-mail]>]

-----Original Message-----
From: Watson Ladd <[e-mail]>
Date: Thursday, 18 February 2021 at 07:24
To: John Mattsson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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
<john.mattsson=[e-mail]> 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.