Home » Security Bloggers Network » Practical Advice for PQC Migration for TLS 1.3

Practical Advice for PQC Migration for TLS 1.3

by Dr. Angelique Faye Loe on October 8, 2024

Numerous blogs and articles are urging security professionals to start migrating to quantum-resistant algorithms immediately. This urgency was heightened on August 13, 2024, when NIST finalized the FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) standards.

In this article, I present a simplified example of a client establishing a TLS 1.3 connection to a standard web server using the quantum-resistant algorithms ML-KEM and ML-DSA. This example highlights key dependencies crucial for a successful post-quantum cryptography (PQC) migration, aiding security professionals in understanding the essential elements for adopting quantum-resistant algorithms.

Dustin Moody , is the project lead for the PQC project at NIST. His messaging was clear on the NIST announcement for the release of their three PQC standards NIST Releases First 3 Finalized Post-Quantum Encryption Standards .

Dustin mentions ‘There is no need to wait for future standards. Go ahead and start using these three. We need to be prepared in case of an attack that defeats the algorithms in these three standards, and we will continue working on backup plans to keep our data safe. But for most applications, these new standards are the main event.’

I appreciate clear and unambiguous messaging. It enables us, as security professionals, to establish firm plans and proceed with quantum-resistant algorithm migration with confidence. However, I also believe that providing some context can help us understand the key dependencies involved in this once-in-a-generation cryptographic migration.

Target Audience: The Creators of PQC vs the Consumers of PQC

Let me clarify what I mean by many of us. This article is written for those in the private and public sector organizations which are not the creators of PQC or those who determine the standards for the adoption of PQC. This article is written for those of us who will be the consumers of quantum-resistant algorithms.

The Creators of PQC

To better understand the rest of this article, it’s helpful to identify those who are creators at the heart of PQC transition. These include cryptographers and computer scientists, who submitted quantum-resistant algorithm standards to NIST, developers and contributors to cryptographic libraries such as OpenSSL, BouncyCastle, WolfSSL, and Open Quantum Safe, and members of the Certificate Authority/Browser (CA/B) Forum who manage specifications for public trust X.509 certificates. Additionally, there are IETF working groups standardizing protocols like TLS 1.3, OASIS managing cryptographic standards such as PKCS#11 and KMIP, and the Trusted Computing Group setting specifications for TPM chips.

To those PQC creators, I salute you and your invaluable work. However, this article is not aimed at you. It is intended for private and public sector organizations that will be the consumers and beneficiaries of your research, work, and collaboration.

The Consumers of PQC

For many of us, whom I shall refer to as the Consumers of PQC, we are the security professionals managing our organization’s PKI, CLM, HSM, KMS, and code signing solutions. We are also the DevSecOps professionals overseeing endpoints that terminate TLS connections, such as web servers and load balancers. Additionally, we are the sysadmins handling DNS name resolution and potentially implementing DNSSEC reliant on digital signatures. We could be mobile application developers eager to work with Apple iOS CryptoKit or Android developers exploring the latest BouncyCastle release. We might also be vehicle ECU software developers utilizing the lightweight WolfSSL library. Creating an exhaustive list of consumers of PQC would be a daunting task, as cryptography permeates many facets of the technology we use.

Set up your own quantum-safe PKI hierarchy and begin your PQC journey today.

Visit AVX PQC Test Center

Therefore, to those of you seeking meaningful context for ‘adopting PQC,’ I also salute you. We have a long, challenging, and rewarding journey ahead. This article is aimed at you, and I hope that by providing a tangible example of the key dependencies for ensuring a quantum-resistant TLS 1.3 connection, you will gain the insight you are looking for.

Dependencies for a Basic Quantum-Resistant TLS 1.3 Connection

The figure below illustrates a TLS 1.3 connection from a client web browser to a web server using an X.509 End Entity Certificate, anchored to a publicly trusted PKI. The private key for the X.509 End Entity Certificate is securely stored in a FIPS 140-3 Level 3 HSM. Additionally, the figure shows the name resolution process, where a client DNS query resolves to a DNSSEC-protected authoritative zone.

PQC Migration for TLS 1.3

Note: While this example references specific web browsers, web servers, and cryptographic libraries, it is not intended as an endorsement of these particular elements. These references are included solely to enhance clarity and context. Additionally, we use the fictitious website pqc-secure.com for illustrative purposes.

Furthermore, many aspects of this example have been streamlined for brevity and clarity. We acknowledge that most TLS connections typically pass through CDNs and load balancers, and that the DNS name resolution process has been simplified.

Item	Element	Type	Organizational Dependency	Status	Description
1	Chromium	Software, Browser	Google	In Progress	The client initiates a TLS 1.3 connection via their Chromium web browser to the fictional website pqc-secure.com. This relies on the Chromium browser’s support for quantum-resistant algorithms. Since Chrome 124, hybrid X25519Kyber768 TLS 1.3 connections have been supported, as detailed in the Chromium Blog: Advancing Our Amazing Bet on Asymmetric Cryptography</a > . This hybrid implementation uses a draft IETF post-quantum key exchange for TLS 1.3, specifically the X25519Kyber768Draft00 hybrid post-quantum key agreement X25519Kyber768Draft00 hybrid post-quantum key agreement</a > . However, to support a purely quantum-resistant ML-KEM (standardized as Kyber under FIPS 203), there is a dependency on the IETF standardizing TLS 1.3 to support ML-KEM without relying on ECDH with the X25519 curve.
2	TLS 1.3	Protocol	IETF	In Progress	The current version of TLS 1.3 is standardized under IETF’s RFC 8446, which explicitly outlines the acceptable cryptographic algorithms, namely DHE and ECDHE RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3</a > . There is currently a draft RFC, expiring on September 23, 2024, that covers ML-KEM post-quantum key agreement using ML-KEM-768 and ML-KEM-10242. This draft is titled ‘ML-KEM Post-Quantum Key Agreement for TLS 1.3’ ML-KEM Post-Quantum Key Agreement for TLS 1.3</a > . To ensure a fully quantum-resistant key establishment mechanism, there is a dependency on the IETF to provide a Standards Track RFC for TLS 1.3 that incorporates ML-KEM as the encryption algorithm for key establishment.
3	Apache	Software, Web Server	Apache Software Foundation	In Progress	Web servers like Apache rely on cryptographic libraries to perform the cryptographic operations essential for the TLS 1.3 protocol. Consequently, the ability of Apache and other web servers to support quantum-resistant algorithms depends on their integration with cryptographic libraries that offer such support. For an example of how to integrate Apache with OpenSSL to create hybrid and purely quantum-resistant TLS 1.3 connections, please visit our blog site https://www.appviewx.com/blogs/</a > as we will soon be releasing a blog on Implementing Hybrid X25519Kyber768 for Quantum-Resistant TLS 1.3 Connections.
4	OpenSSL/LibOQS	Software, Cryptographic Library	OpenSSL Software Foundation/Open Quantum Safe Project	In Progress	As noted in my earlier blog about Cryptographic Bill of Materials (CBOM) Cryptographic Bill of Materials \| CBOM \| SBOM \| PKI</a > , OpenSSL is commonly used on load balancers, email servers, VPN software, and, in this example, web servers. Cryptographic libraries are essential for supporting quantum-resistant algorithms for key establishment (encryption) and digital signatures. In our example, the dependency is on OpenSSL and the Open Quantum Safe project to support ML-KEM-768 key encapsulation for TLS 1.3. Additionally, cryptographic libraries must be capable of creating and verifying signatures using the ML-DSA algorithm, as illustrated in items 7, 8, and 9 of our diagram. For an example of how to integrate various web servers with cryptographic libraries, please refer to our blog site noted in item 3. We will soon be releasing a blog with the work instructions for implementing and testing hybrid X25519Kyber768 TLS connections.
5	PKCS#11	Cryptographic API	OASIS	In Progress	If we choose to secure the private key associated with our X.509 End Entity certificate for pqc-secure.com on an HSM, the cryptographic library must be capable of making PKCS#11 API calls to access the keying material. PKCS#11 is a platform-independent cryptographic API used to manage cryptographic tokens such as HSMs. It handles cryptographic operations including key generation, encryption, decryption, and digital signatures. Managed by the non-profit standards organization OASIS, PKCS#11 is widely supported by HSM suppliers to manage cryptographic keys. Therefore, the dependency on OASIS is to standardize the API to perform quantum-resistant cryptographic operations for algorithms such as ML-KEM and ML-DSA, as outlined in our example. You can view the progress in PKCS#11 and the related KMIP projects for the support of quantum-resistant algorithms on the OASIS website by filtering on the ‘OASIS PKCS 11 TC’ and ‘OASIS Key Management Interoperability Protocol (KMIP) TC’ groups Projects – OASIS</a >.
6	FIPS 140-3 HSM	Hardware	HSM Vendor NIST	Both – In Progress	If the ML-KEM private key is stored on a FIPS 140-3 HSM, then there is a dependency on the HSM vendor to obtain the appropriate Cryptographic Module Validation from NIST Cryptographic Module Validation Program \| CSRC \| CSRC</a > . Therefore, there is also a dependency on NIST keep up with the demand for FIPS 140-3 certifications that various hardware and software vendors will be seeking. If the ML-KEM private key is stored on a FIPS 140-3 HSM, there is a dependency on the HSM vendor to obtain the appropriate CMVP (Cryptographic Module Validation Program) certification from NIST Cryptographic Module Validation Program \| CSRC \| CSRC</a > . Additionally, there is a dependency on NIST to keep up with the demand for FIPS 140-3 certifications that various hardware and software vendors will be seeking. You can view the modules in the process backlog for CMVP for FIPS 140-3 submissions here Modules In Process List – Cryptographic Module Validation Program \| CSRC \| CSRC</a > . Please note that a submission does not necessarily indicate that quantum-resistant algorithms form part of the submission.
7	X.509 End Entity Certificate	Certificate	IETF CA/B Forum	IETF RFC 5280 – Complete CA/B Forum – In Progress	For a publicly-trusted server certificate for TLS, there are two key dependencies. First, the certificate format is defined by the IETF in RFC 5280 RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</a >: this standard is not prescriptive in algorithm selection. RFC 5280 states, ‘Implementations of this specification are not required to use any particular cryptographic algorithms.</i >’ This modularity has allowed RFC 5280, established in May 2008, to remain relevant and widely referenced today. Second, there is a dependency on the CA/B Forum to update its Baseline Requirements for TLS Server Certificates to allow the use of ML-DSA as a signature algorithm. Currently, the Baseline Requirements permit only RSA and ECDSA signatures. The latest version of the CA/B Forum Baseline Requirements for TLS Server Certificates can be found here Baseline Requirements for TLS Server Certificates</a > , with Section 7 being particularly relevant. As a side note, NIST approved the use of EdDSA in their FIPS 186-5 Digital Signature Standard in February 2023. However, 19 months later, it is still absent from the Baseline Requirements. This delay might be a deliberate choice by the CA/B Forum, but it underscores the time lag between NIST’s formalization of algorithms and their adoption by the CA/B Forum.
8	X.509 Issuing CA and Root CA	Certificate(s)	IETF CA/B Forum	IETF RFC 5280 – Complete CA/B Forum – In Progress	Similar to item 7, no further action is required from the IETF regarding RFC 5280 due to its modular nature concerning cryptographic algorithms. However, like item 7, the CA/B Forum Baseline Requirements for TLS Server Certificates will need to permit the use of ML-DSA signatures for both Certificate Authority certificate profiles and the End Entity profile to establish a fully quantum-resistant trust chain. As a side note, while ECDSA is an approved digital signature algorithm for CA and End Entity certificates under the CA/B Forum Baseline Requirements for TLS Server Certificates, not all members have implemented a complete ECDSA trust chain.
9	DNSSEC	Protocol	IANA IETF	IANA – In Progress IETF for RFC 8624 – Complete	Finally, nearly all TLS 1.3 connections will require DNS name resolution to successfully resolve the FQDN to an IP address. Some organizations have chosen to use the DNSSEC protocol to enable clients (resolvers) to verify the authenticity DNS data associated with an organization’s authoritative domains by using digital signatures. Although DNSSEC adoption has not reached a critical mass, it is nonetheless used by several private and public organizations globally. Where did DNSSEC go wrong? \| APNIC Blog</a > DNSSEC Statistics – Internet Society</a > IANA is responsible for signing the root DNS Zone. The Key Signing Ceremonies can be found here Root KSK Ceremonies (iana.org)</a >. Currently an RSA-2048 bit key is used to digitally sign the root zone. Therefore, there is another dependency on IANA to adopt a quantum-resistant digital signature such as ML-DSA to ensure the security of the DNSSEC protocol for the Internet. The current IETF RFC for DNSSEC Algorithm Implementation is RFC 8624 RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC (rfc-editor.org)</a >. Where RFC 5820 (X.509) allows modularity within its selection of cryptographic algorithms, and RFC 8446 (TLS 1.3) is explicit in its use of (EC)DH, RFC 8624 (DNSSEC) is slightly different again. RFC 8624 signposts to IANA to maintain the list of appropriate cryptographic algorithms for use with DNSSEC Domain Name System Security (DNSSEC) Algorithm Numbers (iana.org)</a >. Currently ML-DSA does not feature on the list of accepted algorithms.
All	Algorithm OIDs	Object Identifiers	NIST	Complete	Now, the final dependency that is required for almost every aspect in our TLS 1.3 connection example is the NIST quantum-resistant algorithm OIDs. NIST maintains a list of OIDs on its CSOR (Computer Security Objects Register) Algorithm Registration – Computer Security Objects Register \| CSRC \| CSRC</a >. By way of example, instead of human saying ‘I want an ML-DSA-44 signature’, the various systems described in this example will unambiguously refer this signature as a 2.16.840.1.101.3.4.3.17 signature. The IETF protocols and standards can then use the OIDs noted on the CSOR to explicitly use the precise algorithms they intend to use. Currently this dependency is fulfilled as NIST has released the OID’s related to the FIPS 203, FIPS 204, and FIPS 205 standards.

Summary

The purpose of this article is to provide context to these dependencies and reassure you that it’s completely understandable if you haven’t fully adopted quantum-resistant algorithms yet. The best thing you can do right now is to understand your estate and ensure it is ready and well-prepared when these dependencies are addressed, see our previous blog for guidance on preparations Quantum Computing and the Risk to Classical Cryptography .

By understanding and addressing these dependencies, we can ensure that our systems are prepared for the quantum era, safeguarding our data against the threat of a CRQC. The journey towards quantum-resistant security is complex and collaborative, but with continued effort and cooperation, we can achieve robust and resilient cryptographic solutions.