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

[Paul Wouters <[e-mail]>]

On Sat, 13 May 2023, D. J. Bernstein wrote:

> I agree. There are many redundant post-quantum overviews from people and
> organizations that feel the need to prove that they're doing something.
> PQUIP shouldn't be following that path; it should instead be looking at
> what IETF should be doing to protect users.

That is not what the PQUIP charter says it should do:

https://datatracker.ietf.org/doc/charter-ietf-pquip/

> The charter says that PQUIP is supposed to "facilitate the evolution of
> IETF protocols"

This is cherry-picking the sentence out of context. The full quote:

 	Outside of the IETF, active work is underway to develop and
 	validate Post-Quantum Cryptography (PQC) mechanisms that are
 	expected to be resilient to the cryptanalysis capabilities of
 	future CRQCs (e.g., CFRG, US NIST).  Select IETF WGs (e.g.,
 	LAMPS, TLS, IPSECME, COSE) have already begun standardizing
 	revised protocol behaviors. The focus of Post-Quantum Use in
 	Protocols (PQUIP) WG is to support this growing body of work
 	in the IETF to facilitate the evolution of IETF protocols and
 	document associated operational guidance with respect to PQC.

> with respect to post-quantum cryptography. Comments on
> various post-quantum algorithms have already played a role in various
> IETF discussions; having PQUIP collect this information centrally would
> reduce the risk of error and the risk of missing more suitable options.

PQUIP is not setup to make any choices of PQ algorithms. It is
explicitly out of the charter:

 	This WG will not update existing protocols, specify new protocols,
 	define new cryptographic mechanisms, or assess whether a given
 	cryptographic mechanism is quantum-resistant.

> Mike Ounsworth writes:
>> I see this list / github page as an index of *IETF* PQC work. Trying
>> to document the PQC work in general beyond the IETF seems it is both
>> not the IETF's responsibility, as well as a never-ending task.
>
> I agree that PQUIP should be focusing on what's helpful for IETF.

Rather, it should focus on what is in its charter. Selecting PQ
candidates for recommendation is explicitly not in its charter.

> Attackers are collecting ciphertexts _right now_ in the hope of
> decrypting them with a future quantum computer. IETF can and should take
> action in response.

The IETF has taken action. Protocols _are_ working on post-quantum
algorithms. CFRG is tracking the security of various algorithms and
along with non-IETF sources is working on recommending which algorithms
it recommends IETF protocols adopt. PQUIP's contribution is, as the
charter states to:

 	provide a standing venue to discuss PQC (operational and
 	engineering) transition issues and experiences to date relevant
 	to work in the IETF. The WG will also provide a venue of last
 	resort to discuss PQC-related issues in IETF protocols that have
 	no associated maintenance WGs.

> Having general IETF post-quantum strategy analysis
> spread haphazardly across many protocol-specific lists slows this down.
> PQUIP can usefully centralize and accelerate this analysis.

Whether this is in scope depends on what you mean with "strategy" and
"analysis". Again, selecting or deselecting certain PQ algorithms is
not in charter for PQUIP.

> constraints than NIST is: for example, BCP 188 says
>
>   Pervasive monitoring is a technical attack that should be mitigated
>   in the design of IETF protocols, where possible. ... The IETF Will
>   Work to Mitigate Pervasive Monitoring
>
> which is very different from accepting years of patent-related delays,

The IETF is not a (pre or post quantum) cryptographic research facility.
Which candidates to choose in IETF protocols is something that happens
in collaboration with many non-IETF parties, that we expect to be
summarized by CFRG. What we see happening now is the development of
postquantum frameworks that can plugin in different types of postquantum
algorithms. For example, with IKEv2, work has been happening to ensure
a framework of relaying larges blobs required for PQ (RFC 9242) and work
on hybrid key echanges to ensure we can rely on classic algorithms in
case a PQ candidate supported gets broken (draft-ietf-ipsecme-ikev2-multiple-ke).

This is the type of work that can and should happen "across many
protocol specific lists", and where PQUIP can be used as the WG of
last resort for those protocols that have no running WGs left (eg ssh)
as is explicitly mentioned in the PQUIP charter.



> and BCP 25 says
>
>   The IETF must have change control over the technology described in
>   any Standards Track IETF Documents in order to fix problems that may
>   be discovered or to produce other derivative works.
>
> which is very different from accepting a license that disallows any
> "modification, extension, or derivation of the parameters of the PQC
> ALGORITHM".

Again, you are taking a quote out of context. To provide the full
context of that quote:

 	9.  Change Control for Technologies

 	The IETF must have change control over the technology described in
 	any standards track IETF Documents in order to fix problems that may
 	be discovered or to produce other derivative works.

 	In some cases the developer of patented or otherwise controlled
 	technology may decide to hand over to the IETF the right to evolve
 	the technology (a.k.a., "change control").  The implementation of an
 	agreement between the IETF and the developer of the technology can be
 	complex.  (See [RFC1790] and [RFC2339] for examples.)

 	Note that there is no inherent prohibition against a standards track
 	IETF Document making a normative reference to proprietary technology.
 	For example, a number of IETF Standards support proprietary
 	cryptographic transforms.

Again, PQUIP is not the venue to discuss which PQ algorithms the IETF
should or should not endorse.

> Realistically, abdicating to NIST regarding the selection of a KEM means
> further delay in broad post-quantum deployment. Attackers collecting
> today's ciphertexts, hoping to decrypt them with a future quantum
> computer, are very happy with this delay. I don't see how this path is
> compatible with BCP 188.

BCP188 states:

 	To summarise: current capabilities permit some actors to monitor
 	content and metadata across the Internet at a scale never before
 	seen.  This pervasive monitoring is an attack on Internet privacy.
 	The IETF will strive to produce specifications that mitigate
 	pervasive monitoring attacks.

I believe the IETF is indeed striving to do this. I understand that
you disagree with the methods and speed with which this is taking place.

I hope that at least I clarified to you why our current process is
indeed following BCP188 and BCP25 and under what charter rules the
PQUIP WG operates.

Paul