Hi David, I agree! Rough consensus is not veto-based. I have not claimed otherwise, and I want to be clear about what I actually asked for.
A "blocking objection" in IETF practice is not a veto claim. It is a request that the chairs engage with the technical substance on the record before declaring consensus. RFC 7282, Section 3 (https://datatracker.ietf.org/doc/html/rfc7282#section-3) is explicit on this. The specific concerns I raised have not received that treatment. The FIPS 203 citation in Section 5.3, which attributes a key reuse bound to a document that contains no such bound, has not been corrected. FATT triage has not been answered on the record. The tension with SP 800-227 has not been resolved. If you or anyone on the list believes these concerns have been addressed, I would genuinely welcome hearing how. But a one-line invocation of rough consensus doctrine does not constitute that engagement. I would also remind you, as noted in my objection sent today, that, for the record, that the AD's February 20 message framed this second WGLC as a narrow confirmatory step on the grounds that the first WGLC "passed" with conditions. That characterization does not match what the chairs actually recorded. The December 8 conclusion, cited by the AD as his own reference [2], reads: "we do not have consensus to publish the document as is." The document was returned to WG Document state. Describing that outcome as having "passed" reverses the recorded finding, and it matters for how this second WGLC is scoped and conducted. As an aside, RFC 7282, Section 6 is also informative here (https://datatracker.ietf.org/doc/html/rfc7282#section-6). Nadim Kobeissi Symbolic Software • https://symbolic.software > On 21 Feb 2026, at 6:04 PM, David Adrian <[email protected]> wrote: > > > I ask the > > chairs to treat this as a blocking objection and to reflect it > > accurately in any consensus call summary. > > Rough consensus is not veto-based. > > On Sat, Feb 21, 2026 at 11:57 AM Deirdre Connolly <[email protected] > <mailto:[email protected]>> wrote: >> > The Motivation section of -07 states that pure ML-KEM key establishment >> is "necessary for migrating beyond hybrids and for users that want or >> need post-quantum security without hybrids." >> >> This is not the text in -07 nor the text on #main on GitHub including >> feedback from this call. This is the current text of the Motivation section: >> >> https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-07.html#section-1.1 >> >> "FIPS 203 (ML-KEM) [FIPS203] is a FIPS standard for post-quantum [RFC9794] >> key establishment via a lattice-based key encapsulation mechanism (KEM). >> This document defines key establishment options for TLS 1.3 that use solely >> post-quantum algorithms, without a hybrid construction that also includes a >> traditional cryptographic algorithm. Use cases include regulatory frameworks >> that require standalone post-quantum key establishment, targeting smaller >> key sizes or less computation, and simplicity." >> >> On Sat, Feb 21, 2026, 11:23 AM Nadim Kobeissi <[email protected]> >> wrote: >>> Hi everyone, >>> >>> Following the exchanges since my initial objection and after some >>> additional appraisal of the situation, I am writing to set out a fuller >>> objection to the publication of draft-ietf-tls-mlkem-07. I ask the >>> chairs to treat this as a blocking objection and to reflect it >>> accurately in any consensus call summary. >>> >>> I want to state my position plainly. I do not believe this document >>> should be published. A pure post-quantum key establishment option for >>> TLS 1.3 discards compositional security under component compromise -- a >>> property deliberately designed into TLS 1.3 that has served the deployed >>> Internet well -- and the document identifies no concrete benefit gained >>> in exchange. The hybrid constructions already adopted by this working >>> group provide post-quantum security while retaining that compositional >>> guarantee. This document proposes to remove that guarantee, and I have >>> yet to see a justification for doing so that withstands scrutiny. >>> >>> My background in formal verification of the TLS 1.3 key schedule -- >>> including co-authoring verified models that contributed directly to TLS >>> 1.3's standardization (Bhargavan, Blanchet, Kobeissi, IEEE S&P 2017, DOI >>> 10.1109/SP.2017.26) -- informs the specific concerns I set out below. >>> >>> --- >>> >>> 1. THE DOCUMENT'S MOTIVATION IS CIRCULAR >>> >>> The Motivation section of -07 states that pure ML-KEM key establishment >>> is "necessary for migrating beyond hybrids and for users that want or >>> need post-quantum security without hybrids." >>> >>> This is circular: it asserts that pure PQ key establishment is needed by >>> those who want pure PQ key establishment. The section does not identify >>> any deployment scenario in which a hybrid construction is technically >>> infeasible, any security property gained by removing the classical >>> component, or any basis for concluding that the time for "migrating >>> beyond hybrids" has arrived. >>> >>> The compositional security argument for hybrid constructions is >>> well-established: a hybrid key establishment scheme is secure if either >>> component is secure. ML-KEM is relatively young as a standardized >>> primitive; its mathematical hardness assumptions are less studied than >>> those underlying established elliptic curve constructions. The world's >>> Internet has been running TLS 1.3 with hybrid constructions for years, >>> providing post-quantum security via ML-KEM while retaining higher >>> assurance against classical attacks via ECC. Removing the classical >>> component of this working arrangement discards a concrete security >>> guarantee for no identified gain. >>> >>> One would expect that disrupting a functioning, well-analyzed status quo >>> would require exceptional motivation. The document does not provide one, >>> and none has been offered in discussion despite my repeated requests. I >>> cannot support publication of a standard that removes a security >>> property without justification. >>> >>> --- >>> >>> 2. THE FATT PROCESS HAS NOT BEEN COMPLETED >>> >>> The FATT charter (https://github.com/tlswg/tls-fatt) states: >>> >>> "A proposal that modifies the TLS key schedule or the authentication >>> process or any other part of the cryptographic protocol that has been >>> formally modeled and analyzed in the past would likely result in asking >>> the FATT." >>> >>> This document introduces pure ML-KEM as a NamedGroup, substituting the >>> ML-KEM shared_secret into the TLS 1.3 key schedule in place of the >>> (EC)DHE shared secret (Section 4.3, Figure 1). That substitution >>> directly affects a component of the TLS 1.3 key schedule that has been >>> formally modeled and analyzed, including in: >>> >>> - Bhargavan, Blanchet, Kobeissi, "Verified Models and Reference >>> Implementations for the TLS 1.3 Standard Candidate," IEEE S&P 2017, DOI >>> 10.1109/SP.2017.26. >>> >>> - Dowling, Fischlin, Gunther, Stebila, "A Cryptographic Analysis of >>> the TLS 1.3 Handshake Protocol," Journal of Cryptology, 2021, DOI >>> 10.1007/s00145-021-09384-1 (cited in the draft as [DOWLING]). >>> >>> The prior analyses modeled the (EC)DHE input as a freshly generated >>> ephemeral value. My own 2017 work explicitly modeled TLS 1.3 client key >>> shares as ephemeral. As Muhammad Usama Sardar noted on this list on >>> February 20, and as John Mattsson confirmed, this draft introduces a >>> materially different assumption: Section 5.3 of -07 explicitly permits >>> ML-KEM key share reuse. >>> >>> From direct knowledge of the 2017 proof, I can confirm that its >>> security arguments do not straightforwardly extend to a static key share >>> case. The proof relies on the ephemerality of client key shares at a >>> structural level. Substituting a potentially reused ML-KEM encapsulation >>> key for a fresh ephemeral (EC)DHE value changes the adversarial model >>> the proof operates under. >>> >>> Under the FATT charter, the chairs were expected to determine whether >>> FATT review was warranted at adoption time. I have been unable to find a >>> public record that FATT was engaged for this document: there is no FATT >>> point person named in the FATT repository, and no FATT assessment >>> appears in the shepherd write-up (which shows no shepherd assigned). >>> >>> I would appreciate it if the chairs could clarify on the record whether >>> FATT triage was initiated and, if so, what the outcome was. This is a >>> straightforward process question, and answering it would help the >>> working group understand whether this document has received the formal >>> analysis review that our own processes call for. >>> >>> --- >>> >>> 3. THE KEY REUSE LANGUAGE CONTAINS ERRORS AND CONFLICTS WITH NIST SP 800-227 >>> >>> Section 5.3 of -07 states: >>> >>> "While it is recommended that implementations avoid reuse of ML-KEM >>> keypairs to ensure forward secrecy, implementations that do reuse MUST >>> ensure that the number of reuses abides by bounds in [FIPS203] or >>> subsequent security analyses of ML-KEM." >>> >>> This language has two concrete problems. >>> >>> First, FIPS 203 does not define a reuse bound. FIPS 203 specifies the >>> ML-KEM algorithm; for usage guidance, it explicitly directs implementers >>> to SP 800-227. SP 800-227 is normatively cited in -07 as >>> [NIST-SP-800-227]. Section 5.3's invocation of "bounds in [FIPS203]" >>> attributes guidance to a document that does not contain it. This is a >>> factual error in normative text, verifiable by anyone who reads the >>> cited document. >>> >>> Second, SP 800-227 (September 2025) states: >>> >>> "If an application uses an ephemeral key pair, the key pair shall be >>> used for only one execution of key-establishment via a KEM and shall be >>> destroyed as soon as possible after its use." >>> >>> SP 800-227 distinguishes sharply between ephemeral keys, which are >>> single-use and must be destroyed, and static keys, which are reusable >>> but subject to additional authentication and key management requirements >>> including proof of possession. The draft simultaneously recommends >>> against reuse and permits it, with a MUST qualifier pointing to a bound >>> that does not exist in the cited document. The result is a normative >>> contradiction that implementers cannot resolve by reading the documents >>> cited. >>> >>> The security consequences of key reuse in deployed TLS go beyond the >>> IND-CCA property of ML-KEM in isolation. IND-CCA is a primitive-level >>> property; it does not guarantee forward secrecy, resistance to traffic >>> analysis based on linkability of reused encapsulation keys, or >>> compliance with SP 800-227's additional requirements for static-key >>> deployments. The draft addresses none of these protocol-level concerns. >>> >>> John Mattsson raised this point on February 12 and proposed removing all >>> key reuse text as the condition for his support. The changes in -07 >>> addressed his concern only partially and did not correct the FIPS 203 >>> citation. >>> >>> --- >>> >>> 4. THE FRAMING OF THIS SECOND WGLC DOES NOT ACCURATELY REFLECT THE FIRST >>> WGLC'S CONCLUSION >>> >>> Paul Wouters's message of February 20, sent in his capacity as AD, >>> describes the first WGLC as follows: >>> >>> "We already had a WGLC on this document [1] and the conclusion [2] >>> was that it passed WGLC provided some clarifying text would be >>> added that stated that for the general use case, hybrids were >>> preferred." >>> >>> This description does not match the conclusion it cites. The conclusion >>> of the first WGLC, as recorded by Joseph Salowey on December 8, 2025 in >>> the very message Wouters cites as [2], reads: >>> >>> "The working group last call for pure ML-KEM has concluded, thanks >>> to those that participated in the discussion. In summary, we do not >>> have consensus to publish the document as is. [...] Given this, the >>> chairs will move the document back to the 'WG Document' state and >>> ask the author to work on resolving the issues brought up on the >>> list including text to address concerns that there are reasons to >>> prefer hybrid over the pure approach. The chairs will then redo a >>> working group last call to see if there is rough consensus for >>> publishing this document." >>> >>> [2]: https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/ >>> >>> The recorded conclusion is an explicit finding of no consensus to >>> publish, with the document returned to WG Document state. Anyone can >>> read [2] and compare. Describing this outcome as the document having >>> "passed WGLC" is not a paraphrase; it reverses the recorded finding. >>> This matters because the framing of this second WGLC as a narrow >>> confirmatory step depends on that characterization. If the first WGLC >>> found no consensus -- as [2] explicitly records -- then this second WGLC >>> is properly a fresh determination of rough consensus, not a check on >>> whether added text satisfies conditional supporters. >>> >>> Per RFC 2418 Section 7.4, a working group last call determines rough >>> consensus across the working group as a whole. The first WGLC generated >>> substantive objections from multiple participants -- including D.J. >>> Bernstein, Stephen Farrell, Rich Salz, Simon Josefsson, and myself -- >>> that have not been resolved by the revisions in -07. The conclusion of >>> the first WGLC is itself under active appeal at the IESG >>> (https://datatracker.ietf.org/group/iesg/appeals/artifact/230). I would >>> ask the chairs to clarify how the interaction between that pending >>> appeal and this second WGLC is being handled. >>> >>> --- >>> >>> 5. SCOPE OF THIS OBJECTION >>> >>> I note the AD's guidance that this second WGLC is directed at assessing >>> whether the revisions in -07 address concerns raised in the first WGLC. >>> My response to that framing is twofold. >>> >>> First, several of the concerns I raise above are specific to the -07 >>> text itself: the FIPS 203 citation error, the SP 800-227 conflict, and >>> the absence of FATT review are all concerns that arise from -- or remain >>> unaddressed by -- the current revision. These are squarely within scope >>> of any reading of this WGLC's purpose. >>> >>> Second, the substantive objections from the first WGLC that were not >>> resolved by -07 do not lapse because a second WGLC has been called. The >>> revisions did not address the absence of a concrete motivation for >>> removing the classical component, did not initiate FATT review, did not >>> correct the FIPS 203 citation, and did not resolve the tension with SP >>> 800-227. These objections remain open. >>> >>> I ask the chairs to confirm that this objection has been received, that >>> it will be reflected in the consensus call summary, and that the pending >>> IESG appeal of the first WGLC's conclusion will be resolved before this >>> document advances. >>> >>> Nadim Kobeissi >>> Symbolic Software • https://symbolic.software <https://symbolic.software/> >>> >>> On 2/21/26 11:28 AM, Nadim Kobeissi wrote: >>> > Hi Paul, >>> > >>> > You write: >>> > >>> >> We already had a WGLC on this document [1] and the conclusion [2] was >>> >> that it passed WGLC provided some clarifying text would be added that >>> >> stated that for the general use case, hybrids were preferred. >>> > >>> > I just had a look at [2] and to my surprise, it didn’t seem to match >>> > your description. What [2] seems to show was that the chairs decided >>> > that there was no consensus. Quoting: >>> > >>> > > The working group last call for pure ML-KEM has concluded, thanks to >>> > those >>> > > that participated in the discussion. In summary, we do not have >>> > consensus >>> > > to publish the document as is. >>> > > […] >>> > > Given this, the chairs will move the document back to the "WG Document" >>> > > state and ask the author to work on resolving the issues brought up >>> > on the >>> > > list including text to address concerns that there are reasons to >>> > prefer >>> > > hybrid over the pure approach. The chairs will then redo a working >>> > group >>> > > last call to see if there is rough consensus for publishing this >>> > document. >>> > >>> > I am very confused. You say that [2] showed that it passed WGLC provided >>> > that some clarifying text would be added. Absolutely none of this is >>> > reflected in [2]. Instead, what [2] shows is an explicit admission of >>> > the lack of any consensus to publish the document, and the document >>> > being moved back to a “WG Document” state. >>> > >>> > Could you please clarify this rather large discrepancy between your >>> > description of [2] and what [2] actually appears to say? >>> > >>> > Thank you, >>> > >>> > [2] https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/ >>> > >>> > Nadim Kobeissi >>> > Symbolic Software • https://symbolic.software <https://symbolic.software/> >>> > >>> >> On 20 Feb 2026, at 4:00 PM, Paul Wouters >>> >> <[email protected] <mailto:[email protected]>> >>> >> wrote: >>> >> >>> >> >>> >> [ AD hat on ] >>> >> >>> >> All, >>> >> >>> >> I want to remind people that the goal of this 2nd WGLC is to focus on >>> >> the new text changed in responds to the conclusion of the 1st WGLC. >>> >> >>> >> We already had a WGLC on this document [1] and the conclusion [2] was >>> >> that it passed WGLC provided some clarifying text would be added that >>> >> stated that for the general use case, hybrids were preferred. This >>> >> 2nd WGLC is about that topic. >>> >> >>> >> There is an appeal chain that got muddled by the inappropriate use of >>> >> derivative clauses that is still in progress, but so far yielded the AD >>> >> statement [3] that confirmed the WG Chairs view that the consensus call >>> >> passed. There is an appeal with the IESG [4] on that decision, and this >>> >> document will not be placed in the RFC Editor queue until that appeal has >>> >> concluded, but will also not stop all processing while the appeal runs. >>> >> >>> >> This 2nd WGLC is meant to get those people who provisionally said "yes" >>> >> to publication of this document pending some extra text, to review this >>> >> text and let us know if that resolves the conditional part of their >>> >> "yes" statement. The text changes to discuss can be seen at: >>> >> >>> >> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls- >>> >> mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html >>> >> >>> >> >>> >> I understand this is a heated topic. I am also not hearing from people >>> >> that they have changed their opinion on whether or not to publish this >>> >> document at all. Confirming your views are fine, but again, that is not >>> >> the goal of this 2nd WGLC. It would be helpful if, especially those >>> >> people who wanted additional clarifying text, to give us feedback on >>> >> this. And ideally, offer up suggestions that would address any still >>> >> outstanding issues. >>> >> >>> >> Thanks, >>> >> >>> >> Paul >>> >> >>> >> [1] >>> >> https://mailarchive.ietf.org/arch/msg/tls/Pzdox1sDDG36q19PWDVPghsiyXA/ >>> >> [2] >>> >> https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/ >>> >> [3] >>> >> https://mailarchive.ietf.org/arch/msg/tls/dzPT8KQe4S-_pZROLUJMvS9pM0M/ >>> >> [4] https://datatracker.ietf.org/group/iesg/appeals/artifact/230 >>> >> >>> >> _______________________________________________ >>> >> TLS mailing list -- [email protected] <mailto:[email protected]> >>> >> To unsubscribe send an email to [email protected] >>> >> <mailto:[email protected]> >>> > >>> >>> _______________________________________________ >>> TLS mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> _______________________________________________ >> TLS mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
