On Mon, Mar 16, 2026 at 11:47 AM Loganaden Velvindron <[email protected]> wrote:
> > > 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 ? > We don't have an inventory of those implementations, so we'll just see bustage in the field. I suppose we could make this a SHOULD NOT, but I think we really need to make clear that enforcement is a risky behavior. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
