Suppressing CA Certificates in TLS 1.3
Martin Thomson
Mozilla
mt@lowentropy.net
Panos Kampanakis
AWS
kpanos@amazon.com
Cameron Bytheway
AWS
bythewc@amazon.com
Bas Westerbaan
Cloudflare
bas@cloudflare.com
08 July 2022
Transport
TLS
A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake.

Introduction
The most data heavy part of a TLS handshake is authentication. It usually consists of a signature, an end-entity certificate and Certificate Authority (CA) certificates used to authenticate the end-entity to a trusted root CA. These chains can sometime add to a few kB of data which could be problematic for some use cases. [EAPTLSCERT] and [EAP-TLS13] discuss the issues big certificate chains in EAP authentication. Additionally, it is known that IEEE 802.15.4 [IEEE802154] mesh networks and Wi-SUN [WISUN] Field Area Networks often notice significant delays due to EAP-TLS authentication in constrained bandwidth mediums.
To alleviate the data exchanged in TLS [RFC8879] shrinks certificates by compressing them. [CBOR-CERTS] uses different certificate encodings for constrained environments. On the other hand, [CTLS] proposes the use of certificate dictionaries to omit sending CA certificates in a Compact TLS handshake.
In a post-quantum context [I-D.hoffman-c2pq][NIST_PQ][I-D.ietf-tls-hybrid-design], the TLS authentication data issue is exacerbated. [CONEXT-PQTLS13SSH][NDSS-PQTLS13] show that post-quantum certificate chains exceeding the initial TCP congestion window (10MSS [RFC6928]) will slow down the handshake due to the extra round-trips they introduce. [PQTLS] shows that big certificate chains (even smaller than the initial TCP congestion window) will slow down the handshake in lossy environments. [TLS-SUPPRESS] quantifies the post-quantum authentication data in QUIC and TLS and shows that even the leanest post-quantum signature algorithms will impact QUIC and TLS. [CL-BLOG] also shows that 9-10 kilobyte certificate chains (even with 30MSS initial TCP congestion window) will lead to double digit TLS handshake slowdowns. What’s more, it shows that some clients or middleboxes cannot handle chains larger than 10kB.
Mechanisms like [RFC8879][CBOR-CERTS] would not alleviate the issue with post-quantum certificates as the bulk of the certificate size is in the post-quantum public key or signature which is incompressible.
Thus, this document introduces a backwards-compatible mechanism to shrink the certificate data exchanged in TLS 1.3. In some uses of public key infrastructure (PKI), intermediate CA certificates sign end-entity certificates. In the web PKI, clients require that certificate authorities disclose all intermediate certificates that they create. Although the set of intermediate certificates is large, the size is bounded. Additionally, in some use cases the set of communicating peers is limited.
For a client or server that has the necessary intermediates, receiving them during the TLS handshake, increases the data transmission unnecessarily. This document defines a signal that a client or server can send to inform its peer that it already has the intermediate CA certificates. A peer that receives this signal can limit the certificate chain it sends to just the end-entity certificate, saving on handshake size.
This mechanism is intended to be complementary with certificate compression [RFC8879] in that it further reduces the size of the handshake especially for post-quantum certificates.
It is worth noting that [RFC7924] attempted to address the issue by omitting all certificates in the handshake if the client or server had cached the peer certificate. This standard has not seen wide adoption and could allow for TLS session correlation. Additionally, the short lifetime certificates used today and the large size of peers in some use cases make the peer certificate cache update and maintenance mechanism challenging — not the least because of privacy concerns. The mechanism proposed in this document is not susceptible to these challenges.

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

Suppress CA Certificates Flag
The goal is when a client or server has the intermediate CAs to build the certificate chain for the peer it is establishing a TLS connection with, to signal to the peer to not send these certificates. TLS [RFC5246] [RFC8446] allows for the root CA certificate to be omitted from the handshake under the assumption that the remote peer already possesses it in order to validate its peers. Thus, a client or server in possession of the CA certificates would only need the peer end-entity certificate to validate its identity which would alleviate the data flowing in TLS.
This draft assumes that the endpoint can keep as set of ICAs in memory to use them while building certificate chains to authenticate a peer. Most usually the set will be stored locally in non-volatile memory. In constrained devices the intermediates could be cached, kept and updated only in volatile memory especially when the communicating peers’ PKI domains are limited.
How CA certificates are identified and stored is dependent on the use case. In some use cases (e.g. WebPKI [ICA-PRELOAD]) the peer may assume that all intermediates are assembled, distributed and updated regularly using an out-of-band mechanism. In other use cases when the communicating peers’ PKI domains are limited and not all CA certificates can be stored (i.e., constrained devices), or distributed, intermediates could be cached and updated dynamically using a caching mechanism. Such mechanisms are discussed in [TLS-SUPPRESS].
Although this document uses mechanisms to minimize TLS authentication failures due to stale or incomplete ICA lists, an endpoint is expected to re-attempt a TLS connection if it failed to authenticate a peer certificate after requesting ICA suppression. [EDNOTE: draft-ietf-tls-esni already requires the client to retry a connection when ECH is “securely replaced by the server” or “securely disabled by the server”. ]
[EDNOTE: To prevent failuers, one additional option could be to use a TLS extension like the one defined in [RFC7924] to include the chain fingerprint so the peer can confirm that he does not need to send the chain because the peer asking for suppression has the correct chain to validate the server. That could prevent inadvertent mistakes where the client thinks it has the intermediates to validate the server, but what it has is wrong. The shortcoming is that could be used as a cookie. Alternatively we could HMAC the chain to make it indistinguisable. Another option is for the server to provide a ticket so client returning visits tell the server that the client has the ICAs and it does not need to send them. These options require further evaluation only if we think that the complexity is worth the benefit.]
The 0xTBD1 flag used to signal CA suppression can only be sent in a ClientHello or CertificateRequest message as defined below. Endpoints that receive a 0xTBD1 flag with a value of 1 in any other handshake message MUST generate a fatal illegal_parameter alert.

Client
A client that believes that it has a current, complete set of intermediate certificates to authenticate the server sends the tls_flags extension [TLS-FLAGS] with the 0xTBD1 flag set to 1 in its ClientHello message.
To prevent a failed TLS connection, a client MAY choose not to send the flag if its list of ICAs hasn’t been updated in TBD3 time or has any other reason to believe it does not include the ICAs for its peer.
A server that receives a value of 1 in the 0xTBD1 flag of a ClientHello message SHOULD omit all certificates other than the end-entity certificate from its Certificate message that it sends in response. Otherwise if it does not support CA certificate suppression, the server SHOULD ignore the 0xTBD1 flag.
To prevent a failed TLS connection, a server could choose to send its intermediates regardless of the flag from the client, if it has a reason to believe the issuing CAs do not exist in the client ICA list. For example, if the server’s certificate chain contains ICAs with technical constraints which are not disclosed, the server SHOULD send the chain back to the client regardless of the suppression flag in the ClientHello.
If the connection still fails because the client cannot build the certificate chain to authenticate the server, the client MUST NOT send the flag in a subsequent connection to the server.

Server (mutual TLS authentication)
In a mutual TLS authentication scenario, a server that believes that it has a current, complete set of intermediate certificates to authenticate the client, sends the tls_flags extension [TLS-FLAGS] with the 0xTBD1 flag set to 1 in its CertificateRequest message.
To prevent a failed TLS connection, a server MAY choose not to send the flag if its list of ICAs hasn’t been updated in TBD3 time or has any other reason to believe it does not include the ICAs for its peer.
A client that receives a value of 1 in the 0xTBD1 flag in a CertificateRequest message SHOULD omit all certificates other than the end-entity certificate from the Certificate message that it sends in response. Otherwise if it does not support CA certificate suppression, the client SHOULD ignore the 0xTBD flag.
To prevent a failed TLS connection, a client could choose to send its intermediates regardless of the flag from the server, if it has a reason to believe the issuing CAs do not exist in the server ICA list. For example, if the client’s certificate chain contains ICAs with technical constraints which are not disclosed, the client SHOULD send the chain back to the server regardless of the CA suppression flag in the CertificateRequest. [EDNOTE: MSRP 2.8 may require constrained intermediates which would mean this could change for WebPKI.]
If the connection still fails because the server cannot build the certificate chain to authenticate the client, the server MUST NOT send the flag in a subsequent connection from the client. [EDNOTE: There is a challenge with this in that the server needs to keep track of failed client connections.]

Security Considerations
This document creates an unencrypted signal in the ClientHello that might be used to identify which clients believe that they have intermediates to build the certificate chain for their peer. Although it does not reveal any additional information about the peers, it might allow clients to be more effectively fingerprinted by peers or any passive observers in the network path. A mitigation against this concern is to encrypt the ClientHello in TLS 1.3 [ESNI] which would hide the CA certificate suppression signal.
Even when the 0xTBD1 flag is encrypted in the handshake, a passive observer could fingerprint the peers by analyzing the TLS handshake data sizes flowing each direction. Widespread adoption of the TLS CA suppression mechanism described in this document will deem the use of the signal for fingerprinting impractical.

IANA Considerations
This document registers the 0xTBD1 in the registry created by [TLS-FLAGS].

Acknowledgements
We would like to thank Ilari Liusvaara, Ryan Sleevi Filippo Valsorda and for their valuable feedback contributions to this document.
The authors would also like to thank Filippo Valsorda for his feedback regarding ICA lists [FILOSOTTILE].

Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[TLS-FLAGS]

A Flags Extension for TLS 1.3
Yoav Nir
Dell Technologies
7 March 2022
Internet-Draft draft-ietf-tls-tlsflags-09

Informative References
[IEEE802154]

IEEE Standard for Low-Rate Wireless Networks
July 2020
DOI 10.1109/IEEESTD.2020.9144691
[WISUN]

WI-SUN Alliance
n.d.
[CL-BLOG]

Sizing Up Post-Quantum Signatures
Bas Westerbaan
November 2021
[CONEXT-PQTLS13SSH]

Assessing the Overhead of Post-Quantum Cryptography in TLS 1.3 and SSH
Dimitrios Sikeridis
Panos Kampanakis
Michael Devetsikiotis
November 2020
DOI 10.1145/3386367.3431305
ISBN 9781450379489
[NDSS-PQTLS13]

Post-Quantum Authentication in TLS 1.3: A Performance Study
Dimitrios Sikeridis
Panos Kampanakis
Michael Devetsikiotis
February 2020
DOI 10.14722/ndss.2020.24203
[PQTLS]

Benchmarking Post-Quantum Cryptography in TLS
Christian Paquin
Douglas Stebila
Goutam Tamvada
2019
[TLS-SUPPRESS]

Speeding up post-quantum TLS handshakes by suppressing intermediate CA certificates
Panos Kampanakis
Michael Kallitsis
2021
[ICA-PRELOAD]

Preloading Intermediate CA Certificates into Firefox
Dana Keeler
November 2020
[NIST_PQ]

Post-Quantum Cryptography
National Institute of Standards and Technology
2021
[FILOSOTTILE]

filippo.io/intermediates
Filippo Valsorda
2022
[EAPTLSCERT]

Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods
Mohit Sethi
Ericsson
John Mattsson
Ericsson
Sean Turner
sn3rd
20 November 2020
Internet-Draft draft-ietf-emu-eaptlscert-08
[EAP-TLS13]

Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)
John Mattsson
Mohit Sethi
20 October 2021
Internet-Draft draft-ietf-emu-eap-tls13-21
[RFC8879]

TLS Certificate Compression
A. Ghedini
V. Vasiliev
December 2020
RFC 8879
DOI 10.17487/RFC8879
[CBOR-CERTS]

CBOR Encoded X.509 Certificates (C509 Certificates)
John Preuß Mattsson
Ericsson AB
Göran Selander
Ericsson AB
Shahid Raza
RISE AB
Joel Höglund
RISE AB
Martin Furuhed
Nexus Group
10 January 2022
Internet-Draft draft-ietf-cose-cbor-encoded-cert-03
[CTLS]

Compact TLS 1.3
Eric Rescorla
Mozilla
Richard Barnes
Cisco
Hannes Tschofenig
Arm Limited
7 March 2022
Internet-Draft draft-ietf-tls-ctls-05
[I-D.hoffman-c2pq]

The Transition from Classical to Post-Quantum Cryptography
Paul Hoffman
ICANN
26 May 2020
Internet-Draft draft-hoffman-c2pq-07
[I-D.ietf-tls-hybrid-design]

Hybrid key exchange in TLS 1.3
Douglas Stebila
University of Waterloo
Scott Fluhrer
Cisco Systems
Shay Gueron
University of Haifa and Amazon Web Services
11 January 2022
Internet-Draft draft-ietf-tls-hybrid-design-04
[RFC6928]

Increasing TCP's Initial Window
J. Chu
N. Dukkipati
Y. Cheng
M. Mathis
April 2013
RFC 6928
DOI 10.17487/RFC6928
[RFC7924]

Transport Layer Security (TLS) Cached Information Extension
S. Santesson
H. Tschofenig
July 2016
RFC 7924
DOI 10.17487/RFC7924
[RFC5246]

The Transport Layer Security (TLS) Protocol Version 1.2
T. Dierks
E. Rescorla
August 2008
RFC 5246
DOI 10.17487/RFC5246
[RFC8446]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[ESNI]

TLS Encrypted Client Hello
Eric Rescorla
RTFM, Inc.
Kazuho Oku
Fastly
Nick Sullivan
Cloudflare
Christopher A. Wood
Cloudflare
13 February 2022
Internet-Draft draft-ietf-tls-esni-14