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

Paul Wouters writes:
> 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.

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". I've also pointed out reasons that this is not a
good policy (which is a different question from whether it's current
practice). I don't see where any of this is "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.

Let me see if I understand. You're saying that the ongoing LAMPS WG
discussion of the secret-key format for Kyber shows that IETF isn't
rubber-stamping NIST's selection of Kyber?

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

As far as I know, NIST has not stated a preference either way regarding
hybrids. Do you have a URL supporting your claim to the contrary?

As for current IETF activity, "available" has an important ambiguity. If
IETF has specifications of hybrid _and_ non-hybrid options, and NSA
spends money seeding the ecosystem with implementations that break the
hybrid options, and the users end up being forced to use non-hybrid
options for interoperability, then does the mere fact that there's a
spec mean that hybrids are "available"?

Even with a wimpy "yes" interpretation, I'm baffled by the claim that
IETF is "ensuring" this level of availability. As far as I know, no WG
has reached a decision of which post-quantum options to support.

What IETF should actually be doing is eliminating the non-hybrid
proposals on safety grounds. As an analogy, passengers in airplane seats
are required to wear seatbelts, to reduce damage in common cases of
turbulence and in less common cases of something worse.

> The NIST competitions are also the largest publicly held cryptographic
> exercise where the cryptographic community submits proposals and
> evaluates others.

No. The largest such exercise is the cryptographic literature.

> I also keep finding it strange that you object to NIST algorithms
> while you submitted one yourself.

Please explain what you mean by "NIST algorithm" here, and please quote
the objection that you claim is contrary to submitting something.

> If you truly believe that NIST (via NSA directives) is malicious, and
> it would have picked your candidate algorithm,

"Would have"? NIST has, in fact, standardized some cryptographic systems
that I've (co-)designed.

> would you have said that therefor this "NSA condoned algorithm"
> should not be trusted nor standardized at IETF?

Is this supposed to be a quote from something?

> It seems you are cherry-picking facts to support your case.

What "case" is this referring to, and what's supposedly being
cherry-picked?

> There is a real market driven demand for (US) vendors to implement
> pure NIST algorithms

Statements such as "There are people whose cryptographic expertise I
cannot doubt who say that pure ML-KEM is the right trade-off for them,
and more importantly for my employer, that's what they're willing to
buy. Hence, Cisco will implement it" appear to be driven by NSA, not by
the market.

> 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 isn't okay. For example, this is a security disaster in the
"intercept now, decrypt later" scenario for any user data that still
needs to be confidential at the "later" moment. BCP 188 says "The IETF
Will Work to Mitigate Pervasive Monitoring", not "The IETF Will Issue
Standards That Support Pervasive Monitoring".

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

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

Please give URLs for (1) the IETF consensus that you're referring to and
(2) the statement of mine that you're referring to.

> > 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.
> I am assuming the drafts implied here are
>   draft-pwouters-crypto-current-practices and its successor
> draft-paulwh-crypto-components

Referring solely to "drafts" obviously makes this list incomplete. For
example,

    https://datatracker.ietf.org/meeting/120/materials/slides-120-saag-cryptography-at-the-ietf

included a proposal to "Limit publication of crypto RFCs". The details
of that proposal were far from clear, but

    https://notes.ietf.org/notes-ietf-120-saag

showed at least one participant interpreting the details as giving
special deference to "NIST competitions". More directly,

    https://mailarchive.ietf.org/arch/msg/saag/9e1QheO1L6SVBX3a8mFSij9AgHw/

shows an AD making various claims about NIST as purported justification
for using NIST's selections as a decision-making factor.

> If you believe the current draft has an technological error, please
> share that with us.

As part of explaining why IETF shouldn't adopt a policy of deferring to
NIST, I cited various examples of security failures not caught by NIST's
selection procedures for cryptography. Asking whether there's an error
in such a policy proposal is missing the point.

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.

It seems that the objections to previous versions of the proposals
haven't led to the ADs giving up on the proposals, and also haven't led
to better rationales for the proposals, but instead have led to the
proposals being relabeled as descriptions of the status quo. So, okay,
I'm asking for evidence that this really is the status quo.

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

The IETF statement "IETF activities are conducted with extreme
transparency, in public forums. Decision-making requires achieving broad
consensus via these public processes" is not compatible with a policy
that partially delegates IETF decisions to a non-transparent procedure,
such as NIST's procedure for selecting cryptographic algorithms. This
has nothing to do with the question of whether the policy proposal is
itself transparent.

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

"IETF activities are conducted with extreme transparency, in public
forums. Decision-making requires achieving broad consensus via these
public processes."

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?

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

If you're unable to provide clear justification for your claim that "The
recent past (eg non-pq) shows a narrowing of algorithms to mostly be 1
NIST and 1 non-NIST algorithm", please retract that claim.

Vague references to "many different processes" aren't on point. Your
previous comment about "an apparent convergence for non-pq cryptography
(inside and outside IETF) to support P256-AES-GCM and 25519-POLY-CHACHA"
was more on point, but

    https://mailarchive.ietf.org/arch/msg/saag/pFFRJu5NFvwVDV0cVCnjxq55Zuo/

went through various possibilities for what you were referring to, and
none of those possibilities match what you're claiming.

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

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

> I have spend an exorbitant amount of time

If there are URLs backing up your claims, providing those URLs would be
far less time-consuming than what you've been doing in this thread.

---D. J. Bernstein

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