On Mon, Oct 20, 2025 at 7:03 AM Alicja Kario <[email protected]> wrote:
> On Monday, 20 October 2025 15:45:13 CEST, Eric Rescorla wrote: > > 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: > >>> ... > >> > >> 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. > > I was thinking of protocols where that is normal part of operation, like > SMTP. > Well, it's not clear to me that it's actually easier in SMTP, either, but as I understand it, it's actually quite common for SMTP clients not to verify the server certificate at all, right, in which case it doesn't matter whether the signature is PQ or not. >> 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. > > I think that providing easy way to allow people to drag their feet on this > won't improve the situation... I don't think that that's what this proposal does. Basically, I think we should aim for a > situation > where all major TLS clients and libraries simply don't advertise classical > crypto signatures as an option by default, in 10 years or so. > And so your preference is that in the intervening period, there's no way for servers to avoid exposure to CRQC-based attacks on authentication? -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
