[saag] IETF process discussion, was Re: Re: [Ext] Re : draft-paulwh-crypto-components-02

On Wed, Feb 19, 2025 at 10:28 AM D. J. Bernstein <[email protected]> wrote:

Note I am only responding to those parts that could be seen as requiring an
AD response.
On all other matters, we simply disagree and further discussion has proven
futile in the past.

I would like to know what the AD basis is for claiming that "The recent
> past (eg non-pq) shows a narrowing of algorithms to mostly be 1 NIST and
> 1 non-NIST algorithm".


This request requires no statement from me as an AD. Mentioning a perceived
trend is not an AD
activity, nor is it an (appealable) action.

What IETF should actually be doing is eliminating the non-hybrid
> proposals on safety grounds.


You should write this up in a draft and present it for discussion on the
saag list of a face to face meeting.
However note that most cryptographic registries have a policy of
Specification Required, so you would
need to update a lot of registries, probably in multiple drafts, one for
each respective WG. If you have a
draft and had some discussion on saag and would like a speaking slot at
IETF-123 or later, please let the
SEC ADs know so we can facilitate this.

> If you believe the decision making process has not been following the
> > broad consensus via public process, please file an appeal for each
> > specific instance you found.
>
> Wait, what? Before WG decisions have been made, isn't the WG the right
> venue for discussions? Are appeals even _allowed_ at that point?
>

Appeals are allowed for every "decision" made. If you believe that no
decisions have been made yet that
can be appealed, you should have no facts (aka decisions) that would have
been made "non-transparently".
For example. your belief that BCP188 prohibits supporting non-hybrid
algorithms currently seems to be an
"in the rough of rough consensus" viewpoint, and you could appeal a
decision that adopted a non-hybrid algorithm.
Some are also currently in adoption calls (eg for IKEv2), so it would be
good to state your views in those WGs
as well that you are against adoption.


> As for "the current draft": The ADs should be clearly spelling out the
> details of their controversial proposals to limit crypto RFCs, and the
> rationale for those proposals, before asking for comments on that text.
>

Again, please cite the current text that you object to, and not use your
personal interpretation
of the entire document as a basis for arguing about content.

Of course, you are allowed to just object to the entire document without
citing specific text,
and we will take that into consideration when determining IETF rough
consensus on the document.

It seems that the objections to previous versions of the proposals
> haven't led to the ADs giving up on the proposals


Correct, we are addressing the specific objections in an improved document.

, and also haven't led to better rationales for the proposals


Your view of this has been noted.

> One of the reasons I wanted to get such a draft out that I can point
> > to, is precisely because Security ADs are regularly approached (in
> > private) with requests to AD sponsor some crypto algorithm.
>
> Wait, _private_ requests? Really? How often is "regularly"? Aren't you
> required to reject private requests?
>

What do you base that on? Anyone can approach an AD and request them to
sponsor an
individual draft. There is no mandatory disclosure for contacting an AD.
Anyone can approach
an AD and request help on how and where they could move their draft
forward. And an AD
may AD sponsor any document but it still needs IETF consensus, which is
reached via an IETF
Last Call and IESG approval. For example, this happened for ntruprime for
SSH.

Additionally, you can email ADs privately or attend their "office hours" at
a physical meeting,
if you have a concern you wish to raise in private, for example abusive
behaviour on a WG list.

More to the point, how is this claim about private requests for AD
> sponsorship supposed to justify broad limits on all IETF activities in
> cryptography?
>

I do not believe your construct is a valid representation of facts.

> I still believe my very generic statement is true based on my 30 years
> > experience in the field and 20 years of experience at IETF.
>
> An AD claiming that "The recent past (eg non-pq) shows a narrowing of
> algorithms to mostly be 1 NIST and 1 non-NIST algorithm" should be able
> to provide evidence justifying this description.
>

As I explained before, your method of engagement yields an infinite amount
of
emails as you only disagree via a question. There is no gain in answering as
your disagreement will just attempt to send me even more work. You will just
have to live with the fact that we disagree and that we disagree on the
facts
involved.

> What is seriously wrong is your insistence that we must keep writing
> > more emails back and forth as long as you don't agree with the person.
>
> The issue here isn't agreement. The issue is an AD making claims without
> providing evidence for those claims.
>

If I state I think a trend is visible in algorithm selection in the market,
I do not need
to provide evidence. Furthermore, I provided my indicators and you just
disagreed
with them. Which is fine but does not give you a license to keep requesting
more
work from me. If you don't think the majority of TLS and IPsec use either
AES-GCM
or POLYCHACHA, or that these protools do not matter in whatever viewpoint
you
have of the world, that is fine. You know what my feeling for the trend is
based on.
You may state your disagreement for the record and that will be one of the
inputs
to the rough consensus evaluation. There is no obligation for me to present
you with
more and more data until you are satisfied.

I hope this clarifies some of the IETF processes to you.

Paul

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]