Daniel,
Hi! Thanks for the question.
tl;dr: We are trying to gather information about what to do WRT running WG
adoption calls; no more, no less.
The part of the procedure we are following is, what I would refer to as, the
consensus process. We, as the chairs, need to determine whether there is
consensus to do a thing or not. In this case, that thing is to run one or more
adoption calls.
We provided all that background information because some might not remember all
of the context so it provides context from them as well as something for those
who do remember to check our recollection. The danger with that, obviously, is
that our messages get much longer and prone to misinterpretation. Sorry if we
added any confusion by providing that detail. Another point we can offer is
that no matter how hard we try to get an email just right, there is always
somebody who thinks we wrote it wrong or had some better of writing it; we like
to joke that when we mess up 400 of our closest friends let us know.
If you are wondering why now, it is because until recently there had been few
requests to adopt any of those drafts. In fact, the WG has been shunning cipher
suites I-Ds for years; the notable exception is draft-ietf-tls-tls13-pkcs1, and
that only got adopted because the WG decided that putting something back into
TLS 1.3 that we took out necessitated adoption. We started thinking about and
working on the message that started this thread right after IETF 121, but
unfortunately it takes time for us to get our acts in gear.
Part of chairing is gathering input, i.e., trying to read the room. Asking if
people are generally okay with adoption calls is one of the tools we can use.
And frankly by asking it this way, it is also a signal that maybe we should
take a bit of a break as we are rapidly entering the Holiday season. Not super
efficient I will grant you, but it is pretty darn practical.
As far as people responding one way and others another, all I can say is people
are going to respond how they are going to respond.
As far as the omitting one of I-Ds (draft-tls-westerbaan-mldsa) in the I-Ds we
referred to, we can only offer: mea culpa. Luckily though, people are going to
respond how they are going to respond and our mistake was corrected.
Hopefully, this response answers your questions.
Cheers,
Joe and Sean
NOTE: When we do run adoption calls we ask whether there are objections and
why. If you object to an I-D being adopted, that is a time to say why.
> On Dec 17, 2024, at 21:29, D. J. Bernstein <d...@cr.yp.to> wrote:
>
> 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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
