ECDHE only helps if the connections are short-lived, otherwise CLIENT/SERVER_TRAFFIC_SECRET_0 is enough for passively eavesdropping on the whole connection. Connections lasting months or even years are not uncommon. It is essential to frequently rekey using asymmetric ephemeral key exchange (EDCHE, ML-KEM, etc.). Long-life connections were not a problem in TLS 1.2 where you can do ephemeral key exchange inside the connection. TLS 1.3 connections should not last more than an hour.
While the key shares in acceptable TLS implementations (complying with NIST requirements that ephemeral keys are only used once) are ephemeral, I don’t think the symmetric keys in TLS can be described as ephemeral. John From: Ilari Liusvaara <ilariliusva...@welho.com> Date: Friday, 28 February 2025 at 09:20 To: TLS@ietf.org <tls@ietf.org> Subject: [TLS] Re: Additional uses for SSLKEYLOGFILE entries On Thu, Feb 27, 2025 at 12:59:56PM -0800, S Moonesamy wrote: > Hi Brian, Stephen, > At 06:18 AM 27-02-2025, Stephen Farrell wrote: > > From my POV yes: fundamentally it is a bad idea for > > the IETF to standardise ways to exfiltrate keys > > even if there may be innocuous uses for those. And > > this latest ask (extending the exfiltration from > > being a TLS-only thing, to cover other protocols > > such as EDHOC) IMO nicely demonstrates the danger > > of the TLS WG publishing this document. > > According to Sheffer, Holz and Saint-Andre, "It is known that stolen (or > otherwise obtained) private keys have been used as part of large-scale > monitoring [RFC7258] of certain servers." What kind of private keys? Is that just the known trouble (TLS_RSA_*, TLS_PSK_* and the session ticket extension), or is it also other key types? Of those, only the pure-PSK stuff remains in TLS 1.3 (TLS 1.3 does have session tickets, but the mechanism is not a security disaster). Those three are especially suited for large-scale monitoring, because all destroy any forward secrecy, avoiding attacker having to steal keys on per-connection basis. Which is certainly highly convinient for attacker. I don't think putting non-ephemeral keys into SSLKEYLOGFILE would be even remotely reasonable. -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
