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

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:

    * https://cr.yp.to/papers.html#qrcsp found that 48% of the round-1
      submissions to NIST's post-quantum competition have been broken by
      now, including 25% of the submissions unbroken at the end of round
      1 and 36% of the submissions selected by NIST for round 2. Even if
      it's possible to argue that an older area of cryptography is well
      enough developed to justify rubber-stamping (I'm skeptical about
      that), treating newer areas the same way makes no sense.

    * Even for areas as traditional as cipher design or ECC, there are
      security failures arising from implementation issues (see, e.g.,
      https://cr.yp.to/papers/safecurves-20240809.pdf#chronology and
      https://eprint.iacr.org/2019/996), and NIST refuses to take
      responsibility for those failures (e.g.: "NIST is not aware of any
      vulnerabilities to attacks on these curves when they are
      implemented correctly and used as described in NIST standards and
      guidelines"). We can do better than that.

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

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.

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. If this
claim isn't going to be backed by evidence then it has to be withdrawn.

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

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

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

---D. J. Bernstein

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