Paul, Two members are not the WG. In fact these two members you specify have not expressed things one way or the other here. I have no idea why you think "pinning is suddenly acceptable" when we are actively debating that point right now. I also think pinning in general is a bad idea: we have experience, it creates massive problems for inexperienced operators if it is going to work, and most operators do not have the ability to make it work.
Sincerely, Watson On Thu, Feb 5, 2026 at 6:51 AM Paul Wouters <[email protected]> wrote: > > 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] -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
