[saag] Re: [Ext] Re: draft-paulwh-crypto-components-02

On Tue, Feb 18, 2025 at 8:11 PM D. J. Bernstein <[email protected]> wrote:

> Here are some reasons that it's not a good idea to give NIST a free pass
> into IETF rubber-stamping while forcing other cryptography to compete
> for a "non-NIST" slot:
>

I didn't say there is only a NIST and non-NIST slot. I said it looked like
that is what
happened in the recent past. You are extrapolating.

It is also not a free pass, nor rubber stamping. For example look at the
interplay of NIST
specifications and IETF feedback, like with the Kyber SEED vs expanded key.

As another example, the IETF seems to prefer hybrids over pure PQ
algorithms that NIST
prefers, and is ensuring hybrids will be available for our protocols.

The NIST competitions are also the largest publicly held cryptographic
exercise where
the cryptographic community submits proposals and evaluates others.
Ignoring these
events is like evaluating the US art scene but ignoring Burning Man. Love
it or hate it,
it is going to play a part.

I also keep finding it strange that you object to NIST algorithms while you
submitted one yourself.
If you truly believe that NIST (via NSA directives) is malicious, and it
would have picked your candidate
algorithm, would you have said that therefor this "NSA condoned algorithm"
should not be trusted nor
standardized at IETF? It seems you are cherry-picking facts to support your
case.

There is a real market driven demand for (US) vendors to implement pure
NIST algorithms,
whether we (you, me or the entire IETF) likes it or not. And that's okay,
because we can give
out many code points while trying to keep the recommended or mandatory
algorithm list small.
You can find emails of me stating we should make all PQ algorithms MAY /
RECOMMENDED N at
this point and only decide on MUST / MTI / RECOMMENDED Y sometime in the
future.

This does not sound to me like "free pass" or "rubber stamping".
(If I would write in your style, this is where I would write "please
retract your statement")

    * https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/
>       says the following: "IETF activities are conducted with extreme
>       transparency, in public forums. Decision-making requires achieving
>       broad consensus via these public processes." This would be
>       violated by any deference to NIST's non-transparent procedures.
>

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. I do not know of any. I do know an example of where you are the
only
individual with an view squarely outside of IETF consensus, the "banning"
of non-hybrid
PQ algorithms argued via "anti-competition laws".

We've seen multiple rounds of AD proposals for controversial new
> policies of NIST deference. I don't see how any of these proposals can
> survive a technological evaluation---and I'm sure none of them can
> survive a transparency evaluation.
>

[ For transparency to the readers, I am assuming the drafts implied here are
  draft-pwouters-crypto-current-practices and its successor
draft-paulwh-crypto-components ]

The proposals were written as drafts, submitted for discussion, discussed
at face
to face meetings, leading to revised drafts and even an entire rewrite
based on
community feedback. If you believe the current draft has an technological
error,
please share that with us. I would be surprised as these are not technical
documents.
As for transparency, what do you think is being hidden by discussing the
entire content
of the draft with the IETF community, through the IETF process that
requires IETF consensus
to move forward?

Are we being shown a document saying "Here's a policy proposal; here
> are advantages and disadvantages of this proposal; please comment"? No.
> Instead we're being told that this is how things already work.


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.
This is something most Security ADs do not want to do, but because of the
nature of how some
algorithms have gone through the IETF in the past, proponents approaching
us will cherry-pick one that
has the process that they would like us to copy "to be fair". This document
is meant to help us give the
same answer to anyone who approaches us, using guidance that is public. It
is in fact meant to make the
whole process more transparent.


> If this claim isn't going to be backed by evidence then it has to be
> withdrawn.
>

The "evidence" is the many different processes used to publish
cryptographic algorithm RFCs  over the years.
(Note that it is unclear what "this claim" is referring to)

> > > > > The recent past (eg non-pq) shows a narrowing of algorithms to
> mostly
> > > > > > be 1 NIST and 1 non-NIST algorithm.
> > > > > Shouldn't this sort of claim be backed by a verifiable list of
> examples
> > > > > and counterexamples?
> > > > > When a draft claims to describe "the history of how cryptographic
> > > > > components have been documented and referenced in the IETF,
> particularly
> > > > > in RFCs", shouldn't the draft already have this list?
> > > > The previous document did so and most people thought it was a
> distraction.
> > > Which previous document supposedly had this list?
> >
> https://datatracker.ietf.org/doc/html/draft-pwouters-crypto-current-practices-00
>
> I don't see where that document's fragmentary notes on the history (one
> sentence giving just 7 examples of RFCs specifying primitives, and then
> occasional mentions of higher layers) address the claim of a supposed
> "narrowing of algorithms to mostly be 1 NIST and 1 non-NIST algorithm".
> That document doesn't even mention NIST.
>

This argumentation seems a repeat of your battle with a WG Chair where you
seem to believe
that every statement someone makes (even outside IETF)  needs to be settled
as if in a lawsuit.
I described what I saw was a trend. You are welcome to disagree. You are
not welcome to
request my retraction of my belief.

> read the archive and meeting minutes.
>
> I've tracked SAAG activity and am unable to figure out the justification
> for any of the claims at hand.
>

It is okay for you to believe that I have no justification for my
statement. 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. I understand you feel different, and that's
fine.

> > Please get into the habit of providing URLs to back up your claims,
> > > rather than putting extra load on readers.
> > Please stop the habit of your unlimited email denial of service
> > demanding other people act as your secretary or legal clerk.
>
> This is an inappropriate response. Something is seriously wrong when an
> AD making questionable claims about the history isn't providing URLs to
> justify those claims.
>

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. I have spend an
exorbitant
amount of time dealing with your emails spread over various WGs, both as
participant
and as Area Director. Your demands to not only me, but to many other
individuals that
do not agree with you, are unreasonable infinite demands on their time.
When people stop
responding to you, you complain. When people start responding offlist
because they
want to avoid another email war with you, you claim lack of transparency.
Your own
behaviour is damaging your own causes.

While you provide lots of (selective) URLS to re-iterate your statements,
sadly you keep
doing so even after various people tell you that you are wrong or in the
rough of consensus.
For example, you will want to respond to this by saying I need to provide
evidence for this
claim, and I would then have to go through the list archives of lamps, ssh,
saag, tls, cfrg,
antitrust-policy, etc to pick these up. Ironically, this is a hard job
because many of your emails
are cut and paste of the same (selective) URL materials, so scanning all
your emails becomes
tedious and error prone and quickly leads to diminishing returns. I already
have a spreadsheet
of all your emails to one WG, and I would really prefer spending my time on
other things.

Some of my time is currently better spend on the extra high page load count
of the IESG
Telechats just before the March AD handover IETF meeting, or with
additional meetings to help
BoF proponents present their case at the next IETF.

However, if you wish to discuss specific text written in any of my drafts,
please continue to do so.
The most economic way is to point out the current text, and provide
proposed new text or a succinct
description of why the text should be removed instead of modified. Then
others can chime in and
we can see about the consensus of your proposals and move on to other
business.

Thanks in advance,

Paul

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