On Mon, 16 Mar 2026, 21:20 Eric Rescorla, <[email protected]> wrote: > > > On Mon, Mar 16, 2026 at 10:15 AM Nico Williams <[email protected]> > wrote: > >> On Mon, Mar 16, 2026 at 02:17:31PM +0000, Ben Schwartz wrote: >> > I don't understand this. All secrets derived from ECDH also depend on >> > the (hashed) handshake transcript, including the randoms, so the >> > resulting shared secrets will never be duplicated between connections. >> > What am I missing? >> >> You right that there is enough entropy with the small nonces (which have >> to be kept small), though not in the rest of the handshake. >> >> Without enforcement of the non-reuse requirement, I'm not finding the >> new MUST very credible. >> > > This specification, like many specifications, is full of unenforceable > MUSTs. > The purpose of this one is to tell implementations not to do something > unwise. > > > An optional enforcement requirement would make this requirement more >> credible, in the form of a replay cache, might help, but performant >> replay caches are quite difficult to build. >> >> IOW, w/o an optional replay cache enforcement mechanism I think this >> SHOULD->MUST is just cosmetic. >> > > As stated in the PR, there might be implementations which reused keys > and were previously compliant. Enforcing this MUST would break interop > with them, so we can't do that. > Could there be willingness to fix the issue for those tls implementations ?
> -Ekr > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
