Mozilla

mt@lowentropy.net

AWS

kpanos@amazon.com

AWS

bythewc@amazon.com

Cloudflare

bas@cloudflare.com

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.

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. and discuss the issues big certificate chains in EAP authentication. Additionally, it is known that IEEE 802.15.4 mesh networks and Wi-SUN Field Area Networks often notice significant delays due to EAP-TLS authentication in constrained bandwidth mediums. To alleviate the data exchanged in TLS shrinks certificates by compressing them. uses different certificate encodings for constrained environments. On the other hand, proposes the use of certificate dictionaries to omit sending CA certificates in a Compact TLS handshake. In a post-quantum context , the TLS authentication data issue is exacerbated. show that post-quantum certificate chains exceeding the initial TCP congestion window (10MSS ) will slow down the handshake due to the extra round-trips they introduce. shows that big certificate chains (even smaller than the initial TCP congestion window) will slow down the handshake in lossy environments. 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. 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 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 in that it further reduces the size of the handshake especially for post-quantum certificates. It is worth noting that 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.

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.

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

A client that believes that it has a current, complete set of intermediate certificates to authenticate the server sends the tls_flags extension 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.

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

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

This document registers the 0xTBD1 in the registry created by .

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 .

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Dell Technologies A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. Ericsson Ericsson sn3rd The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem. This document looks at this problem in detail and describes the potential solutions available. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-Transport Layer Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking, when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. In TLS handshakes, certificate chains often take up the majority of the bytes transmitted.This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format. Mozilla Cisco Arm Limited This document specifies a "compact" version of TLS 1.3. It is isomorphic to TLS 1.3 but saves space by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3, but it should eventually be possible for a cTLS/TLS 1.3 server to exist and successfully interoperate. ICANN Quantum computing is the study of computers that use quantum features in calculations. For over 20 years, it has been known that if very large, specialized quantum computers could be built, they could have a devastating effect on asymmetric classical cryptographic algorithms such as RSA and elliptic curve signatures and key exchange, as well as (but in smaller scale) on symmetric cryptographic algorithms such as block ciphers, MACs, and hash functions. There has already been a great deal of study on how to create algorithms that will resist large, specialized quantum computers, but so far, the properties of those algorithms make them onerous to adopt before they are needed. Small quantum computers are being built today, but it is still far from clear when large, specialized quantum computers will be built that can recover private or secret keys in classical algorithms at the key sizes commonly used today. It is important to be able to predict when large, specialized quantum computers usable for cryptanalysis will be possible so that organization can change to post-quantum cryptographic algorithms well before they are needed. This document describes quantum computing, how it might be used to attack classical cryptographic algorithms, and possibly how to predict when large, specialized quantum computers will become feasible. University of Waterloo Cisco Systems University of Haifa and Amazon Web Services Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. RTFM, Inc. Fastly Cloudflare Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni).