Post-Quantum Guidance for current deployments of IETF protocols.

[[This is not an "official" work item anywhere, the -00 was proposed to TLS as such, but this version generalises to more than just TLS. This was discussed at the IETF-124 secdispatch session and the outcome was that further discussion should be on the general security area list. (saag@ietf.org) The source for this is in https://github.com/sftcd/pqg/ PRs are welcome there too.]] Due to concerns about the possible future existence of a cryptographically relevant quantum computer (CRQC), a number of IETF working groups have defined ways in which post-quantum (PQ) cryptographic algorithms can be used with IETF protocols such as TLS, SSH, IPsec, OpenPGP and others and with the public key infrastructure (PKI) that supports a number of these protocols. Implementers have also made headway in incorporating these changes into sometimes widely used implementations. However, once supported by implementations, these changes support many different configurations so those deploying post-quantum algorithms now can be faced with an overly-broad set of choices, some of which might lead to worse interoperability or even lesser security than others. This document provides current guidance on a very high-level set of deployment choices that are recommended for use today. It is reasonably likely that this guidance will change in the not-too distant future, as post-quantum support in protocols and implementations matures, so this document may well be updated in the relatively near future. The format of this document is to provide very concise guidance in , and follow that with background material. A reader pressed for time may be able to stop reading at the end of . Some more specialised implementations and environments may have to meet other requirements that conflict with this guidance - in such cases those deploying will need to do more research in order to select good options. More detailed background is provided in and . The audience for this document are those deploying systems now. This guidance is not aimed at those developing IETF protocols, nor implementations of those. Given that it seems that the latter groups (protocol developers and implementers) seem determined to define and implement almost every possible combination of PQ everything, those deploying systems now, that have such PQ all kinds of everything, can benefit from simple guidance that addresses the most important aspect of the PQ transition.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

We RECOMMEND moving as soon as practical to use of PQ/T hybrid Key Encapsulation Mechanisms (KEMs). Once it becomes practical to use hybrid KEMs, such as X25519MLKEM768 for TLS, we do NOT RECOMMEND use of non-hybrid/classic groups or "pure" PQ KEMs.

For almost all deployments, we RECOMMEND taking no action at all at this point in time in relation to deployment of PQ signatures.

Many additional IANA codepoints (dozens) have been defined by IETF working groups for algorithms that are hoped to remain secure even in the face of a CRQC. Adding code-points to some relevant IANA registries doesn't require IETF consensus. This means that, in such case, anyone can register code-points for their favoured approach, typically so long as there is some specification for the algorithm concerned. For example, anyone can register a PQ algorithm in the TLS named group registry with the RECOMMENDED column set to 'n' Various government entities in different countries have made contradictory recommendations in this space, leading to potential confusion for those deploying applications using PQ algorithms. Hybrid KEMs are combinations of two or more KEMs with the goal of providing security as long as one of the component KEMs is able to provide security. Hybrid KEMs therefore typically consist of a newer, presumed post-quantum secure KEM (such as ML-KEM), to guard against attacks by a CRQC, as well as an established traditional KEM (such as variations of ECDH-KEM), to guard against rapid cryptanalysis of the post-quantum KEM. Any reasonable Hybrid KEM construction provides greater security guarantees than single KEMs, but they may differ in the exact scenarios in which they provide such guarantees (e.g. only cryptanalysis against one KEM vs. some implementation faults in one KEM) and in how they are used in specific protocols. Generally, the IETF WG responsible for a specific protocol will have done the analysis as to how to safely incorporate hybrid KEMs. Whereas key establishment needs to guard against passive attacks, which may be conducted long after online communication has taken place (i.e. harvest now, decrypt later attacks), signatures are typically only required to guard against active attacks. Therefore, a traditional signature scheme can secure protocols for as long as CRQCs do not exist. Systems dealing with signatures that are required to still be usefully verifiable in the timeframe that might include a CRQC are rare and complex and are not further considered here. Systems that need to select a signature verification public key (and hence algorithm) now, for use in some years time, are also not covered by this guidance.

As we transition from RSA and ECC based algorithms to newer approaches, we will necessarily gather implementation experience and learn from failures. Those deploying such systems are therefore advised to regularly monitor cryptanalytic advancements as well as attacks against natural implementations of newer schemes, and guard against failures using hybrid constructions such as the ones indicated above.

Thanks to Thomas Bellebaum for (subsequently heavily edited) background text. All errors, opinions, and ommisions of course remain the fault of the author.

TBD, but probably not needed.