[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

["D. J. Bernstein" <[e-mail]>]

Paul Wouters writes:
> Responding as AD

Hmmm. I thought that a "person who disagrees with a Working Group
recommendation shall always first discuss the matter with the Working
Group's chair(s)", whereas AD involvement is only if "the disagreement
cannot be resolved in this way". This provides multiple levels of
opportunities to resolve disagreements.

So I posed a question to the chairs: specifically, asking how they came
to the conclusion that there was consensus here. I also explained why I
was asking. (Procedurally, I also shouldn't have to ask.)

Does the new AD interruption mean that the chairs are no longer obliged
to engage in discussion of their action? In other words, has the AD
single-handedly destroyed a mandated opportunity for resolution? If so,
what's the authorization for this under IETF procedures?

The situation was already a bit messy before this (for example, were the
chairs deterring input when they issued a consensus declaration before
the end of the call period?), but at this point it's very difficult to
figure out how the situation relates to how the IETF standardization
process is supposed to work.

I'm also not sure how this can be brought back to the proper procedures.
Withdrawing the AD message isn't going to magically restore independent
evaluation by the chairs.

> There is clearly consensus
> based on the 67 responses to the adoption call.
  [ ... ]
> The vast majority was in favour of adoption
  [ ... ]
> a few dissenting opinions

I have an easy question and a harder question.

The easy question, just to make completely sure that I'm not missing
something: You're saying that the numbers here, such as "67" and "a
few", were considered as part of your forming a conclusion that there's
consensus here?

(I assume the answer is simply "yes"---why else would the numbers have
been brought up?---but I'd just like to make sure.)

The harder question: For transparency, please explain how many different
people you're referring to in saying "67 responses" and "vast majority"
and "a few", and please provide details so that the rest of us can check
your tallies.

My impression from watching the list is that the actual ratio between
the numbers of objectors and supporters is vastly larger than the ratio
between "a few" and "67", for any reasonable understanding of "a few".

> > There were several people (including me) raising objections on
> > list to basic flaws in this draft
  [ ... ]
> Not being a hybrid KEM is not a "basic flaw".

The only reason that CECPQ2 didn't expose user data to pre-quantum
attackers is that it had the common sense to include an ECC layer.

> > (2) the failure to provide an engineering justification for this option
> This is your own made up condition.

No, it isn't: "Rather than bringing a fully-formed solution and looking
for a use, begin by articulating _what issue or gap needs to be
addressed_. ... In other words, _don’t put the cart before the horse_:
first convince the group that there's an important problem to solve."

These quotes aren't from something binding on the TLS WG---they're
quotes from a CFRG process document---but they're still doing a nice job
of pinpointing one of the basic flaws in the ML-KEM draft.

> > and (3) the lack of any principles that would justify saying no
> > to options selected by other governments if this option is allowed.
> This document does not set policy for other documents or governments,
> so this "reason" is out of scope for the IETF.

Non sequitur. Supporting endless options is a systemic security problem,
so the WG shouldn't take every option that's proposed---but then there
should be principles for the dividing line. This is entirely about what
the WG is endorsing, not about the level of WG power over anyone else.

> no raised technical issues

Can you please clarify what exactly you mean by "technical" here, why
this criterion factors into the question of whether there's consensus,
and why the issues raised (e.g., the security risks of non-hybrids)
don't qualify as "technical"? Thanks in advance.

---D. J. Bernstein