On 18.03.26 14:45, Viktor Dukhovni wrote:
As I mentioned [0,1], I'll do the formal analysis and share with the WG. John has kindly shared different cases [2,3]. If you see some cases missing, please share.On Wed, Mar 18, 2026 at 05:59:21PM +1100, Martin Thomson wrote:On Wed, Mar 18, 2026, at 14:41, Viktor Dukhovni wrote:The specification already correctly discourages reuse, changing this to a MUST, especially when enforcment on the receiving end is neither very practical, nor wise, rather like a feel-good exercise.As others have noted, many different analyses of the protocol have assumed fresh shares, so the security guarantees rely on having fresh shares. So not completely pointless, unless you don't feel like security analysis is useful.Security analysis provides useful guidance, and is especially valuable when it helps to identify subtle issues that might otherwise be missed.The general case analysed doesn't always cover all the cases that arise in practice, but lack of coverage does not necessarily make remaining use-cases invalid.
In case someone is worried, there are no plans to add ephemeral key reuse in OpenSSL, and I am not advocating for that to change.
That's great.
I just don't see tangible value it the proposed change, it feels to me like security theatre.
Are you denying all the reasons presented in the thread, e.g., mitigate correlation of different connections and side-channel attacks, additional complexity for code reuse, etc.?
Best, -Usama [0] https://mailarchive.ietf.org/arch/msg/tls/fNoZ0w3z213R45gAFKEx8sIT8jQ/ [1] https://mailarchive.ietf.org/arch/msg/tls/ZqDeMWCeHt18Ps4DkJRK2PWWMrs/ [2] https://mailarchive.ietf.org/arch/msg/tls/r6uY835AkOAYwwUFYfAnXpkbYQ0/ [3] https://mailarchive.ietf.org/arch/msg/tls/i_xXmnUtfLqz6JGfcfWEPw4IQzM/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
