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

[Paul Wouters <[e-mail]>]

On Wed, 16 Apr 2025, D. J. Bernstein wrote:

>  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.

If you look at an individual issue, then yes that is the regular
procedure. In your case, you seem to object to most WG decisions not in
your favour and question motivations of every decision and individual
involved in the decision chain. And frankly, it is already a denial of
service on the time of many volunteers within IETF, from WG chair to
the IESG.

To make it more clear and blunt, you calling into question this consensus
call of the WG chair is abusive and follows a repetitive pattern.
Nevertheless, for now this is your right, and we will walk through
the process.

>  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.)

Unfortunately, it looks like you are attempting to bait the chairs to
say they took inventory of the public emails and then throw in some
quotes about "you counted votes but IETF does not vote". My previous
email explained the obvious way the consensus was validly called. This
can be independently verified by anyone reading the email thread. The
fact that you are the only one questioning the consensus should be an
indication that your reasoning to doubt the consensus call might in fact
be erroneous.

>  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?

Dan, there comes a point where you will be prevented from further playing
these games. There are processes for that, that we really try hard to
avoid invoking. But as some point you leave us no choice.

This consensus call was _very_ obvious based on the email thread content,
again as I explained in my previous message. Whether the TLS Chairs
feel obliged to send you another message repeating the obvious is pretty
irrelavant other than taking up valuable time an energy of an entire WG
in playing a process game with you. Unless you are invoking an appeal
as per RFC 2026 Section 6.5.1 against the WG chairs decision that there
is consensus to adopt, they are under no obligation to answer you with
something they deem obvious. It is completely up to the chairs to make
their own decision here. Either way is acceptable in our process.

Once you send an RFC 2026 Section 6.5.1 appeal to them, according to
process they MUST respond to you. Presumbly once denied - if they are
not convinced by your arguments in your appeal - you can then send the
same text, with your usual disclaimer that in your opinion I need to
recuse myself, to me as TLS AD, and I will reply with "based on the
public discussion on the list, with the overwhelming majority being in
favour of adoption as long as the MTI/RECOMMENDED values would remain
"NO", with a few dissenting views of wanting to block all pure PQ in
all IETF protocols in favour of IETF only adopting hybrids, and with
no technical flaws pointed out in the specified protocol by anyone,
considering there are already a number of interoperable implementations
based on early code points, it is unmistakenly clear that the TLS Chairs
correctly called consensus on adoption of this document. Your appeal
is denied". Upon which you can file another appeal of my decision to
the IESG.

>  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?),

According to https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/history/
a two week adoption call went out on 2025-04-01 and the document status
was set to adopted on 2025-04-15. (datatracker provides no finer
granularity in its History tab) This matches the email dates on the
respective TLS email messages:

Start: 01 April 2025 12:58 UTC 
https://mailarchive.ietf.org/arch/msg/tls/PpVAwrBTuRb5pR6D0C1ipdQuvYc/

End: 15 April 2025 17:27 UTC 
https://mailarchive.ietf.org/arch/msg/tls/_AWy51BSgX1ipv0hfnAzLrDrTYI/

You are correct that Sean did say in the announcement that the call
would close at "2359 UTC on 15 April 2025", so indeed technically
speaking it was called 6 hours too early. However, usually adoption and
last calls are send out for a period of weeks and usually chairs send
out a message on which day a call ends without further hourly
granularity. Regardless, it was obvious that at the time no active
discussion about fundamental issues was taking place and calling this
adoption ended on the last day of the adoption call period caused no
stiffling of discussion. I am further confident that if any real
discussion had taken place, the chairs would have not called it and
would have extended the adoption call to give any active discussions
more time to settle. I also see no valid reason to extend the adoption
call by 6 hours.

>  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.

As in all cases regarding WG level document disagreements on WG chairs
decisions, you should follow RFC 2026 Section 6.5.1 as indicated to you
a number of times over the last few months. If you feel the WG Chairs or
AD is giving you conflicting information, you should stick to RFC 2026.

>  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.

I disagree we are deviating from existing procedures. You just had a
glimpse of the obvious continuation of the process, were you to invoke
process from RFC 2026 Section 6.5.1. You have not yet invoked that
process as far as I know. You have until June 15 17:27 UTC to appeal.

>>  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?

The use of the number 67 refered to the number and content of all messages
in the adoption call email thread on the TLS list - which is the entire
information base upon which the consensus call by the chairs took place,
and also constitutes the information on why I believe the chairs reached
the right conclusion.

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

I am not answering your question as a boolean. See my previous paragraph.

>  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.

The only way to win is not to play. I am not playing your game of
forcing me to use numbers only to have you call out "counting is voting".

The content of 67 messages was produced by the WG. Based on the entirety
of the content of those messages, consensus was determined.

>  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".

I never put "a few" against "67". That is a misleading construct you
devised, not me, nor the chairs.

>>>  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.

This is not new information. The WG heard your statement and people took it
into consideration when they expressed their opinion on whether to adopt
the document.

>>>  (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.

If you had expressed these views at the start of the adoption call,
people could have taken this into account. Some of the people that
participated on the adoption call were undoubtedly already aware of
these quotes.

Regardless, "providing an engineering justification" is not something
that one individual (you) can add to the TLS charter in an adhoc matter.

>>>  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.

This is not about "endless options". This is about pure ML-KEM. It is
clear your view on pure ML-KEM is not universally agreed upon.

>>  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.

I meant a concrete issue or flaw. Not a hypothetical one. Nor the number
of airbags deemed not enough or too much in your hypothetical car with
seatbelts.

Paul