Prior to the statement shared by the chair, I had participated but did not give a clear answer in the format as requested by said chairs, so I am providing my protocol following response here in the event the previous message may somehow remain uncounted:
I do not support publication of this document. > On Jul 3, 2026, at 10:28 AM, John Levine <[email protected]> wrote: > > It appears that Eliot Lear <[email protected]> said: >> Christian wrote: >> >>> The attitude of Jon Postel >>> at the time was that if something was going to be used, it is better to >>> publish it as an RFC. It ensures that if people are going to use a >>> specification, they all use it in a compatible way. It also ensures that >>> the specification becomes highly visible. And it reduces the motivation >>> to develop parallel publication channels for competing standards. >> >> This. Warts and all. That's why I support publication. > > Agreed. I also support publication. The late and great Dr. Jon Postel will always be remembered for his expansive contributions. That said, this Postel Principle has limits. We mustn’t standardize everything just because it exists, especially in the most widely used protocol TLS. Solo ML-KEM has already proven to be worse than hybrid kemecc. Publishing this RFC will signal legitimacy to what is, as of today, a downgrade [1]. The NSA really wants this to be published [4]. However, I have faith that the greatest of engineers participating in the IETF will stand on the side of the people. With faith, Andrew [1] Serious flaws in implementations continue to be discovered, daily, including, 1 day after this third round of votes began, in Wolf SSL [2] as Dr. Bernstein pointed out on the X platform [3]. [2] https://www.cve.org/CVERecord?id=CVE-2026-6330 [3] https://x.com/hashbreaker/status/2072760555044302904 [4] https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koXOLooFpU54/
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
