Post-Quantum Guidance for current deployments of IETF protocols.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 June 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[[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 Section 3, and follow that with background material. A reader pressed for time may be able to stop reading at the end of Section 3. 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 [RFC9794] and [I-D.ietf-pquip-pqc-engineers].¶

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

3. Recommendations

4. Background and Justifications

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

Author's Address