TLS                                                           M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                           P. Kampanakis
Expires: 5 September 2022                                    C. Bytheway
                                                                     AWS
                                                         B.E. Westerbaan
                                                              Cloudflare
                                                            4 March 2022


                 Suppressing CA Certificates in TLS 1.3
                  draft-kampanakis-tls-scas-latest-01

Abstract

   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.

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 5 September 2022.

Copyright Notice

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










Thomson, et al.         Expires 5 September 2022                [Page 1]


Internet-Draft                Suppress CAs                    March 2022


   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.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   4
   3.  Suppress CA Certificates Flag . . . . . . . . . . . . . . . .   4
     3.1.  Client  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Server (mutual TLS authentication)  . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  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 usecases.
   [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



Thomson, et al.         Expires 5 September 2022                [Page 2]


Internet-Draft                Suppress CAs                    March 2022


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







Thomson, et al.         Expires 5 September 2022                [Page 3]


Internet-Draft                Suppress CAs                    March 2022


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

3.  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 theese
   certificates.  TLS [RFC5246] [RFC8446] allow 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.

   It is beyond the scope of this document to define how CA certificates
   are identified and stored.  In some usecases [ICA-PRELOAD] the peer
   may assume that all intermediates are available locally.  In other
   usecases where not all CA certificates can be stored, there may be
   intermediate CA certificate caching and updating mechanisms.  Some
   options for such mechanisms are discussed in [TLS-SUPPRESS].

   [EDNOTE: 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 they are worth the effort.]

   The 0xTBD1 flag used below to signal ICA 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.







Thomson, et al.         Expires 5 September 2022                [Page 4]


Internet-Draft                Suppress CAs                    March 2022


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

   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.

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







Thomson, et al.         Expires 5 September 2022                [Page 5]


Internet-Draft                Suppress CAs                    March 2022


   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.

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

4.  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
   suppression mechanism described in this document will deem the use of
   the signal for fingerprinting impractical.

5.  IANA Considerations

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

6.  References

6.1.  Normative References

   [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/info/rfc2119>.

   [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/info/rfc8174>.






Thomson, et al.         Expires 5 September 2022                [Page 6]


Internet-Draft                Suppress CAs                    March 2022


   [TLS-FLAGS]
              Nir, Y., "A Flags Extension for TLS 1.3", Work in
              Progress, Internet-Draft, draft-ietf-tls-tlsflags-08, 11
              January 2022, <https://www.ietf.org/archive/id/draft-ietf-
              tls-tlsflags-08.txt>.

6.2.  Informative References

   [CBOR-CERTS]
              Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
              M. Furuhed, "CBOR Encoded X.509 Certificates (C509
              Certificates)", Work in Progress, Internet-Draft, draft-
              ietf-cose-cbor-encoded-cert-03, 10 January 2022,
              <https://www.ietf.org/archive/id/draft-ietf-cose-cbor-
              encoded-cert-03.txt>.

   [CL-BLOG]  Westerbaan, B.E., "Sizing Up Post-Quantum Signatures",
              November 2021, <https://blog.cloudflare.com/sizing-up-
              post-quantum-signatures/>.

   [CONEXT-PQTLS13SSH]
              Sikeridis, D., Kampanakis, P., and M. Devetsikiotis,
              "Assessing the Overhead of Post-Quantum Cryptography in
              TLS 1.3 and SSH", DOI 10.1145/3386367.3431305,
              ISBN 9781450379489, November 2020,
              <https://doi.org/10.1145/3386367.3431305>.

   [CTLS]     Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
              1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
              ctls-04, 25 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-tls-ctls-
              04.txt>.

   [EAP-TLS13]
              Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3
              (EAP-TLS 1.3)", Work in Progress, Internet-Draft, draft-
              ietf-emu-eap-tls13-21, 20 October 2021,
              <https://www.ietf.org/internet-drafts/draft-ietf-emu-eap-
              tls13-21.txt>.

   [EAPTLSCERT]
              Sethi, M., Mattsson, J., and S. Turner, "Handling Large
              Certificates and Long Certificate Chains in TLS-Based EAP
              Methods", Work in Progress, Internet-Draft, draft-ietf-
              emu-eaptlscert-08, 20 November 2020,
              <https://www.ietf.org/archive/id/draft-ietf-emu-
              eaptlscert-08.txt>.




Thomson, et al.         Expires 5 September 2022                [Page 7]


Internet-Draft                Suppress CAs                    March 2022


   [ESNI]     Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-14, 13 February 2022,
              <https://www.ietf.org/archive/id/draft-ietf-tls-esni-
              14.txt>.

   [I-D.hoffman-c2pq]
              Hoffman, P., "The Transition from Classical to Post-
              Quantum Cryptography", Work in Progress, Internet-Draft,
              draft-hoffman-c2pq-07, 26 May 2020,
              <https://www.ietf.org/archive/id/draft-hoffman-c2pq-
              07.txt>.

   [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-04, 11 January 2022,
              <https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-
              design-04.txt>.

   [ICA-PRELOAD]
              Keeler, D., "Preloading Intermediate CA Certificates into
              Firefox", November 2020,
              <https://blog.mozilla.org/security/2020/11/13/preloading-
              intermediate-ca-certificates-into-firefox/>.

   [IEEE802154]
              "IEEE Standard for Low-Rate Wireless Networks",
              DOI 10.1109/IEEESTD.2020.9144691, July 2020,
              <https://doi.org/10.1109/IEEESTD.2020.9144691>.

   [NDSS-PQTLS13]
              Sikeridis, D., Kampanakis, P., and M. Devetsikiotis,
              "Post-Quantum Authentication in TLS 1.3: A Performance
              Study", DOI 10.14722/ndss.2020.24203, February 2020,
              <https://doi.org/10.14722/ndss.2020.24203>.

   [NIST_PQ]  NIST, ., "Post-Quantum Cryptography", 2021,
              <https://csrc.nist.gov/projects/post-quantum-
              cryptography>.

   [PQTLS]    Paquin, C., Stebila, D., and G. Tamvada, "Benchmarking
              Post-Quantum Cryptography in TLS", 2019,
              <https://ia.cr/2019/1447>.







Thomson, et al.         Expires 5 September 2022                [Page 8]


Internet-Draft                Suppress CAs                    March 2022


   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
              "Increasing TCP's Initial Window", RFC 6928,
              DOI 10.17487/RFC6928, April 2013,
              <https://www.rfc-editor.org/info/rfc6928>.

   [RFC7924]  Santesson, S. and H. Tschofenig, "Transport Layer Security
              (TLS) Cached Information Extension", RFC 7924,
              DOI 10.17487/RFC7924, July 2016,
              <https://www.rfc-editor.org/info/rfc7924>.

   [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/info/rfc8446>.

   [RFC8879]  Ghedini, A. and V. Vasiliev, "TLS Certificate
              Compression", RFC 8879, DOI 10.17487/RFC8879, December
              2020, <https://www.rfc-editor.org/info/rfc8879>.

   [TLS-SUPPRESS]
              Kampanakis, P. and M. Kallitsis, "Speeding up post-quantum
              TLS handshakes by suppressing intermediate CA
              certificates", 2021,
              <https://www.amazon.science/publications/speeding-up-post-
              quantum-tls-handshakes-by-suppressing-intermediate-ca-
              certificates>.

   [WISUN]    "WI-SUN Alliance", n.d., <https://wi-sun.org/>.

Authors' Addresses

   Martin Thomson
   Mozilla
   Email: mt@lowentropy.net


   Panos Kampanakis
   AWS
   Email: kpanos@amazon.com


   Cameron Bytheway
   AWS
   Email: bythewc@amazon.com



Thomson, et al.         Expires 5 September 2022                [Page 9]


Internet-Draft                Suppress CAs                    March 2022


   Bas Westerbaan
   Cloudflare
   Email: bas@cloudflare.com
















































Thomson, et al.         Expires 5 September 2022               [Page 10]