On Mon, Oct 20, 2025 at 6:40 AM Alicja Kario <[email protected]> wrote:
> On Monday, 20 October 2025 14:28:44 CEST, Eric Rescorla wrote: > > On Mon, Oct 20, 2025 at 5:17 AM Alicja Kario <hkario= > > [email protected]> wrote: > > > >> I fail to see the usefullness of it... > >> > >> If we are at a time where we consider quantum attacks as realistic, > >> the client should simply not advertise support for classical signatures > >> at all. Then the server can't propose a classical certificate and > >> remain compliant with the protocol... > >> > > > > The consequence of this will be that clients aren't able to establish > > TLS connections with servers without PQ certs. If breaking a traditional > > system with a CRQC is really cheap, that may or may not be bad, but > > it's possible that it will be quite expensive (e.g., only within the > > capabilities > > of a nation state attacker), in which case it would probably be better > > that people be able to establish TLS connections with such servers > > rather than just experience failures or connect in the clear. > > Falling back to cleartext can be achieved with much simpler means, if the > client allows for that at all, so I don't think we should consider that. > My point is that in this scenario is that falling back to cleartext is worse than using a traditional algorithm. Moreover, it's actually not obviously the case that it is easier, given browser architecture, to fall back to cleartext, even assuming it was superior. Now, going back to the migration. Yes, the attacks will be expensive at the > beginning, but I think what we should aim for is NOT to repeat the > situation > with SHA-1, where the web was dragging its feet for like 10 years before > SHA-1 > was properly distrusted. > I agree that we should try not to repeat that. The question is what the best way to do that is. -Ekr > -- > Regards, > Alicja Kario > Principal Quality Engineer, RHEL Crypto team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
