idnits 2.17.1 draft-kampanakis-tls-scas-latest-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 March 2022) is 777 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-tls-tlsflags-08 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-03 == Outdated reference: A later version (-10) exists of draft-ietf-tls-ctls-04 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-14 == Outdated reference: A later version (-10) exists of draft-ietf-tls-hybrid-design-04 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track P. Kampanakis 5 Expires: 5 September 2022 C. Bytheway 6 AWS 7 B.E. Westerbaan 8 Cloudflare 9 4 March 2022 11 Suppressing CA Certificates in TLS 1.3 12 draft-kampanakis-tls-scas-latest-01 14 Abstract 16 A TLS client or server that has access to the complete set of 17 published intermediate certificates can inform its peer to avoid 18 sending certificate authority certificates, thus reducing the size of 19 the TLS handshake. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 5 September 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 56 3. Suppress CA Certificates Flag . . . . . . . . . . . . . . . . 4 57 3.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Server (mutual TLS authentication) . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 6.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 The most data heavy part of a TLS handshake is authentication. It 69 usually consists of a signature, an end-entity certificate and 70 Certificate Authority (CA) certificates used to authenticate the end- 71 entity to a trusted root CA. These chains can sometime add to a few 72 kB of data which could be problematic for some usecases. 73 [EAPTLSCERT] and [EAP-TLS13] discuss the issues big certificate 74 chains in EAP authentication. Additionally, it is known that IEEE 75 802.15.4 [IEEE802154] mesh networks and Wi-SUN [WISUN] Field Area 76 Networks often notice significant delays due to EAP-TLS 77 authentication in constrained bandwidth mediums. 79 To alleviate the data exchanged in TLS [RFC8879] shrinks certificates 80 by compressing them. [CBOR-CERTS] uses different certificate 81 encodings for constrained environments. On the other hand, [CTLS] 82 proposes the use of certificate dictionaries to omit sending CA 83 certificates in a Compact TLS handshake. 85 In a post-quantum context 86 [I-D.hoffman-c2pq][NIST_PQ][I-D.ietf-tls-hybrid-design], the TLS 87 authentication data issue is exacerbated. 88 [CONEXT-PQTLS13SSH][NDSS-PQTLS13] show that post-quantum certificate 89 chains exceeding the initial TCP congestion window (10MSS [RFC6928]) 90 will slow down the handshake due to the extra round-trips they 91 introduce. [PQTLS] shows that big certificate chains (even smaller 92 than the initial TCP congestion window) will slow down the handshake 93 in lossy environments. [TLS-SUPPRESS] quantifies the post-quantum 94 authentication data in QUIC and TLS and shows that even the leanest 95 post-quantum signature algorithms will impact QUIC and TLS. 96 [CL-BLOG] also shows that 9-10 kilobyte certificate chains (even with 97 30MSS initial TCP congestion window) will lead to double digit TLS 98 handshake slowdowns. What's more, it shows that some clients or 99 middleboxes cannot handle chains larger than 10kB. 101 Mechanisms like [RFC8879][CBOR-CERTS] would not alleviate the issue 102 with post-quantum certificates as the bulk of the certificate size is 103 in the post-quantum public key or signature which is incompressible. 105 Thus, this document introduces a backwards-compatible mechanism to 106 shrink the certificate data exchanged in TLS 1.3. In some uses of 107 public key infrastructure (PKI), intermediate CA certificates sign 108 end-entity certificates. In the web PKI, clients require that 109 certificate authorities disclose all intermediate certificates that 110 they create. Although the set of intermediate certificates is large, 111 the size is bounded. Additionally, in some usecases the set of 112 communicating peers is limited. 114 For a client or server that has the necessary intermediates, 115 receiving them during the TLS handshake, increases the data 116 transmission unnecessarily. This document defines a signal that a 117 client or server can send to inform its peer that it already has the 118 intermediate CA certificates. A peer that receives this signal can 119 limit the certificate chain it sends to just the end-entity 120 certificate, saving on handshake size. 122 This mechanism is intended to be complementary with certificate 123 compression [RFC8879] in that it further reduces the size of the 124 handshake especially for post-quantum certificates. 126 It is worth noting that [RFC7924] attempted to address the issue by 127 omitting all certificates in the handshake if the client or server 128 had cached the peer certificate. This standard has not seen wide 129 adoption and could allow for TLS session correlation. Additionally, 130 the short lifetime certificates used today and the large size of 131 peers in some usecases make the peer certificate cache update and 132 maintenance mechanism challenging -- not the least because of privacy 133 concerns. The mechanism proposed in this document is not susceptible 134 to these challenges. 136 2. Terms and Definitions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. Suppress CA Certificates Flag 146 The goal is when a client or server has the intermediate CAs to build 147 the certificate chain for the peer it is establishing a TLS 148 connection with, to signal to the peer to not send theese 149 certificates. TLS [RFC5246] [RFC8446] allow for the root CA 150 certificate to be omitted from the handshake under the assumption 151 that the remote peer already possesses it in order to validate its 152 peers. Thus, a client or server in possession of the CA certificates 153 would only need the peer end-entity certificate to validate its 154 identity which would alleviate the data flowing in TLS. 156 It is beyond the scope of this document to define how CA certificates 157 are identified and stored. In some usecases [ICA-PRELOAD] the peer 158 may assume that all intermediates are available locally. In other 159 usecases where not all CA certificates can be stored, there may be 160 intermediate CA certificate caching and updating mechanisms. Some 161 options for such mechanisms are discussed in [TLS-SUPPRESS]. 163 [EDNOTE: One additional option could be to use a TLS extension like 164 the one defined in [RFC7924] to include the chain fingerprint so the 165 peer can confirm that he does not need to send the chain because the 166 peer asking for suppression has the correct chain to validate the 167 server. That could prevent inadvertent mistakes where the client 168 thinks it has the intermediates to validate the server, but what it 169 has is wrong. The shortcoming is that could be used as a cookie. 170 Alternatively we could HMAC the chain to make it indistinguisable. 171 Another option is for the server to provide a ticket so client 172 returning visits tell the server that the client has the ICAs and it 173 does not need to send them. These options require further evaluation 174 only if we think that they are worth the effort.] 176 The 0xTBD1 flag used below to signal ICA suppression can only be sent 177 in a ClientHello or CertificateRequest message as defined below. 178 Endpoints that receive a 0xTBD1 flag with a value of 1 in any other 179 handshake message MUST generate a fatal illegal_parameter alert. 181 3.1. Client 183 A client that believes that it has a current, complete set of 184 intermediate certificates to authenticate the server sends the 185 tls_flags extension [TLS-FLAGS] with the 0xTBD1 flag set to 1 in its 186 ClientHello message. 188 To prevent a failed TLS connection, a client MAY choose not to send 189 the flag if its list of ICAs hasn't been updated in TBD3 time or has 190 any other reason to believe it does not include the ICAs for its 191 peer. 193 A server that receives a value of 1 in the 0xTBD1 flag of a 194 ClientHello message SHOULD omit all certificates other than the end- 195 entity certificate from its Certificate message that it sends in 196 response. Otherwise if it does not support CA certificate 197 suppression, the server SHOULD ignore the 0xTBD1 flag. 199 To prevent a failed TLS connection, a server could choose to send its 200 intermediates regardless of the flag from the client, if it has a 201 reason to believe the issuing CAs do not exist in the client ICA 202 list. 204 If the connection still fails because the client cannot build the 205 certificate chain to authenticate the server, the client MUST NOT 206 send the flag in a subsequent connection to the server. 208 3.2. Server (mutual TLS authentication) 210 In a mutual TLS authentication scenario, a server that believes that 211 it has a current, complete set of intermediate certificates to 212 authenticate the client, sends the tls_flags extension [TLS-FLAGS] 213 with the 0xTBD1 flag set to 1 in its CertificateRequest message. 215 To prevent a failed TLS connection, a server MAY choose not to send 216 the flag if its list of ICAs hasn't been updated in TBD3 time or has 217 any other reason to believe it does not include the ICAs for its 218 peer. 220 A client that receives a value of 1 in the 0xTBD1 flag in a 221 CertificateRequest message SHOULD omit all certificates other than 222 the end-entity certificate from the Certificate message that it sends 223 in response. Otherwise if it does not support CA certificate 224 suppression, the client SHOULD ignore the 0xTBD flag. 226 To prevent a failed TLS connection, a client could choose to send its 227 intermediates regardless of the flag from the server, if it has a 228 reason to believe the issuing CAs do not exist in the server ICA 229 list. 231 If the connection still fails because the server cannot build the 232 certificate chain to authenticate the client, the server MUST NOT 233 send the flag in a subsequent connection from the client. [EDNOTE: 234 There is a challenge with this in that the server needs to keep track 235 of failed client connections.] 237 4. Security Considerations 239 This document creates an unencrypted signal in the ClientHello that 240 might be used to identify which clients believe that they have 241 intermediates to build the certificate chain for their peer. 242 Although it does not reveal any additional information about the 243 peers, it might allow clients to be more effectively fingerprinted by 244 peers or any passive observers in the network path. A mitigation 245 against this concern is to encrypt the ClientHello in TLS 1.3 [ESNI] 246 which would hide the CA certificate suppression signal. 248 Even when the 0xTBD1 flag is encrypted in the handshake, a passive 249 observer could fingerprint the peers by analyzing the TLS handshake 250 data sizes flowing each direction. Widespread adoption of the TLS 251 suppression mechanism described in this document will deem the use of 252 the signal for fingerprinting impractical. 254 5. IANA Considerations 256 This document registers the 0xTBD1 in the registry created by 257 [TLS-FLAGS]. 259 6. References 261 6.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 270 May 2017, . 272 [TLS-FLAGS] 273 Nir, Y., "A Flags Extension for TLS 1.3", Work in 274 Progress, Internet-Draft, draft-ietf-tls-tlsflags-08, 11 275 January 2022, . 278 6.2. Informative References 280 [CBOR-CERTS] 281 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 282 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 283 Certificates)", Work in Progress, Internet-Draft, draft- 284 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 285 . 288 [CL-BLOG] Westerbaan, B.E., "Sizing Up Post-Quantum Signatures", 289 November 2021, . 292 [CONEXT-PQTLS13SSH] 293 Sikeridis, D., Kampanakis, P., and M. Devetsikiotis, 294 "Assessing the Overhead of Post-Quantum Cryptography in 295 TLS 1.3 and SSH", DOI 10.1145/3386367.3431305, 296 ISBN 9781450379489, November 2020, 297 . 299 [CTLS] Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 300 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 301 ctls-04, 25 October 2021, 302 . 305 [EAP-TLS13] 306 Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3 307 (EAP-TLS 1.3)", Work in Progress, Internet-Draft, draft- 308 ietf-emu-eap-tls13-21, 20 October 2021, 309 . 312 [EAPTLSCERT] 313 Sethi, M., Mattsson, J., and S. Turner, "Handling Large 314 Certificates and Long Certificate Chains in TLS-Based EAP 315 Methods", Work in Progress, Internet-Draft, draft-ietf- 316 emu-eaptlscert-08, 20 November 2020, 317 . 320 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 321 Encrypted Client Hello", Work in Progress, Internet-Draft, 322 draft-ietf-tls-esni-14, 13 February 2022, 323 . 326 [I-D.hoffman-c2pq] 327 Hoffman, P., "The Transition from Classical to Post- 328 Quantum Cryptography", Work in Progress, Internet-Draft, 329 draft-hoffman-c2pq-07, 26 May 2020, 330 . 333 [I-D.ietf-tls-hybrid-design] 334 Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key 335 exchange in TLS 1.3", Work in Progress, Internet-Draft, 336 draft-ietf-tls-hybrid-design-04, 11 January 2022, 337 . 340 [ICA-PRELOAD] 341 Keeler, D., "Preloading Intermediate CA Certificates into 342 Firefox", November 2020, 343 . 346 [IEEE802154] 347 "IEEE Standard for Low-Rate Wireless Networks", 348 DOI 10.1109/IEEESTD.2020.9144691, July 2020, 349 . 351 [NDSS-PQTLS13] 352 Sikeridis, D., Kampanakis, P., and M. Devetsikiotis, 353 "Post-Quantum Authentication in TLS 1.3: A Performance 354 Study", DOI 10.14722/ndss.2020.24203, February 2020, 355 . 357 [NIST_PQ] NIST, ., "Post-Quantum Cryptography", 2021, 358 . 361 [PQTLS] Paquin, C., Stebila, D., and G. Tamvada, "Benchmarking 362 Post-Quantum Cryptography in TLS", 2019, 363 . 365 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 366 (TLS) Protocol Version 1.2", RFC 5246, 367 DOI 10.17487/RFC5246, August 2008, 368 . 370 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 371 "Increasing TCP's Initial Window", RFC 6928, 372 DOI 10.17487/RFC6928, April 2013, 373 . 375 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 376 (TLS) Cached Information Extension", RFC 7924, 377 DOI 10.17487/RFC7924, July 2016, 378 . 380 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 381 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 382 . 384 [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate 385 Compression", RFC 8879, DOI 10.17487/RFC8879, December 386 2020, . 388 [TLS-SUPPRESS] 389 Kampanakis, P. and M. Kallitsis, "Speeding up post-quantum 390 TLS handshakes by suppressing intermediate CA 391 certificates", 2021, 392 . 396 [WISUN] "WI-SUN Alliance", n.d., . 398 Authors' Addresses 400 Martin Thomson 401 Mozilla 402 Email: mt@lowentropy.net 404 Panos Kampanakis 405 AWS 406 Email: kpanos@amazon.com 408 Cameron Bytheway 409 AWS 410 Email: bythewc@amazon.com 411 Bas Westerbaan 412 Cloudflare 413 Email: bas@cloudflare.com