Muhammad Usama Sardar writes:
> D. J. Bernstein wrote:
> > 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.
> If you believe Nadim's formal analysis in ProVerif is not a significant
> development
My comments have nothing to do with the judgment call of what qualifies
as "significant".
Instead my comments were about whether the concerns raised in the last
WGLC were addressed. This is explicit in the context that you omitted
("False. For example, none of that has addressed the following objection
... This isn't an isolated example of an unaddressed objection" etc.). I
carefully distinguished the occasional objections that _were_ addressed
from the much larger number of objections that weren't.
> John is surely not the only one. Key reuse was one of my *major*
> concerns.
Sorry if I missed some previous text (but then why don't you provide a
quote?). Anyway, I really don't see how this is relevant.
I said before that the changes have addressed objections from "a few
people". I went through the details, naming you and John. But there were
_many more_ people objecting than that: 22 in total. I cited
https://blog.cr.yp.to/20260405-votes.html
for names, quotes, and links. I said that the majority of these 22
"stated objections centered on solo PQ incurring unnecessary security
risks compared to hybrids".
That's exactly what the chairs have been ignoring. They claim that "the
concerns raised in the last WGLC" have been addressed; that's simply not
true. Concerns stated by _a few_ people have been addressed but more
fundamental concerns stated by many more people have not.
> > > - 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.
> Respectfully, I believe that's wrong too.
Objections 4, 5, 7, 8, 10, 12, 13, 15, 16, 17, 18, 19, 20, and 22 quoted
in https://blog.cr.yp.to/20260405-votes.html are regarding the security
risks of draft-ietf-tls-mlkem compared to draft-ietf-tls-ecdhe-mlkem.
Plus me, obviously, so 15 people.
I'm providing these details to allow double-checking, but the exact
number doesn't matter for what I'm saying. I'm objecting that this WGLC
is founded upon false pretenses, the fiction that "the concerns raised
in the last WGLC" have been addressed, and is thus imposing improper
burdens upon people objecting.
Note that the chairs didn't say "some concerns", which would have been
formally true---but deceptive and in any case inadequate. (The reader
understands "last call" to mean that all previous objections were
already addressed.) Instead the chairs said "the concerns", which would
have been adequate for WGLC if it were true, but it's simply not true.
The fact that some of the previous objectors have already spoken up
_again_ to object illustrates that the objections were _not_ addressed.
This also illustrates the improper burdens. Nobody should have to raise
an objection twice. Instead of ignoring objections, the chairs should be
enforcing the requirement from RFC 2418 for disagreements to be
"resolved by a process of open review and discussion".
> AFAIU, most of the 25 objecters
> from the last WGLC now seem to be satisfied with the formal proof. I've seen
> only 4-5 of those still objecting. All other objecters so far are new
Your numbers are not backed by URLs or other evidence; I have no idea
why you think excluding "new" objectors is justified; this WGLC started
only 4 days ago, so it makes no sense to compare the numbers to the
results of a two-week WGLC; and I don't know how you think any of this
contradicts what I've written.
> I haven't seen any new arguments yet
The chairs wrote "Please refrain from further discussion on this topic".
That violates RFC 2418, but I'd think that many people who know this
will also be terrified of disobeying the chairs.
I did post something about https://cr.yp.to/papers/mldsa-20260601.pdf,
and about flaws in various new arguments for solo PQ.
Anyway, I don't know why you think the number of new arguments is
important. The arguments _already_ raised include 15 people who objected
to draft-ietf-tls-mlkem incurring unnecessary security risks compared to
draft-ietf-tls-ecdhe-mlkem.
> Moreover, many more people are now in
> support because of formal assurance.
I don't see how claims about the rationales for support are relevant to
what I've written about the chairs ignoring objections.
> The formal analysis showed both proponents and opponents were correct:
> * proponents in the sense that there is no security issue in the
> integration of ML-KEM in TLS
> * opponents in the sense that hybrids enjoy two-factor security
> properties and it is not only "proponents of hybrids" as the draft
> previously said, rather a scientifically proven fact.
All of the formal analyses of TLS so far skip important cryptographic
details, as I wrote in an earlier message, and thus miss a wide range of
attacks in the cryptographic literature, including many attacks cheap
enough for academic demos (e.g., https://sweet32.info), including many
PQ spec attacks (see generally https://cr.yp.to/papers.html#qrcsp) and
PQ software attacks (see, e.g., https://cr.yp.to/papers.html#kyberslash
and my new paper https://cr.yp.to/papers.html#mldsa).
Sometimes formal analyses catch problems. Given how much advertising
there was for the TLS 1.3 formal analysis, I was surprised to see how
some people responded to your requests to extend the analysis to KEMs.
But it's also easy to see from my chart in
https://blog.cr.yp.to/20260221-structure.html
(which includes links for verification) that a very large part of the
debate about solo ML-KEM is about issues beyond these formal analyses.
---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]
