On Thu, 5 Feb 2026, Yaron Sheffer wrote: [ speaking very much as only an individual, not as AD ]
I cannot respond for the working group of course, but as far as I can tell the community is committed to migrating TLS to a PQC world, and this draft addresses one potential problem (rollback attacks) with this migration.
That's not really answering Viktor. For reference, EKR and Richard Barnes fiercly opposed any kind of pinning in browsers, that had the exact same property: prevent a downgrade attack. The concern at the time was that pinning would cause more damage to operations than it would protect. Seeing that we are far from actual quantum computers, it seems the same balancing act applies here. (for background of those who weren't around. This escalated to the point I could not even continue my presentation on the stage at that TLS WG meeting for being continuously interrupted and over talked that I had to step off the stage. The TLS WG was also very unhappy with this and no longer wanted it to take up time and unadopted the document not for technical reasons, but for not wanting to be involved reasons. The draft with pinning against downgrade solution then had to go to ISE to get published as RFC9102) I think it is a _very_ fair question now to ask why having pinning as a feature is suddenly acceptable. Because now it does appear that the original pushback was not about pinning, but about supporting an alternative trust model to the CAB/Forum (webpki) using DNSSEC(DANE). (And if pinning is okay now, whether the previous opponents of pinning will volunteer to bring the DANE extension via the TLS WG to Standards Track RFC 😜 ) Paul
Thanks, Yaron From: Viktor Dukhovni <[email protected]> Date: Wednesday, 4 February 2026 at 11:44 To: [email protected] <[email protected]> Subject: [TLS] Re: PQC Continuity draft (DANE chain déjà vu) On Mon, Feb 02, 2026 at 04:05:11PM +0000, Kampanakis, Panos wrote: > [1] https://datatracker.ietf.org/doc/draft-sheffer-tls-pqc-continuity/ The proposed "validity_period" component looks rather similar to what was proposed for the DANE chain extension some years back, which encountered fierce pushback from EKR and others and ultimately derailed that RFC. What's different this time? Why would it be OK for a server to commit to ongoing support for PQC certs when it wasn't OK for it to commit to ongoing support for DANE chains? -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ 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]
