The TLS WG chairs write: > Significant developments have occurred both within this document and > in the broader TLS ecosystem to address the concerns raised in the > last WGLC.
False. For example, none of that has addressed the following objection from Izzy Grosof: "The performance improvements of a non-hybrid approach are trifling; the security risks are immense ... Do not endorse or standardize any non-hybrid post-quantum cryptosystem, via this document or any other." This isn't an isolated example of an unaddressed objection. In the last WGLC, there were 22 people speaking up against the document (vs. 21 in favor). The majority of those 22 people stated objections centered on solo PQ incurring unnecessary security risks compared to hybrids. See https://blog.cr.yp.to/20260405-votes.html for names, quotes, and links. RFC 2026, Section 6.5, authorizes process complaints from individuals whose views have not been adequately considered by the WG. I'm hereby invoking this provision to ask for withdrawal of this WGLC---a WGLC founded upon disregarding objections from many people, including me. The chairs have never acknowledged the level of opposition. The chairs have never acknowledged the main content of the opposition. This new last call takes minor issues and misrepresents those as "the concerns raised in the last WGLC". I'm saying "minor" because, in fact, only a few people raised those _as objections_, no matter how many times _proponents_ might have claimed that those issues are central. What's particularly pernicious about the chair refusal to acknowledge the majority of the objections is that the chairs also wrote "Please refrain from further discussion on this topic". RFC 2418 requires disagreements to be "resolved by a process of open review and discussion"; the chairs are actively sabotaging this process. > Therefore, the third consensus call is warranted. No, it is not. It is an abuse of power by the chairs, inflicting costs upon opponents to object again and again. Defense contractors paying people to show up here can easily afford these costs, but for normal people these costs are important. IETF says it isn't a pay-to-play organization. IETF says it makes decisions by consensus. IETF says disagreements must be _resolved_. > - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a > separate consensus call, the WG agreed to promote the X25519MLKEM768 > hybrid group to Recommended: Y in the IANA registry. This argument might be relevant in a fantasy world where corporate purchasing managers understand IETF endorsement to be conveyed not by the issuance of RFCs but rather by the IANA registry. In the real world, I'm sure a survey will show that the majority haven't even heard of the IANA registry. They also don't check the RFCs they're requiring to check for unexplained buried notes saying "Recommended: N". We've even seen Eric Rescorla admitting this: "I think it's clear that many regard the publication of an RFC by the TLS WG as a form of endorsement, even when Recommended=N [0]. In fact, this is precisely why the publication of some documents has become so controversial. ... [0] I don't think this position is entirely unreasonable given that the documents state on the face of them that they 'represent[s] the consensus of the IETF community.' " Just to emphasize: that's admitting the controversy regarding _the WG issuing an RFC_ (the proposal on the table). It's also admitting that pointing to "Recommended: N" doesn't address the controversy. Now the chairs are pointing to "Recommended: N" (by comparison to "Recommended: Y" in a better spec) and claiming that this addresses the controversy. No, it doesn't. Any action that will be interpreted as endorsing this security-sabotaging spec is unacceptable. The issuance of an RFC will be viewed as IETF endorsement; that's unacceptable. The (fraudulent) claim of "consensus of the IETF community" will also be viewed as IETF endorsement; that's also unacceptable. > Consequently, the IANA registry will reflect a clear community > preference for a hybrid If there's a clear community preference for ECC+PQ, then why are we seeing endless pushes for solo PQ? We've already been told the answer. An NSA employee wrote "we are looking for products that support /standalone/ ML-DSA-87 and /standalone/ ML-KEM-1024. If there is one vendor that produces one product that complies, then that is the product that goes on the compliance list and is approved for use. Our interactions with vendors suggests that this won't be a problem in most cases"; a Cisco employee wrote "There are people whose cryptographic expertise I cannot doubt who say that pure ML-KEM is the right trade-off for them, and more importantly for my employer, that's what they're willing to buy. Hence, Cisco will implement it"; etc. This violates a rule labeled in https://web.archive.org/web/20250528213926/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/ as "fundamental": "IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user." See also https://web.archive.org/web/20260622091826/https://www.ietf.org/support-us/endowment/ saying that "participants cannot exert influence as they could in a pay-to-play organization where members, companies, or governments pay fees to set the direction". What's happening here is NSA overtly paying to influence IETF's direction. More recently (perhaps because arguments along the lines of "NSA wants this so we'll standardize it" don't exactly look good in the sunlight) we've seen other arguments for solo PQ, such as * the claim that "pure-mlkem is the obviously correct solution if you want high-performance solutions"; * an emphasis that "we have implemented this in Chrome"; and * a claim that deploying ECC+PQ would require a "second large-scale engineering effort to migrate to pure ML-KEM sometime later" and "would consume literal years of my life". But these arguments can't be reconciled with the supposed clarity of the community preference for ECC+PQ. As I put it in a previous message: "Who's the supposed user base for these specs? The answers are absurdly inconsistent. Someone asking about the purported _advantage_ of solo PQ over ECC+PQ is treated to wild exaggerations of the cost difference and to a whac-a-mole game of supposed applications (such as 'high-frequency trading'). Someone asking about the _security damage_ is instead told that this is just for NSA. C'mon, this doesn't pass the laugh test." > because Recommended: Y clearly indicates this while the standalone > ML-KEM groups defined in this draft remain Recommended: N. There are endless statements contradicting the idea that "Y" vs. "N" for "Recommended" clearly communicates a preference of one algorithm over another. For example: * Eric Rescorla wrote that a preference "isn't what Recommended=Y/N means in the context of TLS ... which is why we have four separate recommended EC curves" and that "The mechanism for encouraging implementors to actually use/deploy a draft is SHOULD/MUST implement". * RFC 8447 states a variety of different possible situations that can all produce Recommended: N, such as an item that "has limited applicability" _or_ "is intended only for specific use cases" _or_ merely "has not been through the IETF consensus process". * RFC 9847 says something different, namely that Recommended: N means that "the item has not been evaluated by the IETF" _and_ "that the IETF has made no statement about the suitability of the associated mechanism". * Meanwhile RFC 9487 says that Recommended: Y "only means that the associated mechanism is fit for the purpose for which it was defined". How can the chairs be claiming that "the IANA registry will reflect a clear community preference for a hybrid because Recommended: Y clearly indicates this" when they're authors of an RFC from last month saying that Recommended: Y means something else? Anyway, there's no point trying to disentangle this mess. The victims of RFCs on solo PQ usually won't even _see_ "Recommended: N" vs. "Y", so they won't be in the situation of trying to figure out what it means. It's instructive to look at https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf saying "The SIGINT Enabling Project actively engages the US and foreign IT industries to covertly influence and/or overtly leverage their commercial products' designs. ... To the consumer and other adversaries, however, the systems' security remains intact." That nicely summarizes what's happening here. Overt leverage by NSA is removing the protection provided by ECC, but people all the way from purchasing managers to the end consumers aren't being _told_ that this protection has been removed. > The updated security considerations in [1] reference the IANA registry > to emphasize this preference. "Emphasize"? What the chairs are talking about here, as far as I can tell, is the last sentence of "5. Security Considerations", which currently says "The recommended column in the IANA TLS Supported Groups registry contains the IETF's current guidance on the recommended use of these algorithms for general purposes." How is this text emphasizing a preference for hybrids? I simply don't see that in the text. Furthermore, the _positioning_ of this text is _deemphasizing_ it. The text is buried much more deeply than, e.g., the text "consensus of the IETF community" that's automatically added to all WG RFCs, or the text "ML-KEM [FIPS203] is a FIPS standard for post-quantum [RFC9794] key establishment via a lattice-based key encapsulation mechanism (KEM)" in the introduction. The occasional reader who makes it to the security-considerations section sees the following text at the top of that section: "This document defines standalone ML-KEM key establishment for TLS 1.3. Use of KEMs for key agreement in TLS 1.3 has been analyzed in multiple settings and security models [DOWLING] [KEMTLS] [HV22] [CHSW22] [CZCJWH25] [ZJZ24]; ML-KEM's IND-CCA security exceeds the requirements for ephemeral key establishment [GHS25] [RFC8446bis]." To be clear, I would be opposed to an RFC specifying solo PQ even if it _did_ have prominent warnings. Many people will treat the issuance of an RFC as IETF endorsement without ever seeing the warnings. > - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG > recently reached consensus to explicitly prohibit key share reuse > across connections in TLS 1.3. The new text changes the guidance from > SHOULD NOT to a strict MUST NOT. This resolves the concerns regarding > static key reuse and its associated privacy and forward-secrecy risks > for ML-KEM. It has always been clear that this matters for one person. John Mattsson during the adoption call wrote "I support adoption as long as reuse of ephemeral keys is normatively forbidden, i.e. MUST NOT reuse"; he has made similar comments afterwards. However, the majority of people stating objections have done so on more fundamental grounds than this. See my chart https://blog.cr.yp.to/20260221-structure.html of the arguments and counterarguments; someone claiming to "address the concerns raised" should be addressing, e.g., "weakening normal ECC+PQ to solo PQ creates security risks", not just the sideshow about "whether ML-KEM key reuse should be prohibited". > - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and > hybrid KEM groups in TLS 1.3. This supports other results which show > that KEMs are secure when used in TLS 1.3 and that hybrid groups are > secure even if one of the components is compromised. My understanding is that such formal analysis moved Muhammad Usama Sardar from opposition to neutral. But, again, the majority of people stating objections have done so on more fundamental grounds than this. > - Liaisons: We received liaison statements from multiple SDOs > including O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing > support for the publication of draft-ietf-tls-mlkem as an RFC as they > rely on the IETF to provide a stable normative reference. An organization trying to influence IETF decisions via liaison statements to WGs is violating the following rule from RFC 2418: "Participation is by individual technical contributors, rather than by formal representatives of organizations." I'm hereby complaining under RFC 2026, Section 6.5, about this process violation, and requesting that the chairs explicitly bar all liaison statements. A closer look at the content---see https://web.archive.org/web/20260628104623/https://mailarchive.ietf.org/arch/msg/tls/Jt6-6ssv7zUBHMgIzXaxw_PfJYQ/ ---also finds severe problems with what the chairs are claiming here. The chairs have never addressed any part of this; they just wave again and again at liaisons while ignoring the procedural objections and content objections. Anyway, claiming that NSA etc. want solo PQ, or even that they demand solo PQ, is non-responsive to the objections saying that solo PQ incurs unnecessary security risks compared to ECC+PQ. ---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]
