Can the WG chairs please clarify which procedure from RFC 2026 (or from
RFCs updating RFC 2026) is being followed here?
I have three reasons for asking for clarification. First: The question
in the message that began the thread can easily be read in two ways, and
the replies are split in the question they're answering. Specifically:
* The message asks an adopt-or-not question in the subject line, but
it then says that the chairs _aren't_ asking this question yet
("not actually do the calls"), and it instead asks a call-or-not
question ("Is the WG consensus to run four separate adoption calls
for the individual I-Ds").
* Some of the replies are answering the adopt-or-not question, at
least for some drafts; other replies focus on the call-or-not
question. For example, "I suggest to call for adoption on
[ecdhe-mlkem, mldsa, composite-mldsa, slhdsa]. Personally, I don't
think all of those should be adopted, but I will share that when
there is an adoption calls" is distinguishing the questions and
explicitly not answering the adopt-or-not question. As another
example, "I only support an adoption call for [ecdhe-mlkem]" is
focusing on the call question; it implies opposition to current
adoption for the other drafts, but doesn't necessarily imply
support for adopting ecdhe-mlkem.
The way that the starting message mushed these questions together
strikes me as a recipe for confusion, on top of the confusion caused by
trying to handle four documents in a single thread. (Oh, oops, five. No,
wait, seven.) I'm one of the people who would like to see both KEMs and
signatures moving ahead, but I'd still like to see separate threads for
(1) KEM documents, (2) signature documents, and (3) questions about the
KEM-signature overlap area (most importantly the need for hybrids). Each
procedure that's official enough to be labeled as a chair action should
be in its own clearly labeled thread, to simplify tracking of which
comments are on which action.
Second reason for asking for clarification: It's inefficient to stretch
WG decisions into many formal stages, such as "have an adoption call or
not?" and then "adopt or not?" and then "RFC or not?". Realistically,
this inefficiency ends up encouraging votes ("+1" etc.), which is not
how IETF is supposed to work. If there isn't clear authorization for the
current procedure, then the procedure shouldn't be happening at all.
Evaluating this requires clarity regarding what procedure is happening.
Decision to adopt as a preliminary procedure before decision to issue an
RFC is allowed (and I would say encouraged) in BCP 78 and BCP 79, which
update RFC 2026. I don't see an IETF decide-to-call-to-adopt procedure.
Third: I don't understand why the chairs have started a meta-discussion
instead of simply calling for adoption of ecdhe-mlkem (and skipping the
other eleven TLS PQ drafts). Previous WG discussions already showed
controversy regarding
(1) whether to do anything with PQ signatures now and
(2) whether to do anything with non-hybrid PQ now.
The only draft at hand that avoids these controversies is ecdhe-mlkem,
and there have already been various participants requesting a prompt
move forward with ecdhe-mlkem.
Content-wise, I'd hope that more discussion can settle things in favor
of #1 and against #2, but for now I'd expect the WG chairs to be
responding to any request to call for adoption of #1 or #2 by saying
that there are unresolved objections. So I'm puzzled to see the WG
chairs issuing a call-or-not question regarding those. Meanwhile I'm
puzzled to see the WG chairs delaying a call for adoption regarding
ecdhe-mlkem.
Clarifying which RFC 2026 procedure the chairs are using would,
presumably, also shed light on the criteria being used.
Maybe I should reiterate that my security concerns and patent concerns
regarding Kyber are _not_ a reason to delay deployment of post-quantum
crypto---delay is creating its own security problems. Instead we should
be
(A) upgrading from ECC to ECC+PQ---so that our efforts to stop
quantum attacks don't make the situation worse in case of
further PQ breaks;
(B) within the PQ part, providing alternatives that are outside the
Kyber patent minefield; and
(C) within the PQ part, providing alternatives that are less likely
to fail in the first place.
ecdhe-mlkem already follows A. Providing B would bring the document into
compliance with BCP 79's "no mandatory-to-implement security technology
can be specified in an IETF specification unless it has no known IPR
claims against it or a royalty-free license is available to implementers
of the specification". C can be handled in a separate document. So these
aren't arguments against adopting ecdhe-mlkem.
---D. J. Bernstein
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
