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. This argument is laid out in a bit more detail at: https://educatedguesswork.org/posts/pq-emergency/#signature-algorithms -Ekr > > On Sunday, 19 October 2025 09:49:10 CEST, Yaron Sheffer wrote: > > Hi, > > We expect the migration of TLS endpoints to PQC to span several > > years. During this period, many clients will likely be > > configured to accept both traditional and PQ signatures or > > certificates, creating a potential for rollback attacks. Tiru > > and I have posted a draft proposing a simple solution based on > > TLS signaling combined with a client-side caching mechanism. > > This approach is inspired by HSTS but operates at the TLS layer > > rather than the HTTP layer. > > > > Thanks, > > Yaron > > > > On 19/10/2025, 9:22, "[email protected]" > > <[email protected]> wrote: > > > > A new version of Internet-Draft draft-sheffer-tls-pqc-continuity-00.txt > has > > been successfully submitted by Yaron Sheffer and posted to the > > IETF repository. > > > > Name: draft-sheffer-tls-pqc-continuity > > Revision: 00 > > Title: PQC Continuity: Downgrade Protection for TLS Servers > > Migrating to PQC > > Date: 2025-10-19 > > Group: Individual Submission > > Pages: 9 > > URL: > > https://www.ietf.org/archive/id/draft-sheffer-tls-pqc-continuity-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-sheffer-tls-pqc-continuity/ > > HTML: > > https://www.ietf.org/archive/id/draft-sheffer-tls-pqc-continuity-00.html > > HTMLized: > > https://datatracker.ietf.org/doc/html/draft-sheffer-tls-pqc-continuity > > > > > > Abstract: > > > > As the Internet transitions toward post-quantum cryptography (PQC), > > many TLS servers will continue supporting traditional certificates to > > maintain compatibility with legacy clients. However, this > > coexistence introduces a significant vulnerability: an undetected > > rollback attack, where a malicious actor strips the PQC or Composite > > certificate and forces the use of a traditional certificate once > > quantum-capable adversaries exist. > > > > To defend against this, this document defines a TLS extension that > > allows a client to cache a server's declared commitment to present > > PQC or composite certificates for a specified duration. On > > subsequent connections, clients enforce that cached commitment and > > reject traditional-only certificates that conflict with it. This > > mechanism, inspired by HTTP Strict Transport Security (HSTS) but > > operating at the TLS layer provides PQC downgrade protection without > > requiring changes to certificate authority (CA) infrastructure. > > > > > > > > The IETF Secretariat > > > > > > > > > > -- > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
