Re: [Pqc] [Ext] Listing pointers to not-yet-standardized PQC algorithms

["D. J. Bernstein" <[e-mail]>]

Russ Housley writes:
> The LAMPS WG charter sets the scope of PQ algorithms that can be
> considered.  They need to be NIST-approved or GFRG-approved. I hope we
> can have the same criteria across the IETF.

>From a security perspective, those limitations are problematic:

   * NIST's selections so far have, to the extent that people are
     following NIST, created years of patent-related delays in
     deployment of post-quantum encryption. This is a security problem
     right now, under the reasonable assumption that future attackers
     will have large quantum computers.

   * NIST's selections don't include any conservative encryption
     options. (This, like NIST not requiring hybrids, is most easily
     explained as overconfidence.) Obviously various non-NIST
     organizations (e.g., BSI) are taking a very different path here.

The CFRG add-on doesn't help---CFRG was very fast in vetting stateful
hash-based signature schemes but is far behind other organizations in
handling post-quantum encryption.

As a procedural matter, the LAMPS charter was last modified in May 2021,
which is before NIST issued its selections (July 2022). It would be good
for LAMPS to recognize the security problems at hand and expand its
charter accordingly.

(As a side note, I think that the opposite extreme, with all IETF WGs
requiring CFRG algorithm vetting, could work well if CFRG takes this
job seriously. But this would be a much larger change from the current
situation, and I think it would need an IESG policy decision.)

As another procedural matter, the PQUIP charter does not have the same
limitations as the LAMPS charter. Why is a LAMPS co-chair showing up on
the PQUIP mailing list and pointing to a current LAMPS restriction as an
argument for limiting PQUIP's activities, rather than acknowledging that
the PQUIP charter is different?

If there's a problem caused by the differences between the charters,
then surely the decision on the way forward should start by looking at
the relevant goals for IETF (such as BCP 188) and figuring out how to
organize the work into WGs, rather than by one current charter being
allowed to override another.

Right now there's a mess of different WGs looking at post-quantum
updates to specific protocols _and_ looking at protocol-independent
questions. Surely it would be better to have protocol-independent
discussions (example: should IETF let NIST slow down IETF's response to
the quantum threat?) centralized in PQUIP---meaning, e.g., that LAMPS
should focus on issues specific to updating PKIX and SMIME, and should
avoid being in the position of making IETF-wide post-quantum decisions.

---D. J. Bernstein