Feedback-ID: i6d3949ed:Fastmail
From: Nadim Kobeissi <nadim@symbolic.software>
Message-Id: <B1DCBF8E-696A-4FFB-9B55-0A7BC25E89B4@symbolic.software>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0F908F55-5D41-4CA1-B8BB-34C8C68D6B9F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Date: Sat, 21 Feb 2026 18:56:57 +0100
In-Reply-To: 
 <CACf5n79d=6sCXDJVoOPmELiRpjifBEo6rc30oK2Q7FGpKOLpNA@mail.gmail.com>
To: David Adrian <davadria@umich.edu>
References: <20260218194044.1135896.qmail@cr.yp.to>
 <7C9C99AA-42B0-4BC7-8F41-39F35754F1C4@vigilsec.com>
 <MN2PR17MB40310F0A2891942D76C43E60CD6BA@MN2PR17MB4031.namprd17.prod.outlook.com>
 <2caab265-00ba-4078-b6d0-3a178dabaa61@tu-dresden.de>
 <CAEEbLAbkV4YxN7cgggckpEp24MLtRZpzs6M4KemBatpzCCcs0A@mail.gmail.com>
 <MEAPR01MB3654415F735DE96CEE239C78EE68A@MEAPR01MB3654.ausprd01.prod.outlook.com>
 <aZfbhrFDBp7a0xHL@chardros.imrryr.org>
 <EB48AB24-A1A2-47C8-9C2C-47C93B9320E7@thomwiggers.nl>
 <93af0689-4bd3-4f6b-afaf-41869d27fa4d@app.fastmail.com>
 <CAMtubr3QcHbiP5guhBoiFbFh8tKSD6WNHBJkxxb_AM4Wy5i0=g@mail.gmail.com>
 <9b71e709-69a3-f3d9-4cbd-d4d521556c55@nohats.ca>
 <971672FF-31BE-47C4-A478-8FEB60DE3F7A@symbolic.software>
 <66970fb7-0645-4fff-8b9e-48f6bad3e007@symbolic.software>
 <CAFR824xy-Kv8PKUnWenjKhUg+YippeK7Xp2Nrr3gbAGpJDf0VQ@mail.gmail.com>
 <CACf5n79d=6sCXDJVoOPmELiRpjifBEo6rc30oK2Q7FGpKOLpNA@mail.gmail.com>
Message-ID-Hash: LUI3WSHVIMEXQB4BXRJSHXWQOBJBJ5U4
CC: Paul Wouters <paul=40nohats.ca@dmarc.ietf.org>,
 "TLS@ietf.org" <tls@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-05_=28Ends_20?=
	=?utf-8?q?26-02-27=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/a4fgfugr40soNTsF5l52--RgDco>


--Apple-Mail=_0F908F55-5D41-4CA1-B8BB-34C8C68D6B9F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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 =E2=80=A2 https://symbolic.software

> On 21 Feb 2026, at 6:04=E2=80=AFPM, David Adrian <davadria@umich.edu> =
wrote:
>=20
> > I ask the
> > chairs to treat this as a blocking objection and to reflect it
> > accurately in any consensus call summary.
>=20
> Rough consensus is not veto-based.
>=20
> On Sat, Feb 21, 2026 at 11:57=E2=80=AFAM Deirdre Connolly =
<durumcrustulum@gmail.com <mailto:durumcrustulum@gmail.com>> 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."
>>=20
>> 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:=20
>>=20
>> =
https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-07.html#section-1.1
>>=20
>> "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."
>>=20
>> On Sat, Feb 21, 2026, 11:23=E2=80=AFAM Nadim Kobeissi =
<nadim@symbolic.software> wrote:
>>> Hi everyone,
>>>=20
>>> Following the exchanges since my initial objection and after some=20
>>> additional appraisal of the situation, I am writing to set out a =
fuller=20
>>> objection to the publication of draft-ietf-tls-mlkem-07. I ask the=20=

>>> chairs to treat this as a blocking objection and to reflect it=20
>>> accurately in any consensus call summary.
>>>=20
>>> I want to state my position plainly. I do not believe this document=20=

>>> should be published. A pure post-quantum key establishment option =
for=20
>>> TLS 1.3 discards compositional security under component compromise =
-- a=20
>>> property deliberately designed into TLS 1.3 that has served the =
deployed=20
>>> Internet well -- and the document identifies no concrete benefit =
gained=20
>>> in exchange. The hybrid constructions already adopted by this =
working=20
>>> group provide post-quantum security while retaining that =
compositional=20
>>> guarantee. This document proposes to remove that guarantee, and I =
have=20
>>> yet to see a justification for doing so that withstands scrutiny.
>>>=20
>>> My background in formal verification of the TLS 1.3 key schedule --=20=

>>> including co-authoring verified models that contributed directly to =
TLS=20
>>> 1.3's standardization (Bhargavan, Blanchet, Kobeissi, IEEE S&P 2017, =
DOI=20
>>> 10.1109/SP.2017.26) -- informs the specific concerns I set out =
below.
>>>=20
>>> ---
>>>=20
>>> 1. THE DOCUMENT'S MOTIVATION IS CIRCULAR
>>>=20
>>> The Motivation section of -07 states that pure ML-KEM key =
establishment=20
>>> is "necessary for migrating beyond hybrids and for users that want =
or=20
>>> need post-quantum security without hybrids."
>>>=20
>>> This is circular: it asserts that pure PQ key establishment is =
needed by=20
>>> those who want pure PQ key establishment. The section does not =
identify=20
>>> any deployment scenario in which a hybrid construction is =
technically=20
>>> infeasible, any security property gained by removing the classical=20=

>>> component, or any basis for concluding that the time for "migrating=20=

>>> beyond hybrids" has arrived.
>>>=20
>>> The compositional security argument for hybrid constructions is=20
>>> well-established: a hybrid key establishment scheme is secure if =
either=20
>>> component is secure. ML-KEM is relatively young as a standardized=20
>>> primitive; its mathematical hardness assumptions are less studied =
than=20
>>> those underlying established elliptic curve constructions. The =
world's=20
>>> Internet has been running TLS 1.3 with hybrid constructions for =
years,=20
>>> providing post-quantum security via ML-KEM while retaining higher=20
>>> assurance against classical attacks via ECC. Removing the classical=20=

>>> component of this working arrangement discards a concrete security=20=

>>> guarantee for no identified gain.
>>>=20
>>> One would expect that disrupting a functioning, well-analyzed status =
quo=20
>>> would require exceptional motivation. The document does not provide =
one,=20
>>> and none has been offered in discussion despite my repeated =
requests. I=20
>>> cannot support publication of a standard that removes a security=20
>>> property without justification.
>>>=20
>>> ---
>>>=20
>>> 2. THE FATT PROCESS HAS NOT BEEN COMPLETED
>>>=20
>>> The FATT charter (https://github.com/tlswg/tls-fatt) states:
>>>=20
>>>    "A proposal that modifies the TLS key schedule or the =
authentication=20
>>> process or any other part of the cryptographic protocol that has =
been=20
>>> formally modeled and analyzed in the past would likely result in =
asking=20
>>> the FATT."
>>>=20
>>> This document introduces pure ML-KEM as a NamedGroup, substituting =
the=20
>>> ML-KEM shared_secret into the TLS 1.3 key schedule in place of the=20=

>>> (EC)DHE shared secret (Section 4.3, Figure 1). That substitution=20
>>> directly affects a component of the TLS 1.3 key schedule that has =
been=20
>>> formally modeled and analyzed, including in:
>>>=20
>>>    - Bhargavan, Blanchet, Kobeissi, "Verified Models and Reference=20=

>>> Implementations for the TLS 1.3 Standard Candidate," IEEE S&P 2017, =
DOI=20
>>> 10.1109/SP.2017.26.
>>>=20
>>>    - Dowling, Fischlin, Gunther, Stebila, "A Cryptographic Analysis =
of=20
>>> the TLS 1.3 Handshake Protocol," Journal of Cryptology, 2021, DOI=20
>>> 10.1007/s00145-021-09384-1 (cited in the draft as [DOWLING]).
>>>=20
>>> The prior analyses modeled the (EC)DHE input as a freshly generated=20=

>>> ephemeral value. My own 2017 work explicitly modeled TLS 1.3 client =
key=20
>>> shares as ephemeral. As Muhammad Usama Sardar noted on this list on=20=

>>> February 20, and as John Mattsson confirmed, this draft introduces a=20=

>>> materially different assumption: Section 5.3 of -07 explicitly =
permits=20
>>> ML-KEM key share reuse.
>>>=20
>>>  =46rom direct knowledge of the 2017 proof, I can confirm that its=20=

>>> security arguments do not straightforwardly extend to a static key =
share=20
>>> case. The proof relies on the ephemerality of client key shares at a=20=

>>> structural level. Substituting a potentially reused ML-KEM =
encapsulation=20
>>> key for a fresh ephemeral (EC)DHE value changes the adversarial =
model=20
>>> the proof operates under.
>>>=20
>>> Under the FATT charter, the chairs were expected to determine =
whether=20
>>> FATT review was warranted at adoption time. I have been unable to =
find a=20
>>> public record that FATT was engaged for this document: there is no =
FATT=20
>>> point person named in the FATT repository, and no FATT assessment=20
>>> appears in the shepherd write-up (which shows no shepherd assigned).
>>>=20
>>> I would appreciate it if the chairs could clarify on the record =
whether=20
>>> FATT triage was initiated and, if so, what the outcome was. This is =
a=20
>>> straightforward process question, and answering it would help the=20
>>> working group understand whether this document has received the =
formal=20
>>> analysis review that our own processes call for.
>>>=20
>>> ---
>>>=20
>>> 3. THE KEY REUSE LANGUAGE CONTAINS ERRORS AND CONFLICTS WITH NIST SP =
800-227
>>>=20
>>> Section 5.3 of -07 states:
>>>=20
>>>    "While it is recommended that implementations avoid reuse of =
ML-KEM=20
>>> keypairs to ensure forward secrecy, implementations that do reuse =
MUST=20
>>> ensure that the number of reuses abides by bounds in [FIPS203] or=20
>>> subsequent security analyses of ML-KEM."
>>>=20
>>> This language has two concrete problems.
>>>=20
>>> First, FIPS 203 does not define a reuse bound. FIPS 203 specifies =
the=20
>>> ML-KEM algorithm; for usage guidance, it explicitly directs =
implementers=20
>>> to SP 800-227. SP 800-227 is normatively cited in -07 as=20
>>> [NIST-SP-800-227]. Section 5.3's invocation of "bounds in [FIPS203]"=20=

>>> attributes guidance to a document that does not contain it. This is =
a=20
>>> factual error in normative text, verifiable by anyone who reads the=20=

>>> cited document.
>>>=20
>>> Second, SP 800-227 (September 2025) states:
>>>=20
>>>    "If an application uses an ephemeral key pair, the key pair shall =
be=20
>>> used for only one execution of key-establishment via a KEM and shall =
be=20
>>> destroyed as soon as possible after its use."
>>>=20
>>> SP 800-227 distinguishes sharply between ephemeral keys, which are=20=

>>> single-use and must be destroyed, and static keys, which are =
reusable=20
>>> but subject to additional authentication and key management =
requirements=20
>>> including proof of possession. The draft simultaneously recommends=20=

>>> against reuse and permits it, with a MUST qualifier pointing to a =
bound=20
>>> that does not exist in the cited document. The result is a normative=20=

>>> contradiction that implementers cannot resolve by reading the =
documents=20
>>> cited.
>>>=20
>>> The security consequences of key reuse in deployed TLS go beyond the=20=

>>> IND-CCA property of ML-KEM in isolation. IND-CCA is a =
primitive-level=20
>>> property; it does not guarantee forward secrecy, resistance to =
traffic=20
>>> analysis based on linkability of reused encapsulation keys, or=20
>>> compliance with SP 800-227's additional requirements for static-key=20=

>>> deployments. The draft addresses none of these protocol-level =
concerns.
>>>=20
>>> John Mattsson raised this point on February 12 and proposed removing =
all=20
>>> key reuse text as the condition for his support. The changes in -07=20=

>>> addressed his concern only partially and did not correct the FIPS =
203=20
>>> citation.
>>>=20
>>> ---
>>>=20
>>> 4. THE FRAMING OF THIS SECOND WGLC DOES NOT ACCURATELY REFLECT THE =
FIRST=20
>>> WGLC'S CONCLUSION
>>>=20
>>> Paul Wouters's message of February 20, sent in his capacity as AD,=20=

>>> describes the first WGLC as follows:
>>>=20
>>>    "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."
>>>=20
>>> This description does not match the conclusion it cites. The =
conclusion=20
>>> of the first WGLC, as recorded by Joseph Salowey on December 8, 2025 =
in=20
>>> the very message Wouters cites as [2], reads:
>>>=20
>>>    "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."
>>>=20
>>> [2]: =
https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/
>>>=20
>>> The recorded conclusion is an explicit finding of no consensus to=20
>>> publish, with the document returned to WG Document state. Anyone can=20=

>>> read [2] and compare. Describing this outcome as the document having=20=

>>> "passed WGLC" is not a paraphrase; it reverses the recorded finding.=20=

>>> This matters because the framing of this second WGLC as a narrow=20
>>> confirmatory step depends on that characterization. If the first =
WGLC=20
>>> found no consensus -- as [2] explicitly records -- then this second =
WGLC=20
>>> is properly a fresh determination of rough consensus, not a check on=20=

>>> whether added text satisfies conditional supporters.
>>>=20
>>> Per RFC 2418 Section 7.4, a working group last call determines rough=20=

>>> consensus across the working group as a whole. The first WGLC =
generated=20
>>> substantive objections from multiple participants -- including D.J.=20=

>>> Bernstein, Stephen Farrell, Rich Salz, Simon Josefsson, and myself =
--=20
>>> that have not been resolved by the revisions in -07. The conclusion =
of=20
>>> the first WGLC is itself under active appeal at the IESG=20
>>> (https://datatracker.ietf.org/group/iesg/appeals/artifact/230). I =
would=20
>>> ask the chairs to clarify how the interaction between that pending=20=

>>> appeal and this second WGLC is being handled.
>>>=20
>>> ---
>>>=20
>>> 5. SCOPE OF THIS OBJECTION
>>>=20
>>> I note the AD's guidance that this second WGLC is directed at =
assessing=20
>>> whether the revisions in -07 address concerns raised in the first =
WGLC.=20
>>> My response to that framing is twofold.
>>>=20
>>> First, several of the concerns I raise above are specific to the -07=20=

>>> text itself: the FIPS 203 citation error, the SP 800-227 conflict, =
and=20
>>> the absence of FATT review are all concerns that arise from -- or =
remain=20
>>> unaddressed by -- the current revision. These are squarely within =
scope=20
>>> of any reading of this WGLC's purpose.
>>>=20
>>> Second, the substantive objections from the first WGLC that were not=20=

>>> resolved by -07 do not lapse because a second WGLC has been called. =
The=20
>>> revisions did not address the absence of a concrete motivation for=20=

>>> removing the classical component, did not initiate FATT review, did =
not=20
>>> correct the FIPS 203 citation, and did not resolve the tension with =
SP=20
>>> 800-227. These objections remain open.
>>>=20
>>> I ask the chairs to confirm that this objection has been received, =
that=20
>>> it will be reflected in the consensus call summary, and that the =
pending=20
>>> IESG appeal of the first WGLC's conclusion will be resolved before =
this=20
>>> document advances.
>>>=20
>>> Nadim Kobeissi
>>> Symbolic Software =E2=80=A2 https://symbolic.software =
<https://symbolic.software/>
>>>=20
>>> On 2/21/26 11:28 AM, Nadim Kobeissi wrote:
>>> > Hi Paul,
>>> >=20
>>> > You write:
>>> >=20
>>> >> 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.
>>> >=20
>>> > I just had a look at [2] and to my surprise, it didn=E2=80=99t =
seem to match=20
>>> > your description. What [2] seems to show was that the chairs =
decided=20
>>> > that there was no consensus. Quoting:
>>> >=20
>>> >  > The working group last call for pure ML-KEM has concluded, =
thanks to=20
>>> > those
>>> >  > that participated in the discussion. In summary, we do not have =
consensus
>>> >  > to publish the document as is.
>>> >  > [=E2=80=A6]
>>> >  > 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=20
>>> > 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=20
>>> > document.
>>> >=20
>>> > I am very confused. You say that [2] showed that it passed WGLC =
provided=20
>>> > that some clarifying text would be added. Absolutely none of this =
is=20
>>> > reflected in [2]. Instead, what [2] shows is an explicit admission =
of=20
>>> > the lack of any consensus to publish the document, and the =
document=20
>>> > being moved back to a =E2=80=9CWG Document=E2=80=9D state.
>>> >=20
>>> > Could you please clarify this rather large discrepancy between =
your=20
>>> > description of [2] and what [2] actually appears to say?
>>> >=20
>>> > Thank you,
>>> >=20
>>> > [2] =
https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/
>>> >=20
>>> > Nadim Kobeissi
>>> > Symbolic Software =E2=80=A2 https://symbolic.software =
<https://symbolic.software/>
>>> >=20
>>> >> On 20 Feb 2026, at 4:00=E2=80=AFPM, Paul Wouters=20
>>> >> <paul=3D40nohats.ca@dmarc.ietf.org =
<mailto:40nohats.ca@dmarc.ietf.org>> 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=3Ddraft-ietf-tls-=20
>>> >> mlkem-05&url2=3Ddraft-ietf-tls-mlkem-07&difftype=3D--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 -- tls@ietf.org <mailto:tls@ietf.org>
>>> >> To unsubscribe send an email to tls-leave@ietf.org =
<mailto:tls-leave@ietf.org>
>>> >=20
>>>=20
>>> _______________________________________________
>>> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org>
>>> To unsubscribe send an email to tls-leave@ietf.org =
<mailto:tls-leave@ietf.org>
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org>
>> To unsubscribe send an email to tls-leave@ietf.org =
<mailto:tls-leave@ietf.org>


--Apple-Mail=_0F908F55-5D41-4CA1-B8BB-34C8C68D6B9F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">Hi David,<br><br>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.<br><br>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 (<a =
href=3D"https://datatracker.ietf.org/doc/html/rfc7282#section-3">https://d=
atatracker.ietf.org/doc/html/rfc7282#section-3</a>) is explicit on =
this.<div><br>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.<br><br>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 (<a =
href=3D"https://datatracker.ietf.org/doc/html/rfc7282#section-6">https://d=
atatracker.ietf.org/doc/html/rfc7282#section-6</a>).<br><div>
<meta charset=3D"UTF-8"><br>Nadim Kobeissi<br>Symbolic Software =
=E2=80=A2&nbsp;https://symbolic.software<br>
</div>
<div><br><blockquote type=3D"cite"><div>On 21 Feb 2026, at 6:04=E2=80=AFPM=
, David Adrian &lt;davadria@umich.edu&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div dir=3D"ltr">&gt; I ask =
the<br>&gt; chairs to treat this as a blocking objection and to reflect =
it<br>&gt; accurately in any consensus call summary.<br><br>Rough =
consensus is not veto-based.</div><br><div class=3D"gmail_quote =
gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Feb =
21, 2026 at 11:57=E2=80=AFAM Deirdre Connolly &lt;<a =
href=3D"mailto:durumcrustulum@gmail.com">durumcrustulum@gmail.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div =
dir=3D"auto"></div><div>&gt; The Motivation section of -07 states that =
pure ML-KEM key establishment<br>is "necessary for migrating beyond =
hybrids and for users that want or<br>need post-quantum security without =
hybrids."</div><div dir=3D"auto"><br></div><div dir=3D"auto">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:&nbsp;</div><div dir=3D"auto"><br></div><div dir=3D"auto"><a =
href=3D"https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-07.html#secti=
on-1.1" =
target=3D"_blank">https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-07.=
html#section-1.1</a></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">"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."</div><div dir=3D"auto"><br><div =
class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" =
class=3D"gmail_attr">On Sat, Feb 21, 2026, 11:23=E2=80=AFAM Nadim =
Kobeissi &lt;nadim@symbolic.software&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">Hi everyone,<br>
<br>
Following the exchanges since my initial objection and after some <br>
additional appraisal of the situation, I am writing to set out a fuller =
<br>
objection to the publication of draft-ietf-tls-mlkem-07. I ask the <br>
chairs to treat this as a blocking objection and to reflect it <br>
accurately in any consensus call summary.<br>
<br>
I want to state my position plainly. I do not believe this document <br>
should be published. A pure post-quantum key establishment option for =
<br>
TLS 1.3 discards compositional security under component compromise -- a =
<br>
property deliberately designed into TLS 1.3 that has served the deployed =
<br>
Internet well -- and the document identifies no concrete benefit gained =
<br>
in exchange. The hybrid constructions already adopted by this working =
<br>
group provide post-quantum security while retaining that compositional =
<br>
guarantee. This document proposes to remove that guarantee, and I have =
<br>
yet to see a justification for doing so that withstands scrutiny.<br>
<br>
My background in formal verification of the TLS 1.3 key schedule -- <br>
including co-authoring verified models that contributed directly to TLS =
<br>
1.3's standardization (Bhargavan, Blanchet, Kobeissi, IEEE S&amp;P 2017, =
DOI <br>
10.1109/SP.2017.26) -- informs the specific concerns I set out =
below.<br>
<br>
---<br>
<br>
1. THE DOCUMENT'S MOTIVATION IS CIRCULAR<br>
<br>
The Motivation section of -07 states that pure ML-KEM key establishment =
<br>
is "necessary for migrating beyond hybrids and for users that want or =
<br>
need post-quantum security without hybrids."<br>
<br>
This is circular: it asserts that pure PQ key establishment is needed by =
<br>
those who want pure PQ key establishment. The section does not identify =
<br>
any deployment scenario in which a hybrid construction is technically =
<br>
infeasible, any security property gained by removing the classical <br>
component, or any basis for concluding that the time for "migrating <br>
beyond hybrids" has arrived.<br>
<br>
The compositional security argument for hybrid constructions is <br>
well-established: a hybrid key establishment scheme is secure if either =
<br>
component is secure. ML-KEM is relatively young as a standardized <br>
primitive; its mathematical hardness assumptions are less studied than =
<br>
those underlying established elliptic curve constructions. The world's =
<br>
Internet has been running TLS 1.3 with hybrid constructions for years, =
<br>
providing post-quantum security via ML-KEM while retaining higher <br>
assurance against classical attacks via ECC. Removing the classical <br>
component of this working arrangement discards a concrete security <br>
guarantee for no identified gain.<br>
<br>
One would expect that disrupting a functioning, well-analyzed status quo =
<br>
would require exceptional motivation. The document does not provide one, =
<br>
and none has been offered in discussion despite my repeated requests. I =
<br>
cannot support publication of a standard that removes a security <br>
property without justification.<br>
<br>
---<br>
<br>
2. THE FATT PROCESS HAS NOT BEEN COMPLETED<br>
<br>
The FATT charter (<a href=3D"https://github.com/tlswg/tls-fatt" =
rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://github.com/tlswg/tls-fatt</a>) states:<br>
<br>
&nbsp; &nbsp;"A proposal that modifies the TLS key schedule or the =
authentication <br>
process or any other part of the cryptographic protocol that has been =
<br>
formally modeled and analyzed in the past would likely result in asking =
<br>
the FATT."<br>
<br>
This document introduces pure ML-KEM as a NamedGroup, substituting the =
<br>
ML-KEM shared_secret into the TLS 1.3 key schedule in place of the <br>
(EC)DHE shared secret (Section 4.3, Figure 1). That substitution <br>
directly affects a component of the TLS 1.3 key schedule that has been =
<br>
formally modeled and analyzed, including in:<br>
<br>
&nbsp; &nbsp;- Bhargavan, Blanchet, Kobeissi, "Verified Models and =
Reference <br>
Implementations for the TLS 1.3 Standard Candidate," IEEE S&amp;P 2017, =
DOI <br>
10.1109/SP.2017.26.<br>
<br>
&nbsp; &nbsp;- Dowling, Fischlin, Gunther, Stebila, "A Cryptographic =
Analysis of <br>
the TLS 1.3 Handshake Protocol," Journal of Cryptology, 2021, DOI <br>
10.1007/s00145-021-09384-1 (cited in the draft as [DOWLING]).<br>
<br>
The prior analyses modeled the (EC)DHE input as a freshly generated <br>
ephemeral value. My own 2017 work explicitly modeled TLS 1.3 client key =
<br>
shares as ephemeral. As Muhammad Usama Sardar noted on this list on <br>
February 20, and as John Mattsson confirmed, this draft introduces a =
<br>
materially different assumption: Section 5.3 of -07 explicitly permits =
<br>
ML-KEM key share reuse.<br>
<br>
&nbsp;=46rom direct knowledge of the 2017 proof, I can confirm that its =
<br>
security arguments do not straightforwardly extend to a static key share =
<br>
case. The proof relies on the ephemerality of client key shares at a =
<br>
structural level. Substituting a potentially reused ML-KEM encapsulation =
<br>
key for a fresh ephemeral (EC)DHE value changes the adversarial model =
<br>
the proof operates under.<br>
<br>
Under the FATT charter, the chairs were expected to determine whether =
<br>
FATT review was warranted at adoption time. I have been unable to find a =
<br>
public record that FATT was engaged for this document: there is no FATT =
<br>
point person named in the FATT repository, and no FATT assessment <br>
appears in the shepherd write-up (which shows no shepherd assigned).<br>
<br>
I would appreciate it if the chairs could clarify on the record whether =
<br>
FATT triage was initiated and, if so, what the outcome was. This is a =
<br>
straightforward process question, and answering it would help the <br>
working group understand whether this document has received the formal =
<br>
analysis review that our own processes call for.<br>
<br>
---<br>
<br>
3. THE KEY REUSE LANGUAGE CONTAINS ERRORS AND CONFLICTS WITH NIST SP =
800-227<br>
<br>
Section 5.3 of -07 states:<br>
<br>
&nbsp; &nbsp;"While it is recommended that implementations avoid reuse =
of ML-KEM <br>
keypairs to ensure forward secrecy, implementations that do reuse MUST =
<br>
ensure that the number of reuses abides by bounds in [FIPS203] or <br>
subsequent security analyses of ML-KEM."<br>
<br>
This language has two concrete problems.<br>
<br>
First, FIPS 203 does not define a reuse bound. FIPS 203 specifies the =
<br>
ML-KEM algorithm; for usage guidance, it explicitly directs implementers =
<br>
to SP 800-227. SP 800-227 is normatively cited in -07 as <br>
[NIST-SP-800-227]. Section 5.3's invocation of "bounds in [FIPS203]" =
<br>
attributes guidance to a document that does not contain it. This is a =
<br>
factual error in normative text, verifiable by anyone who reads the <br>
cited document.<br>
<br>
Second, SP 800-227 (September 2025) states:<br>
<br>
&nbsp; &nbsp;"If an application uses an ephemeral key pair, the key pair =
shall be <br>
used for only one execution of key-establishment via a KEM and shall be =
<br>
destroyed as soon as possible after its use."<br>
<br>
SP 800-227 distinguishes sharply between ephemeral keys, which are <br>
single-use and must be destroyed, and static keys, which are reusable =
<br>
but subject to additional authentication and key management requirements =
<br>
including proof of possession. The draft simultaneously recommends <br>
against reuse and permits it, with a MUST qualifier pointing to a bound =
<br>
that does not exist in the cited document. The result is a normative =
<br>
contradiction that implementers cannot resolve by reading the documents =
<br>
cited.<br>
<br>
The security consequences of key reuse in deployed TLS go beyond the =
<br>
IND-CCA property of ML-KEM in isolation. IND-CCA is a primitive-level =
<br>
property; it does not guarantee forward secrecy, resistance to traffic =
<br>
analysis based on linkability of reused encapsulation keys, or <br>
compliance with SP 800-227's additional requirements for static-key <br>
deployments. The draft addresses none of these protocol-level =
concerns.<br>
<br>
John Mattsson raised this point on February 12 and proposed removing all =
<br>
key reuse text as the condition for his support. The changes in -07 <br>
addressed his concern only partially and did not correct the FIPS 203 =
<br>
citation.<br>
<br>
---<br>
<br>
4. THE FRAMING OF THIS SECOND WGLC DOES NOT ACCURATELY REFLECT THE FIRST =
<br>
WGLC'S CONCLUSION<br>
<br>
Paul Wouters's message of February 20, sent in his capacity as AD, <br>
describes the first WGLC as follows:<br>
<br>
&nbsp; &nbsp;"We already had a WGLC on this document [1] and the =
conclusion [2]<br>
&nbsp; &nbsp; was that it passed WGLC provided some clarifying text =
would be<br>
&nbsp; &nbsp; added that stated that for the general use case, hybrids =
were<br>
&nbsp; &nbsp; preferred."<br>
<br>
This description does not match the conclusion it cites. The conclusion =
<br>
of the first WGLC, as recorded by Joseph Salowey on December 8, 2025 in =
<br>
the very message Wouters cites as [2], reads:<br>
<br>
&nbsp; &nbsp;"The working group last call for pure ML-KEM has concluded, =
thanks<br>
&nbsp; &nbsp; to those that participated in the discussion. In summary, =
we do not<br>
&nbsp; &nbsp; have consensus to publish the document as is. [...] Given =
this, the<br>
&nbsp; &nbsp; chairs will move the document back to the 'WG Document' =
state and<br>
&nbsp; &nbsp; ask the author to work on resolving the issues brought up =
on the<br>
&nbsp; &nbsp; list including text to address concerns that there are =
reasons to<br>
&nbsp; &nbsp; prefer hybrid over the pure approach. The chairs will then =
redo a<br>
&nbsp; &nbsp; working group last call to see if there is rough consensus =
for<br>
&nbsp; &nbsp; publishing this document."<br>
<br>
[2]: <a =
href=3D"https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRc=
FxY/" rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCk=
eEcvJ_qtRcFxY/</a><br>
<br>
The recorded conclusion is an explicit finding of no consensus to <br>
publish, with the document returned to WG Document state. Anyone can =
<br>
read [2] and compare. Describing this outcome as the document having =
<br>
"passed WGLC" is not a paraphrase; it reverses the recorded finding. =
<br>
This matters because the framing of this second WGLC as a narrow <br>
confirmatory step depends on that characterization. If the first WGLC =
<br>
found no consensus -- as [2] explicitly records -- then this second WGLC =
<br>
is properly a fresh determination of rough consensus, not a check on =
<br>
whether added text satisfies conditional supporters.<br>
<br>
Per RFC 2418 Section 7.4, a working group last call determines rough =
<br>
consensus across the working group as a whole. The first WGLC generated =
<br>
substantive objections from multiple participants -- including D.J. <br>
Bernstein, Stephen Farrell, Rich Salz, Simon Josefsson, and myself -- =
<br>
that have not been resolved by the revisions in -07. The conclusion of =
<br>
the first WGLC is itself under active appeal at the IESG <br>
(<a href=3D"https://datatracker.ietf.org/group/iesg/appeals/artifact/230" =
rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://datatracker.ietf.org/group/iesg/appeals/artifact=
/230</a>). I would <br>
ask the chairs to clarify how the interaction between that pending <br>
appeal and this second WGLC is being handled.<br>
<br>
---<br>
<br>
5. SCOPE OF THIS OBJECTION<br>
<br>
I note the AD's guidance that this second WGLC is directed at assessing =
<br>
whether the revisions in -07 address concerns raised in the first WGLC. =
<br>
My response to that framing is twofold.<br>
<br>
First, several of the concerns I raise above are specific to the -07 =
<br>
text itself: the FIPS 203 citation error, the SP 800-227 conflict, and =
<br>
the absence of FATT review are all concerns that arise from -- or remain =
<br>
unaddressed by -- the current revision. These are squarely within scope =
<br>
of any reading of this WGLC's purpose.<br>
<br>
Second, the substantive objections from the first WGLC that were not =
<br>
resolved by -07 do not lapse because a second WGLC has been called. The =
<br>
revisions did not address the absence of a concrete motivation for <br>
removing the classical component, did not initiate FATT review, did not =
<br>
correct the FIPS 203 citation, and did not resolve the tension with SP =
<br>
800-227. These objections remain open.<br>
<br>
I ask the chairs to confirm that this objection has been received, that =
<br>
it will be reflected in the consensus call summary, and that the pending =
<br>
IESG appeal of the first WGLC's conclusion will be resolved before this =
<br>
document advances.<br>
<br>
Nadim Kobeissi<br>
Symbolic Software =E2=80=A2 <a href=3D"https://symbolic.software/" =
rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://symbolic.software</a><br>
<br>
On 2/21/26 11:28 AM, Nadim Kobeissi wrote:<br>
&gt; Hi Paul,<br>
&gt; <br>
&gt; You write:<br>
&gt; <br>
&gt;&gt; We already had a WGLC on this document [1] and the conclusion =
[2] was<br>
&gt;&gt; that it passed WGLC provided some clarifying text would be =
added that<br>
&gt;&gt; stated that for the general use case, hybrids were =
preferred.<br>
&gt; <br>
&gt; I just had a look at [2] and to my surprise, it didn=E2=80=99t seem =
to match <br>
&gt; your description. What [2] seems to show was that the chairs =
decided <br>
&gt; that there was no consensus. Quoting:<br>
&gt; <br>
&gt;&nbsp; &gt; The working group last call for pure ML-KEM has =
concluded, thanks to <br>
&gt; those<br>
&gt;&nbsp; &gt; that participated in the discussion. In summary, we do =
not have consensus<br>
&gt;&nbsp; &gt; to publish the document as is.<br>
&gt;&nbsp; &gt; [=E2=80=A6]<br>
&gt;&nbsp; &gt; Given this, the chairs will move the document back to =
the "WG Document"<br>
&gt;&nbsp; &gt; state and ask the author to work on resolving the issues =
brought up <br>
&gt; on the<br>
&gt;&nbsp; &gt; list including text to address concerns that there are =
reasons to prefer<br>
&gt;&nbsp; &gt; hybrid over the pure approach. The chairs will then redo =
a working group<br>
&gt;&nbsp; &gt; last call to see if there is rough consensus for =
publishing this <br>
&gt; document.<br>
&gt; <br>
&gt; I am very confused. You say that [2] showed that it passed WGLC =
provided <br>
&gt; that some clarifying text would be added. Absolutely none of this =
is <br>
&gt; reflected in [2]. Instead, what [2] shows is an explicit admission =
of <br>
&gt; the lack of any consensus to publish the document, and the document =
<br>
&gt; being moved back to a =E2=80=9CWG Document=E2=80=9D state.<br>
&gt; <br>
&gt; Could you please clarify this rather large discrepancy between your =
<br>
&gt; description of [2] and what [2] actually appears to say?<br>
&gt; <br>
&gt; Thank you,<br>
&gt; <br>
&gt; [2]&nbsp;<a =
href=3D"https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRc=
FxY/" rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCk=
eEcvJ_qtRcFxY/</a><br>
&gt; <br>
&gt; Nadim Kobeissi<br>
&gt; Symbolic Software =E2=80=A2&nbsp;<a =
href=3D"https://symbolic.software/" rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://symbolic.software</a><br>
&gt; <br>
&gt;&gt; On 20 Feb 2026, at 4:00=E2=80=AFPM, Paul Wouters <br>
&gt;&gt; &lt;paul=3D<a href=3D"mailto:40nohats.ca@dmarc.ietf.org" =
rel=3D"noreferrer" target=3D"_blank">40nohats.ca@dmarc.ietf.org</a>&gt; =
wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; [ AD hat on ]<br>
&gt;&gt;<br>
&gt;&gt; All,<br>
&gt;&gt;<br>
&gt;&gt; I want to remind people that the goal of this 2nd WGLC is to =
focus on<br>
&gt;&gt; the new text changed in responds to the conclusion of the 1st =
WGLC.<br>
&gt;&gt;<br>
&gt;&gt; We already had a WGLC on this document [1] and the conclusion =
[2] was<br>
&gt;&gt; that it passed WGLC provided some clarifying text would be =
added that<br>
&gt;&gt; stated that for the general use case, hybrids were preferred. =
This<br>
&gt;&gt; 2nd WGLC is about that topic.<br>
&gt;&gt;<br>
&gt;&gt; There is an appeal chain that got muddled by the inappropriate =
use of<br>
&gt;&gt; derivative clauses that is still in progress, but so far =
yielded the AD<br>
&gt;&gt; statement [3] that confirmed the WG Chairs view that the =
consensus call<br>
&gt;&gt; passed. There is an appeal with the IESG [4] on that decision, =
and this<br>
&gt;&gt; document will not be placed in the RFC Editor queue until that =
appeal has<br>
&gt;&gt; concluded, but will also not stop all processing while the =
appeal runs.<br>
&gt;&gt;<br>
&gt;&gt; This 2nd WGLC is meant to get those people who provisionally =
said "yes"<br>
&gt;&gt; to publication of this document pending some extra text, to =
review this<br>
&gt;&gt; text and let us know if that resolves the conditional part of =
their<br>
&gt;&gt; "yes" statement. The text changes to discuss can be seen =
at:<br>
&gt;&gt;<br>
&gt;&gt; <a =
href=3D"https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-tls-" =
rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-t=
ls-</a> <br>
&gt;&gt; =
mlkem-05&amp;url2=3Ddraft-ietf-tls-mlkem-07&amp;difftype=3D--html<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I understand this is a heated topic. I am also not hearing from =
people<br>
&gt;&gt; that they have changed their opinion on whether or not to =
publish this<br>
&gt;&gt; document at all. Confirming your views are fine, but again, =
that is not<br>
&gt;&gt; the goal of this 2nd WGLC. It would be helpful if, especially =
those<br>
&gt;&gt; people who wanted additional clarifying text, to give us =
feedback on<br>
&gt;&gt; this. And ideally, offer up suggestions that would address any =
still<br>
&gt;&gt; outstanding issues.<br>
&gt;&gt;<br>
&gt;&gt; Thanks,<br>
&gt;&gt;<br>
&gt;&gt; Paul<br>
&gt;&gt;<br>
&gt;&gt; [1] <a =
href=3D"https://mailarchive.ietf.org/arch/msg/tls/Pzdox1sDDG36q19PWDVPghsi=
yXA/" rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://mailarchive.ietf.org/arch/msg/tls/Pzdox1sDDG36q1=
9PWDVPghsiyXA/</a><br>
&gt;&gt; [2] <a =
href=3D"https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRc=
FxY/" rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCk=
eEcvJ_qtRcFxY/</a><br>
&gt;&gt; [3] <a =
href=3D"https://mailarchive.ietf.org/arch/msg/tls/dzPT8KQe4S-_pZROLUJMvS9p=
M0M/" rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://mailarchive.ietf.org/arch/msg/tls/dzPT8KQe4S-_pZ=
ROLUJMvS9pM0M/</a><br>
&gt;&gt; [4] <a =
href=3D"https://datatracker.ietf.org/group/iesg/appeals/artifact/230" =
rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://datatracker.ietf.org/group/iesg/appeals/artifact=
/230</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; TLS mailing list -- <a href=3D"mailto:tls@ietf.org" =
rel=3D"noreferrer" target=3D"_blank">tls@ietf.org</a><br>
&gt;&gt; To unsubscribe send an email to <a =
href=3D"mailto:tls-leave@ietf.org" rel=3D"noreferrer" =
target=3D"_blank">tls-leave@ietf.org</a><br>
&gt; <br>
<br>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:tls@ietf.org" rel=3D"noreferrer" =
target=3D"_blank">tls@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:tls-leave@ietf.org" =
rel=3D"noreferrer" target=3D"_blank">tls-leave@ietf.org</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:tls@ietf.org" =
target=3D"_blank">tls@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:tls-leave@ietf.org" =
target=3D"_blank">tls-leave@ietf.org</a><br>
</blockquote></div>
</div></blockquote></div><br></div></body></html>=

--Apple-Mail=_0F908F55-5D41-4CA1-B8BB-34C8C68D6B9F--