On Tue, Apr 7, 2026 at 5:59 PM Nico Williams <[email protected]> wrote: > > On Tue, Apr 07, 2026 at 05:04:53PM -0700, Rob Sayre wrote: > > On Tue, Apr 7, 2026 at 4:22 PM Stephen Farrell <[email protected]> > > wrote: > > > On 07/04/2026 21:35, Paul Wouters wrote: > > > > The contention is whether it should be published now or later, when > > > > classic protections gain us little to no benefit. > > > > > > From my POV, that mischaracterises the contention. I think > > > the contentious issue is whether or not to publish this with > > > or without caveats as to when to use it, and how to encode > > > any such caveats in RFC/BCP text. > > > > There are two things here: > > > > 1) The IEEE group wants an RFC. They can advocate for this just as anyone > > else can. (yes!) > > > > 2) The IETF must do an RFC because the IEEE has made a requirement (no!) > > > > That cedes sovereignty, and we shouldn't do that. > > If the IEEE publishes their own w/o the guidance we would have written > in ours, then we've "ceded sovereignty" anyways in that we would have > lost an opportunity to give guidance. Either way non-hybrid PQ happens, > so what will have anyone "won"?
Huh? The TLS Key Exchange registry policy is open precisely so that anyone can use any key exchange they want in an interoperable way, and this change was made exactly so that the TLS WG would not get dragged into debates over what one to use. Clearly that's failed, but a lot of the arguments about why this draft needs to go out end up applying more broadly and get us back to the situation we tried to avoid by making that registry change. That's the problem: we specifically didn't want to end up with a bunch of low value from a specification standpoint RFCs jamming up the process. > > Nico > -- > > _______________________________________________ > 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]
