John Mattsson writes: > Based on the number of people who spoke up during the consensus call, > it is clear that many people share my concern.
No, you're conflating two separate calls. You're talking about the "WG Consensus Call: Prohibit Key Share Reuse Between Connections" from March regarding draft-ietf-tls-rfc8446bis. Nobody objected to that prohibition. I'm talking about the draft-ietf-tls-mlkem WGLC from February, the predecessor of the current WGLC. There were 22 people who filed objections to draft-ietf-tls-mlkem during that WGLC (for names, quotes, and links see https://blog.cr.yp.to/20260405-votes.html). You were the only objector to draft-ietf-tls-mlkem saying that you "support publication iff all text related to 'key reuse' is removed", i.e., saying that the key-share-reuse decision was central to your objection. As I said before, I agree with the chairs that _your_ objection was addressed by the reuse prohibition. Also, my understanding is that Muhammad Usama Sardar was satisfied with how his objection regarding formal analysis was addressed. But there are many more people who filed objections that solo PQ incurs unnecessary security risks compared to ECC+PQ. These are fundamental objections not addressed by a reuse prohibition or by formal analysis. When the chairs claim that changes have addressed "the concerns raised in the last WGLC" regarding solo ML-KEM, justifying a new WGLC, the chairs are simply ignoring these fundamental objections. The chairs have never even acknowledged the _number_ of people objecting, let alone the main content of the objections. ---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> The same language is used in, e.g., RFC 5831. The same language hereby applies to this document. This is not disclaiming or limiting the applicability of IETF policies; it is strictly following IETF policies. 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. Rationale for exercising the BCP 78 opt-out provision: I'm fine with redistribution of copies of this document. The issue is instead with modification, such as (1) IESG's May 2025 posting of an IESG-mangled version of an appeal that I had filed and (2) IETF management selling IETF mailing-list text to AI companies. This goes far beyond what copyright law allows as fair use (such as giving quotes for purposes of commentary). 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]
