[TLS] Re: Last Call: <draft-ietf-tls-mlkem-09.txt> (ML-KEM Post-Quantum Key Agreement for TLS 1.3) to Informat ional RFC

Dear IESG, cc'ing [email protected] and [email protected]:

I've sent four messages to [email protected] and [email protected] in
response to your limited-time "last call" for draft-ietf-tls-mlkem. They
appeared promptly on [email protected] but not on [email protected]:

    https://archive.cr.yp.to/2026-08-11/11:07:06/Py4B3LXgfQLJ5t3FqOWOuU8VGh7uZdCw98eLOzBWFpE/https/mailarchive.ietf.org/arch/msg/tls/g-oB-wLzxRO9VCrX1FPHQxVEfBE/
    https://archive.cr.yp.to/2026-08-11/11:07:17/PjAcoRVE3bZ26cFIfUYAM3kPKB0L7kdewHiJPD6U1vQ/https/mailarchive.ietf.org/arch/msg/tls/y8SB0h1D7IU1MD1ZQHpLuVJSm-g/
    https://archive.cr.yp.to/2026-08-11/11:07:28/dwRWTT0R3MycM7ejMvdh1D4VAqn-0VjpVihZjrY_Dw4/https/mailarchive.ietf.org/arch/msg/tls/0yf-y5TdzghP8F9j3hlNoSV20jc/
    https://archive.cr.yp.to/2026-08-11/11:07:40/4yNdY1U1i454phk2p_xUgbLI1ro7kCDgeu2DVmuCDc8/https/mailarchive.ietf.org/arch/msg/tls/yw4jeDTFmcHdWDehavATABn8pio/
    https://archive.cr.yp.to/2026-08-11/11:02:40/sbDH2sH-Sb9XVyVXI2e_D0Budfl6jd2T3yYhifTw8gg/https/mailarchive.ietf.org/arch/browse/static/last-call/2026-08/index.html

I presume the [email protected] censors blocked these messages---even
if just temporarily, something inappropriate for a limited-time process.
I wonder how many more community inputs the [email protected] censors
have been blocking.

("IETF participation is free and open to all interested individuals. ...
IETF activities are conducted with extreme transparency, in public
forums. Decision-making requires achieving broad consensus via these
public processes.")

Please confirm that you see my four messages (at the first four URLs
above) and that you will process them as inputs to this "last call".

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

That language hereby applies to this document. This is not disclaiming
or limiting the applicability of IETF policies; it is strictly following
IETF policies. IETF has similarly published, e.g., RFC 7425, which says
the following: "This document may not be modified, and derivative works
of it may not be created, except to format it for publication as an RFC
or to translate it into languages other than English."

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

IETF Executive Director Jay Daley says that informative text can
"contextualise and disambiguate normative text as it does here". When he
was asked what he claimed was ambiguous about the BCP 78 "explicitly
disallowed" provision, he did not reply. There is no ambiguity, and an
"Exposition of Why These Procedures Are the Way They Are" is not a
change to the procedures.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. However, BCP 78's default
position, without the opt-out, is a power grab that goes far beyond
redistribution and far beyond what copyright law allows as fair use
(such as giving quotes for purposes of commentary). BCP 78 authorizes
arbitrary modifications, such as plagiarism, quote falsification, data
falsification, and IETF management selling IETF mailing-list text in
bulk to AI companies spreading further misinformation.

For example, Google, a major source of IETF funds, systematically
ingests IETF mailing-list text into its AI system, which modifies the
text and frequently spits out misinformation to readers. IETF is only
one of many terms-of-service battlegrounds; this is not a reason to skip
the battle.

IETF itself also carries out problematic modifications. For example, in
May 2025, IESG posted an IESG-mangled version of an appeal that I had
filed, and then in its response confused exactly the point obfuscated by
that mangling. When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]