Hello,
On 2/26/26 04:44, Nadim Kobeissi wrote:
Dear Stephen,
Thank you for your note. I appreciate your shared reservations
regarding the publication of this document.
I agree entirely with both you and Rich that a single participant
does not possess a unilateral veto, and that assessing consensus
requires judgement calls by the chairs. IETF procedures do not allow
one person to hold a document hostage based merely on contention or
preference.
However, there is a fundamental difference between a generic
complaint and a substantive, detailed technical objection. As
outlined in RFC 7282, the essence of rough consensus is that all
legitimate technical concerns must be addressed—not necessarily
accommodated, but technically resolved or refuted.
If a severe technical flaw is demonstrated, or if prerequisites—such
as FATT review—aren’t met, and the Working Group's only response is
to state that they "still want to move forward" without engaging
with the realities of the flaw, then the technical issue remains
unaddressed. Proceeding under such circumstances is not rough
consensus; it is the administrative dismissal of an unresolved
technical reality.
My objective is simply to ensure that the cryptographic standards we
produce are sound. I remain fully prepared to engage with any
rigorous technical refutation of the vulnerabilities I have
detailed. Until the substance of those concerns is actually met, my
objection stands on its technical merits.
I am in full agreement with Nadim and others on the list pushing back
against publication of this draft. I find the counter arguments, and the
motivations or rather the lack of motivations, to be unconvincing.
It is important to model and verify, and indeed to think about changes
very carefully. It is surprising that the FATT review isn't the starting
point for serious consideration.
It is prudent from a risk management perspective to use hybrid
constructions with an appropriate combiner. Even if an attack against
ECC were to be demonstrated tomorrow using a quantum computer, does
anyone expect every adversary to have the same capability and the same
datasets instantly? It seems unlikely, and various issues in
post-quantum implementations seem to be much more likely to arrive again
and again, and sooner.
Those who want post-quantum protections should not be less secure for
hedging security concerns with the use of hybrid constructions. TLS
enjoyers and myriad unknowing users should not need to take special
steps to ensure they aren't accidentally using the less conservative,
riskier strategy. The longer cryptographers and security researchers
have to discover and fix various issues while hedging safely, the
better. Those who only want post-quantum security are always free to
publish their ECC secret keys as a sign of their confidence.
The compositional security properties mentioned by Nadim and others are
table stakes for deploying post-quantum cryptography. The math, the
various implementation details, and the deployment contexts that are
secure today using ECC today should remain at least as secure today and
tomorrow. Targeted and mass surveillance collection of data is part of a
larger pervasive attack strategy that is practiced by many adversaries
more or less continuously. Practical cryptanalysis of data collected
through such surveillance or other means of data collection is by no
means limited to a hypothetical quantum computer.
In the tremendous volume of email on list there has not been a
compelling technical argument against hybrids to the contrary presented.
I oppose publication of the draft and furthermore think that for TLS, we
should see hybrids listed as RECOMMENDED (i.e.: recommend=Y). In an
ideal world with prudent risk management, hybrids would be listed as a
MUST, and PQ only should be a MUST NOT[1].
With regard to Kyber/ML-KEM, NIST dismissed or did not address important
technical concerns, and they ignored other related concerns of
significance that were raised in the public comment period[0]. The
effect of that overall disappointment has been immensely harmful to
NIST's international standing, which was already lying down, to
paraphrase a great American poet.
Given this experience with NIST, I oppose publication of this draft for
another reason: it will further damage IETF's standing as an independent
and fair forum that seeks to protect users and the internet without
advantaging any Adversary.
Probably others have already received emails about this very WGLC where
they have been asked if this will be an example of Project BULLRUN's
latest victory. Exclusionary hostility and anti-competitive concerns
aside, I am cautiously optimistic that it is at least possible that the
WG and indeed the IETF won't be such an example (again).
Kind regards and happy hacking,
Jacob Appelbaum
[0]
https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf
[1] Pure PQ in TLS, not even once!
Nadim Kobeissi Symbolic Software • https://symbolic.software
On 25 Feb 2026, at 11:38 PM, Stephen Farrell
<[email protected]> wrote:
On 25/02/2026 21:50, Salz, Rich wrote: You misunderstand what
“addressed” means here. A perfectly reasonable response is “the
issue has been discussed by the WG and they still want to move
forward.” As another recent example, the LAMPS WG went ahead
even though one participant (repeatedly:) raised patent
concerns.
Despite me not wanting to see this document published, Rich is
correct here. There are always judgement calls required and one
participant being convinced there's a fatal flaw in something is
not sufficient in itself to block that thing. If a participant
convinces others of the fatality of the flaw, that may be
different, but if something is generally contentious, (as in this
case), a claim of a fatal flaw by itself blocks nothing.
Cheers, S. <OpenPGP_signature.asc>
_______________________________________________ TLS mailing list --
[email protected] To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
