Internet DRAFT - draft-reddy-uta-pqc-app
draft-reddy-uta-pqc-app
uta T. Reddy
Internet-Draft Nokia
Intended status: Standards Track 2 March 2024
Expires: 3 September 2024
Post-Quantum Cryptography Recommendations for Internet Applications
draft-reddy-uta-pqc-app-02
Abstract
Post-quantum cryptography brings some new challenges to applications,
end users, and system administrators. This document describes
characteristics unique to application protocols and best practices
for deploying Quantum-Ready usage profiles for applications using
TLS.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-reddy-uta-pqc-app/.
Discussion of this document takes place on the uta Working Group
mailing list (mailto:uta@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/uta/. Subscribe at
https://www.ietf.org/mailman/listinfo/uta/.
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 3 September 2024.
Reddy Expires 3 September 2024 [Page 1]
Internet-Draft PQC Recommendations for Applications March 2024
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Timeline for transition . . . . . . . . . . . . . . . . . . . 4
4. Data Confidentiality . . . . . . . . . . . . . . . . . . . . 5
5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 7
6. Informing Users of PQC Security Compatibility Issues . . . . 8
7. Application Protocols . . . . . . . . . . . . . . . . . . . . 9
7.1. Encrypted DNS . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Hybrid public-key encryption (HPKE) . . . . . . . . . . . 9
7.2.1. Interaction with Encrypted Client Hello . . . . . . . 10
7.2.2. Oblivious HTTP . . . . . . . . . . . . . . . . . . . 10
7.2.3. MLS . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.5. Email Submission . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . . 13
Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The visible face of the Internet largely consists of services that
employ a client-server architecture in which a client communicates
with an application service. When a client communicates with an
application service using protocols such as TLS 1.3 [RFC8446], DTLS
1.3 [RFC9147], or a protocol built on those (QUIC [RFC9001] being a
notable example), the client and server can perform ephemeral public-
key exchange mechanism, such as ECDH, to derive the shared secret for
forward secrecy. They can validate each other's identity using X.509
Reddy Expires 3 September 2024 [Page 2]
Internet-Draft PQC Recommendations for Applications March 2024
certificates to establish secure communication.
The presence of a Cryptographically Relevant Quantum Computer (CRQC)
would render state-of-the-art, traditional public-key algorithms
deployed today obsolete and insecure, since the assumptions about the
intractability of the mathematical problems for these algorithms that
offer confident levels of security today no longer apply in the
presence of a CRQC. This means there is a requirement to update
protocols and infrastructure to use post-quantum algorithms, which
are public-key algorithms designed to be secure against CRQCs as well
as classical computers. The traditional cryptographic primitives
that need to be replaced by PQC are discussed in
[I-D.ietf-pquip-pqc-engineers].
The industry has successfully upgraded TLS versions while deprecating
old versions (e.g., SSLv2), and many protocols have transitioned from
RSA to Elliptic Curve Cryptography (ECC) improving security while
also reducing key sizes. The transition to post-quantum crypto
brings different challenges, most significantly, the new Post-Quantum
algorithms:
1. are still being evaluated against both classical and post-quantum
attacks,
2. typically use larger key sizes (which increases handshake packet
size). For example, the public key sizes of ML-KEM is much
larger than ECDH (see Table 5 in [I-D.ietf-pquip-pqc-engineers])
and the public key sizes of Dilithium/Falcon are much larger than
P256 (see Table 6 in [I-D.ietf-pquip-pqc-engineers]), and
3. While certain post-quantum (PQ) algorithms are comparatively
slower than their traditional counterparts, it's important to
note that specific PQ algorithms also showcase faster
performance. For instance, ML-KEM utilizes less CPU than X25519,
and both Dilithium and Falcon exhibit faster signature
verification times than Ed25519, although with slower signature
generation times.
All applications transmitting messages over untrusted networks can be
susceptible to active or passive attacks by adversaries using CRQCs,
with varying degrees of significance for both users and the
underlying systems. This document explores Quantum-Ready usage
profiles for applications specifically designed to defend against
passive and on-path attacks employing CRQCs. TLS client and server
implementations, as well as applications, can mitigate the impact of
these challenges through various techniques described in subsequent
sections.
Reddy Expires 3 September 2024 [Page 3]
Internet-Draft PQC Recommendations for Applications March 2024
2. Conventions and Definitions
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses terms defined in
[I-D.ietf-pquip-pqt-hybrid-terminology]. For the purposes of this
document, it is helpful to be able to divide cryptographic algorithms
into three classes:
"Traditional Algorithm": An asymmetric cryptographic algorithm based
on integer factorisation, finite field discrete logarithms or
elliptic curve discrete logarithms. In the context of TLS, examples
of traditional key exchange algorithms include Elliptic Curve Diffie-
Hellman (ECDH); which is almost always used in the ephemeral mode
referred to as Elliptic Curve Diffie-Hellman Ephemeral (ECDHE).
"Post-Quantum Algorithm": An asymmetric cryptographic algorithm that
is believed to be secure against attacks using quantum computers as
well as classical computers. Examples of PQC key exchange algorithms
include the Module-Lattice Key Encapsulation Mechanism (ML-KEM),
which is widely known as Kyber.
"Hybrid" key exchange, in this context, means the use of two
component key exchange algorithms -- one traditional algorithm and
one Post-Quantum algorithm. The final shared secret key is secure
when at least one of the component key exchange algorithms remains
unbroken. It is referred to as PQ/T Hybrid Scheme in
[I-D.ietf-pquip-pqt-hybrid-terminology].
The same categories also apply to digital signature algorithms as
used in X.509 certificates, Certificate Transparency SCTs, OCSP
statements, Remote Attestations, and any other mechanism that
contributes signatures to a TLS handshake.
3. Timeline for transition
The timeline and driving motivation for Quantum-Ready transition
differ between data confidentiality and data authentication (e.g.,
signature). Digital signatures are used within X.509 certificates,
Certificate Revocation Lists (CRLs), and to sign messages.
Encrypted payloads transmitted via Transport Layer Security (TLS) can
be susceptible to decryption if an attacker equipped with a CRQC
gains access to the traditional asymmetric public keys used in the
Reddy Expires 3 September 2024 [Page 4]
Internet-Draft PQC Recommendations for Applications March 2024
TLS key exchange and the transmitted ciphertext. TLS implementations
commonly utilize Diffie-Hellman schemes for key exchange. If an
attacker has copies of an entire set of encrypted payloads, including
the TLS setup, it could employ CRQCs to potentially decrypt the
payload by determining the private key.
For data confidentiality, we are concerned with the so-called
"Harvest Now, Decrypt Later" attack where a malicious actor with
adequate resources can launch an attack to store encrypted data today
that can be decrypted once a CRQC is available. This implies that,
even today, encrypted data is susceptible to the attack by not
implementing quantum-safe strategies, as it corresponds to data being
deciphered in the future. The storage time and effective security
lifetime of this encrypted data might vary from seconds to decades.
For data authentication, our concern lies with an on-path attacker
who possesses devices equipped with CRQCs capable of breaking
traditional authentication protocols. For instance, the attacker can
fake the identity of the target, leading victims to connect to the
attacker's device instead of connecting to the actual target,
resulting in an impersonation attack. While not an immediate threat,
it is still a concern when compared to the 'Harvest Now, Decrypt
Later' attack.
In client/server certificate-based authentication, it's common for
the certificate's signature in the TLS handshake to have a short
lifetime. This means that the time between the certificate signing
the CertificateVerify message and its verification by the peer during
the TLS handshake is limited. However, it's worth questioning the
security lifetime of the digital signatures on X.509 certificates,
including those issued by root Certificate Authorities (CAs). Root
CAs can have lifetimes of 20 years or more. Additionally, root
Certificate Revocation Lists (CRLs) may have lifetimes of a year or
more, while delegated credentials like CRL Signing Certificates or
OCSP response signing certificates can have lifetimes that fall
anywhere in between.
4. Data Confidentiality
Data in transit may need to be protected for lifetimes measured in
years. The possibility of CRQCs being developed means that we need
to move away from traditional algorithms, but at the same time
uncertainty about post-quantum algorithm implementation security, lag
in standardization, regulatory requirements, and maturity of
cryptanalysis may require the continued use of mature traditional
algorithms alongside the new post-quantum primitives.
Reddy Expires 3 September 2024 [Page 5]
Internet-Draft PQC Recommendations for Applications March 2024
The primary goal of a hybrid key exchange mechanism is to facilitate
the establishment of a shared secret which remains secure as long as
one of the component key exchange mechanisms remains unbroken.
[I-D.ietf-tls-hybrid-design] provides a construction for hybrid key
exchange in TLS 1.3. It fulfils the primary goal of hybrid key
exchange, with additional objectives discussed in Section 1.5 of the
same document.
Applications that use (D)TLS and susceptible to CRQC attack MUST
migrate to (D)TLS 1.3 and support the hybrid key exchange, as defined
in [I-D.ietf-tls-hybrid-design]. In the future, we anticipate a
shift away from traditional cryptographic algorithms in favor of
post-quantum algorithms. This transition is expected to provide
benefits in terms of CPU efficiency and reduced data transmission
overhead compared to hybrid key exchange.
The client initiates the TLS handshake by sending a list of key
agreement methods it supports in the key_share extension. One of the
challenges during the PQC migration is that the client may not know
whether the server supports the Hybrid key exchange. To address this
uncertainty, the client can adopt one of two strategies:
1. Sending Both Traditional and Hybrid Key Exchange Algorithms: In
the initial ClientHello message, the client has the option to
send both traditional and hybrid key exchange algorithm key
shares to the server, eliminating the need for multiple round
trips. It's important to note that the size of the hybrid key
exchange algorithm key share may exceed the MTU, leading to the
possibility of splitting the ClientHello message across multiple
packets. However, this approach necessitates additional
computations on the client side and results in increased
handshake traffic. During the TLS handshake, the server responds
to the ClientHello by providing its public key and ciphertext.
If the combined size of these components exceeds the MTU, there's
a chance that the ServerHello message may be fragmented across
multiple TCP packets. This fragmentation raises the risk of lost
packets and potential delays due to retransmission.
2. Indicate Support for Hybrid Key Exchange: Alternatively, the
client may initially indicate support for hybrid key exchange and
send a traditional key exchange algorithm key share in the first
ClientHello message. If the server supports hybrid key exchange,
it will use the HelloRetryRequest to request a hybrid key
exchange algorithm key share from the client. The client can
then send the hybrid key exchange algorithm key share in the
second ClientHello message.
Reddy Expires 3 September 2024 [Page 6]
Internet-Draft PQC Recommendations for Applications March 2024
Clients MAY use information from completed handshakes to cache the
server's preferences for key exchange algorithms ([RFC8446], section
4.2.7).
In order to avoid multiple packets to send ClientHello message, the
client would have to prevent the duplication of PQC KEM public key
shares in the ClientHello, avoiding duplication of key shares is
discussed in Section 4 of [I-D.ietf-tls-hybrid-design].
[I-D.davidben-tls-key-share-prediction] defines a mechanism for
servers to communicate key share preferences in DNS responses. TLS
clients can use this information to reduce TLS handshake round-trips.
5. Authentication
While CRQCs could decrypt previous TLS sessions, client/server
authentication based on certificates cannot be retroactively broken.
However, given the multi-year lead-time required to establish,
certify, and embed new root CAs, it would be difficult to react in a
timely manner if CRQCs come online sooner than anticipated. So while
PQ migration of X.509 certificates has more time than key exchanges,
we should not delay this work for too long.
The Quantum-Ready authentication property can be utilized in
scenarios where an on-path attacker possesses network devices
equipped with CRQCs, capable of breaking traditional authentication
protocols. If an attacker uses CRQC to determine the private key of
a server certificate before the certificate expiry, the attacker can
create a fake server, and then every user will think that their
connection is legitimate. The server impersonation leads to various
security threats, including impersonation, data disclosure, and the
interception of user data and communications.
The Quantum-Ready authentication property ensures authentication
through either a pure Post-Quantum or a PQ/T hybrid Certificate.
* A Post-Quantum X.509 Certificate using Module-Lattice Digital
Signature Algorithm (ML-DSA), also called
Dilithium, is defined in [I-D.ietf-lamps-dilithium-certificates].
* The PQ/T Hybrid Authentication property is currently still under
active exploration and discussion in the
LAMPS WG, and consensus may evolve over time regarding its
adoption.
* The non-composite hybrid authentication discussed in
[I-D.ietf-lamps-cert-binding-for-multi-auth] enables peers to
employ the same certificates in hybrid authentication as in
Reddy Expires 3 September 2024 [Page 7]
Internet-Draft PQC Recommendations for Applications March 2024
authentication done with only traditional or post-quantum
algorithms. In TLS, peers can request that both traditional and
PQ certificate be used for authentication. For instance,
traditional certificates can be exchanged during the TLS handshake
and PQ certificates can be exchanged after the session has been
established using the mechanism defined in [RFC9261].
* The composite signature contains two signatures in a single atomic
container that have been generated
using two different cryptographic algorithms. For example, NIST
define a dual signature as "two or more signatures on a common
message". The goal of this approach is to define a signature
format which requires both contained signatures to be verified.
This concept is described in Composite Signatures For Use In
Internet PKI [I-D.ounsworth-pq-composite-sigs].
To decide whether and when to support a Post-Quantum Certificate
(PQC) or a PQ/T hybrid scheme for client and server authentication,
it is important to consider factors such as the frequency and
duration of system upgrades, as well as the anticipated availability
of CRQCs. For example, applications that have extremely short key
lifetimes -- for example less than an hour -- may decide that it is
an acceptable risk to leave those on Traditional algorithms for the
foreseeable future under the assumption that quantum key factoring
attacks take longer to run than the key lifetimes. It may be
advantageous to explore heterogeneous PKI architectures where the
long-lived CAs are using Post-Quantum algorithms but the server and
client certificates are not. In summary, if the signature is not
post-quantum secure, further evaluation is needed to determine
whether the attempt to achieve post-quantum security using short-
lived keys is effective or not.
6. Informing Users of PQC Security Compatibility Issues
When the server detects that the client doesn't support PQC or hybrid
key exchange, it can send an 'insufficient_security' fatal alert to
the client. The client can inform the end-users that the server they
are trying to access requires a level of security that the client
cannot provide due to the lack of PQC support. Furthermore, the
client may log the event for diagnostic and security auditing
purposes and report the security-related issue to the client
development team.
Similarly, when the client detects that the server doesn't support
PQC or hybrid key exchange, it can send an alert or error page to the
client. The message can inform the end-user that the server is not
compatible with the PQC security features offered by the client.
Reddy Expires 3 September 2024 [Page 8]
Internet-Draft PQC Recommendations for Applications March 2024
7. Application Protocols
7.1. Encrypted DNS
The privacy risks for end users exchanging DNS messages in clear text
are discussed in [RFC7518]. Transport Layer Security (TLS) is
employed to ensure privacy for DNS. DNS encryption provided by TLS
(e.g., DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC) eliminates
opportunities for eavesdropping and on-path tampering while in
transit through the network.
Encrypted DNS messages transmitted using Transport Layer Security
(TLS) may be vulnerable to decryption if an attacker gains access to
the traditional asymmetric public keys used in the TLS key exchange.
If an attacker possesses copies of an entire set of encrypted DNS
messages, including the TLS setup, it could use a CRQC to potentially
decrypt the message content by determining the ephemeral key exchange
private key.
Encrypted DNS protocols will have to support the Quantum-Ready usage
profile discussed in {#confident}.
Note that post-quantum security of DNSSEC [RFC9364], which provides
authenticity for DNS records, is a separate issue from the
requirements for encrypted DNS transports.
7.2. Hybrid public-key encryption (HPKE)
Hybrid public-key encryption (HPKE) is a scheme that provides public
key encryption of arbitrary-sized plaintexts given a recipient's
public key. HPKE utilizes a non-interactive ephemeral-static Diffie-
Hellman exchange to establish a shared secret. The motivation for
standardizing a public key encryption scheme is explained in the
introduction of [RFC9180].
HPKE can be extended to support PQ/T Hybrid post-quantum Key
Encapsulation Mechanisms (KEMs) as defined in
[I-D.westerbaan-cfrg-hpke-xyber768d00-02]. Kyber, which is a KEM
does not support the static-ephemeral key exchange that allows HPKE
based on DH based KEMs. Note that X25519Kyber768Draft00 is IND-CCA2
secure (Section 4 of [I-D.westerbaan-cfrg-hpke-xyber768d00-02]).
Reddy Expires 3 September 2024 [Page 9]
Internet-Draft PQC Recommendations for Applications March 2024
7.2.1. Interaction with Encrypted Client Hello
Client TLS libraries and applications can use Encrypted Client Hello
(ECH) [I-D.ietf-tls-esni] to prevent passive observation of the
intended server identity in the TLS handshake which requires also
deploying Encrypted DNS (DNS over TLS), otherwise a passive listener
can observe DNS queries (or responses) and infer same server identity
that was being protected with ECH. ECH uses HPKE for public key
encryption.
ECH MUST incorporate support for PQ/T Hybrid post-quantum KEMs to
protect against the 'Harvest Now, Decrypt Later' attack.
To use ECH the client needs to learn the ECH configuration for a
server before it attempts a connection to the server. Bootstrapping
TLS Encrypted ClientHello with DNS Service Bindings specification
[I-D.draft-ietf-tls-svcb-ech] provides a mechanism for conveying the
ECH configuration information via DNS, using a SVCB or HTTPS record.
The "ech" SvcParamKey is used in SVCB or HTTPS or DNS records, and is
intended to serve as the primary bootstrap mechanism for ECH. The
value of the parameter is an ECHConfigList (Section 4 of
[I-D.ietf-tls-esni]). The public_key in HpkeKeyConfig structure
would carry the concatenation of traditional and PQC KEM public keys
which would increase DNS resposnse size that could exceed the path
MTU. It would require the use of reliable transport and Encrypted
DNS (e.g., DoT, DoH or DoQ).
7.2.2. Oblivious HTTP
Oblivious HTTP [I-D.ietf-ohai-ohttp] allows clients to encrypt
messages exchanged with an Oblivious Target Resource (target). The
messages are encapsulated in encrypted messages to an Oblivious
Gateway Resource (gateway), which offers Oblivious HTTP access to the
target. The gateway is accessed via an Oblivious Relay Resource
(relay), which proxies the encapsulated messages to hide the identity
of the client. Overall, this architecture is designed in such a way
that the relay cannot inspect the contents of messages, and the
gateway and target cannot learn the client's identity from a single
transaction. Oblivious HTTP uses HPKE for encapsulating binary HTTP
messages to protect their contents.
Oblivious HTTP is vulnerable to decryption if an attacker gains
access to the traditional asymmetric public keys used in the HPKE.
If an attacker possesses copies of an entire set of encapsulated HTTP
messages, it could use CRQC to potentially decrypt the message
content by determining the private key. The attacker can potentially
be the Oblivious Relay Resource.
Reddy Expires 3 September 2024 [Page 10]
Internet-Draft PQC Recommendations for Applications March 2024
The "ohttp" SvcParamKey defined in [I-D.ietf-ohai-svcb-config] is
used to indicate that a service described in an SVCB RR can be
accessed as a target using an associated gateway. For the "dns"
scheme, as defined in [I-D.draft-ietf-add-svcb-dns], the presence of
the "ohttp" parameter means that the DNS server being described has a
DNS over HTTP (DoH) [RFC8484] service that can be accessed using
Oblivious HTTP.
Oblivious HTTP and DNS over Oblivious HTTP MUST incorporate support
for PQ/T Hybrid post-quantum KEMs to protect against the 'Harvest
Now, Decrypt Later' attack.
7.2.3. MLS
The Messaging Layer Security (MLS) Protocol [RFC9420] enables
asynchronous group keying with forward secrecy and post-compromise
security. MLS uses HPKE for public key encryption. HPKE can be
extended to support PQ/T Hybrid post-quantum Key Encapsulation
Mechanisms (KEMs) as defined in
[I-D.westerbaan-cfrg-hpke-xyber768d00-02].
7.3. WebRTC
In WebRTC, secure channels are set up via DTLS and DTLS-SRTP
[RFC5763] keying for SRTP [RFC3711] for media channels and the Stream
Control Transmission Protocol (SCTP) over DTLS [RFC8261] for data
channels.
Secure channels may be vulnerable to decryption if an attacker gains
access to the traditional asymmetric public keys used in the DTLS key
exchange. If an attacker possesses copies of an entire set of
encrypted media, including the DTLS setup, it could use CRQC to
potentially decrypt the media by determining the private key.
WebRTC media and data channels MUST support the Quantum-Ready usage
profile discussed in {#confident}.
The other challenge with WebRTC is that PQC KEMs often come with
large public keys and PQC Signature schemes come with large
signatures in comparison with traditional algorithms (as discussed in
Section 12 and 13 of [I-D.ietf-pquip-pqc-engineers]). In many cases,
UDP datagrams are restricted to sizes smaller than 1500 bytes. If IP
fragmentation needs to be avoided, each DTLS handshake message must
be fragmented over several DTLS records, with each record intended to
fit within a single UDP datagram. This approach could potentially
lead to increased time to complete the DTLS handshake and involve
multiple round-trips in lossy networks. It may also extend the time
required to set up secure WebRTC channels. One potential mitigation
Reddy Expires 3 September 2024 [Page 11]
Internet-Draft PQC Recommendations for Applications March 2024
strategy to avoid the delay is to prevent the duplication PQC KEM
public key shares in the ClientHello, avoiding duplication of key
shares is discussed in Section 4 of [I-D.ietf-tls-hybrid-design].
7.4. HTTPS
HTTPS (Hypertext Transfer Protocol Secure) is the secure version of
HTTP used for secure data exchange over the web. HTTPS primarily
relies on the TLS (Transport Layer Security) protocol to provide
encryption, integrity, and authenticity for data in transit.
HTTP messages transmitted using Transport Layer Security (TLS) may be
vulnerable to decryption if an attacker gains access to the
traditional asymmetric public keys used in the TLS key exchange. If
an attacker possesses copies of an entire set of encrypted HTTP
messages, including the TLS setup, it could use CRQC to potentially
decrypt the message content by determining the private key. This
traffic can include sensitive information, such as login credentials,
personal data, or financial details, depending on the nature of the
communication.
If an attacker can decrypt the message content before the expiry of
the login credentials, the attacker can steal the credentials. The
theft of login credentials is a serious security concern that can
have a wide range of consequences for individuals and organizations.
The most immediate and obvious challenge is that the attacker gains
unauthorized access to the victim's accounts, systems, or data. This
can lead to data breaches, privacy violations, and various forms of
cybercrime.
Applications using HTTPS to exchange sensitive data MUST support the
Quantum-Ready usage profile discussed in {#confident}. If the data is
genuinely non-sensitive and has no privacy or security implications,
the motivation for an attacker to invest resources in capturing and
later decrypting it would likely be very low. In such cases, the
"Harvest Now, Decrypt Later" attack may not be relevant. In similar
lines, reverse proxies operated between clients and origin servers
will also have to support {#confident}.
7.5. Email Submission
Email often contains information that needs protection from passive
monitoring or active modification. While some standards exist for
protecting integrity and for encrypting content of messages
themselves (see [RFC8551]), transport encryption is also frequently
used. TLS support for Email Submission/Access is described in
Section 3.3 of [RFC8314]. The Mail User Agent (MUA) and a Mail
Submission Server or Mail Access Server MUST support the Quantum-
Reddy Expires 3 September 2024 [Page 12]
Internet-Draft PQC Recommendations for Applications March 2024
Ready usage profile discussed in {#confident}.
8. Security Considerations
Post-quantum algorithms selected for standardization are relatively
new and they they have not been subject to the same depth of study as
traditional algorithms. PQC implementations will also be new and
therefore more likely to contain implementation bugs than the battle-
tested crypto implementations that we rely on today. In addition,
certain deployments may need to retain traditional algorithms due to
regulatory constraints, for example FIPS [SP-800-56C] or PCI
compliance. Hybrid key exchange enables potential security against
"Harvest Now, Decrypt Later" attack provide for time to react in the
case of the announcement of a devastating attack against any one
algorithm, while not fully abandoning traditional cryptosystems.
Implementing PQ/T hybrid schemes improperly can introduce security
issues at the cryptographic layer, for example how the Traditional
and PQ schemes are combined; at the algorithm selection layer,
mismatched security levels for example if 192-bit KEM is used with a
128-bit secure combiner; or at the protocol layer in how the upgrade/
downgrade mechanism works. PQ/T hybrid schemes should be implemented
carefully and all relevant specifications implemented correctly.
Acknowledgements
Thanks to Dan Wing for suggesting wider document scope. Thanks to
Mike Ounsworth, Scott Fluhrer, Bas Westerbaan and Thom Wiggers for
review and feedback.
References
Normative References
[I-D.davidben-tls-key-share-prediction]
Benjamin, D., "TLS Key Share Prediction", Work in
Progress, Internet-Draft, draft-davidben-tls-key-share-
prediction-00, 25 September 2023,
<https://datatracker.ietf.org/doc/html/draft-davidben-tls-
key-share-prediction-00>.
[I-D.draft-ietf-add-svcb-dns]
Schwartz, B. M., "Service Binding Mapping for DNS
Servers", Work in Progress, Internet-Draft, draft-ietf-
add-svcb-dns-09, 26 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-add-
svcb-dns-09>.
Reddy Expires 3 September 2024 [Page 13]
Internet-Draft PQC Recommendations for Applications March 2024
[I-D.ietf-tls-hybrid-design]
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-hybrid-design-09, 7 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
hybrid-design-09>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/rfc/rfc3711>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/rfc/rfc5763>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
"Datagram Transport Layer Security (DTLS) Encapsulation of
SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
2017, <https://www.rfc-editor.org/rfc/rfc8261>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261,
DOI 10.17487/RFC9261, July 2022,
<https://www.rfc-editor.org/rfc/rfc9261>.
Reddy Expires 3 September 2024 [Page 14]
Internet-Draft PQC Recommendations for Applications March 2024
Informative References
[I-D.draft-ietf-tls-svcb-ech]
Schwartz, B. M., Bishop, M., and E. Nygren, "Bootstrapping
TLS Encrypted ClientHello with DNS Service Bindings", Work
in Progress, Internet-Draft, draft-ietf-tls-svcb-ech-00,
26 September 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-tls-svcb-ech-00>.
[I-D.ietf-lamps-cert-binding-for-multi-auth]
Becker, A., Guthrie, R., and M. J. Jenkins, "Related
Certificates for Use in Multiple Authentications within a
Protocol", Work in Progress, Internet-Draft, draft-ietf-
lamps-cert-binding-for-multi-auth-03, 29 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cert-binding-for-multi-auth-03>.
[I-D.ietf-lamps-dilithium-certificates]
Massimo, J., Kampanakis, P., Turner, S., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure:
Algorithm Identifiers for ML-DSA", Work in Progress,
Internet-Draft, draft-ietf-lamps-dilithium-certificates-
03, 5 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
dilithium-certificates-03>.
[I-D.ietf-ohai-ohttp]
Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-ietf-ohai-ohttp-10, 25
August 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-ohai-ohttp-10>.
[I-D.ietf-ohai-svcb-config]
Pauly, T. and T. Reddy.K, "Discovery of Oblivious Services
via Service Binding Records", Work in Progress, Internet-
Draft, draft-ietf-ohai-svcb-config-07, 6 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ohai-
svcb-config-07>.
[I-D.ietf-pquip-pqc-engineers]
Banerjee, A., Reddy.K, T., Schoinianakis, D., and T.
Hollebeek, "Post-Quantum Cryptography for Engineers", Work
in Progress, Internet-Draft, draft-ietf-pquip-pqc-
engineers-03, 22 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-engineers-03>.
Reddy Expires 3 September 2024 [Page 15]
Internet-Draft PQC Recommendations for Applications March 2024
[I-D.ietf-pquip-pqt-hybrid-terminology]
D, F., "Terminology for Post-Quantum Traditional Hybrid
Schemes", Work in Progress, Internet-Draft, draft-ietf-
pquip-pqt-hybrid-terminology-02, 2 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqt-hybrid-terminology-02>.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-17, 9 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-17>.
[I-D.ounsworth-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., and J. Klaußner,
"Composite Signatures For Use In Internet PKI", Work in
Progress, Internet-Draft, draft-ounsworth-pq-composite-
sigs-12, 11 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ounsworth-pq-
composite-sigs-12>.
[I-D.westerbaan-cfrg-hpke-xyber768d00-02]
Westerbaan, B. and C. A. Wood, "X25519Kyber768Draft00
hybrid post-quantum KEM for HPKE", Work in Progress,
Internet-Draft, draft-westerbaan-cfrg-hpke-xyber768d00-02,
4 May 2023, <https://datatracker.ietf.org/doc/html/draft-
westerbaan-cfrg-hpke-xyber768d00-02>.
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
Use of Transport Layer Security (TLS) for Email Submission
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
<https://www.rfc-editor.org/rfc/rfc8314>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>.
Reddy Expires 3 September 2024 [Page 16]
Internet-Draft PQC Recommendations for Applications March 2024
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/rfc/rfc9364>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.
[SP-800-56C]
"Recommendation for Key-Derivation Methods in Key-
Establishment Schemes",
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Cr2.pdf>.
Author's Address
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Email: kondtir@gmail.com
Reddy Expires 3 September 2024 [Page 17]
