idnits 2.17.1 draft-ietf-tls-cert-abridge-02.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 are 6 instances 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 (16 September 2024) is 439 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-tls-esni-17 == Outdated reference: A later version (-15) exists of draft-ietf-cose-cbor-encoded-cert-05 == Outdated reference: A later version (-10) exists of draft-ietf-tls-ctls-08 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security D. Jackson 3 Internet-Draft Mozilla 4 Intended status: Experimental 16 September 2024 5 Expires: 20 March 2025 7 Abridged Compression for WebPKI Certificates 8 draft-ietf-tls-cert-abridge-02 10 Abstract 12 This draft defines a new TLS Certificate Compression scheme which 13 uses a shared dictionary of root and intermediate WebPKI 14 certificates. The scheme smooths the transition to post-quantum 15 certificates by eliminating the root and intermediate certificates 16 from the TLS certificate chain without impacting trust negotiation. 17 It also delivers better compression than alternative proposals whilst 18 ensuring fair treatment for both CAs and website operators. It may 19 also be useful in other applications which store certificate chains, 20 e.g. Certificate Transparency logs. 22 About This Document 24 This note is to be removed before publishing as an RFC. 26 The latest revision of this draft can be found at 27 https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls- 28 cert-abridge.html. Status information for this document may be found 29 at https://datatracker.ietf.org/doc/draft-ietf-tls-cert-abridge/. 31 Discussion of this document takes place on the Transport Layer 32 Security Working Group mailing list (mailto:tls@ietf.org), which is 33 archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe 34 at https://www.ietf.org/mailman/listinfo/tls/. 36 Source for this draft and an issue tracker can be found at 37 https://github.com/tlswg/draft-ietf-tls-cert-abridge. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 20 March 2025. 56 Copyright Notice 58 Copyright (c) 2024 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.3. Relationship to other drafts . . . . . . . . . . . . . . 4 76 1.4. Status . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 78 3. Abridged Compression Scheme . . . . . . . . . . . . . . . . 6 79 3.1. Pass 1: Intermediate and Root Compression . . . . . . . . 6 80 3.1.1. Enumeration of Known Intermediate and Root 81 Certificates . . . . . . . . . . . . . . . . . . . . 6 82 3.1.2. Compression of CA Certificates in Certificate 83 Chain . . . . . . . . . . . . . . . . . . . . . . . . 8 84 3.2. Pass 2: End-Entity Compression . . . . . . . . . . . . . 9 85 3.2.1. Construction of Shared Dictionary . . . . . . . . . . 9 86 4. Preliminary Evaluation . . . . . . . . . . . . . . . . . . . 11 87 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 88 5.1. Dictionary Versioning . . . . . . . . . . . . . . . . . . 12 89 5.2. Version Migration . . . . . . . . . . . . . . . . . . . . 13 90 5.3. Disk Space Requirements . . . . . . . . . . . . . . . . . 14 91 5.4. Implementation Complexity . . . . . . . . . . . . . . . . 14 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 97 9.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19 99 Appendix B. CCADB Churn and Dictionary Negotiation . . . . . . . 19 100 B.1. CCADB Churn . . . . . . . . . . . . . . . . . . . . . . . 19 101 B.2. Dictionary Negotiation . . . . . . . . . . . . . . . . . 20 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 1.1. Motivation 108 When a server responds to a TLS Client Hello, the size of its initial 109 flight of packets is limited by the underlying transport protocol. 110 If the size limit is exceeded, the server must wait for the client to 111 acknowledge receipt before concluding the flight, incurring the 112 additional latency of a round trip before the handshake can complete. 113 For TLS handshakes over TCP, the size limit is typically around 114 14,500 bytes. For TLS handshakes in QUIC, the limit is much lower at 115 a maximum of 4500 bytes ([RFC9000], Section 8.1). 117 The existing compression schemes used in [TLSCertCompress] have been 118 shown to deliver a substantial improvement in QUIC handshake latency 119 [FastlyStudy], [QUICStudy] by reducing the size of server's 120 certificate chain and so fitting the server's initial messages within 121 a single flight. However, in a post-quantum setting, the signatures 122 and public keys used in a TLS certificate chain will be typically 10 123 to 40 times their current size and cannot be compressed with existing 124 TLS Certificate Compression schemes because most of the size of the 125 certificate is in high entropy fields such as cryptographic keys and 126 signatures. 128 Consequently studies [SCAStudy] [PQStudy] have shown that post- 129 quantum certificate transmission becomes the dominant source of 130 latency in PQ TLS with certificate chains alone expected to exceed 131 even the TCP initial flight limit. This motivates alternative 132 designs for reducing the wire size of post-quantum certificate 133 chains. 135 1.2. Overview 137 This draft introduces a new TLS certificate compression scheme which 138 is intended specifically for WebPKI applications and is negotiated 139 using the existing certificate compression extension described in 140 [TLSCertCompress]. It uses a predistributed dictionary consisting of 141 all intermediate and root certificates contained in the root stores 142 of major browsers which is sourced from the Common CA Database 143 [CCADB]. As of May 2023, this dictionary would be 3 MB in size and 144 consist of roughly 2000 intermediate certificates and 200 root 145 certificates. The disk footprint can be reduced to near zero as many 146 clients (such as Mozilla Firefox & Google Chrome) are already 147 provisioned with their trusted intermediate and root certificates for 148 compatibility and performance reasons. 150 Using a shared dictionary allows for this compression scheme to 151 deliver dramatically more effective compression than previous 152 schemes, reducing the size of certificate chains in use today by 153 ~75%, significantly improving on the ~25% reduction achieved by 154 existing schemes. A preliminary evaluation (Section 4) of this 155 scheme suggests that 50% of certificate chains in use today would be 156 compressed to under 1000 bytes and 95% to under 1500 bytes. 157 Similarly to [SCA], this scheme effectively removes the CA 158 certificates from the certificate chain on the wire but this draft 159 achieves a much better compression ratio, since [SCA] removes the 160 redundant information in chain that existing TLS Certificate 161 Compression schemes exploit and is more fragile in the presence of 162 out of sync clients or servers. 164 Note that as this is only a compression scheme, it does not impact 165 any trust decisions in the TLS handshake. A client can offer this 166 compression scheme whilst only trusting a subset of the certificates 167 in the CCADB certificate listing, similarly a server can offer this 168 compression scheme whilst using a certificate chain which does not 169 chain back to a WebPKI root. Furthermore, new root certificates are 170 typically included in the CCADB at the start of their application to 171 a root store, a process which typically takes more than a year. 172 Consequently, applicant root certificates can be added to new 173 versions of this scheme ahead of any trust decisions, allowing new 174 CAs to compete on equal terms with existing CAs as soon as they are 175 approved for inclusion in a root program. As a result this scheme is 176 equitable in so far as it provides equal benefits for all CAs in the 177 WebPKI, doesn't privilege any particular end-entity certificate or 178 website and allows WebPKI clients to make individual trust decisions 179 without fear of breakage. 181 1.3. Relationship to other drafts 183 This draft defines a certificate compression mechanism suitable for 184 use with TLS Certificate Compression [TLSCertCompress]. 186 The intent of this draft is to provide an alternative to CA 187 Certificate Suppression [SCA] as it provides a better compression 188 ratio, can operate in a wider range of scenarios (including out of 189 sync clients or servers) and doesn't require any additional error 190 handling or retry mechanisms. 192 CBOR Encoded X.509 (C509) [I-D.ietf-cose-cbor-encoded-cert-05] 193 defines a concise alternative format for X.509 certificates. If this 194 format were to become widely used on the WebPKI, defining an 195 alternative version of this draft specifically for C509 certificates 196 would be beneficial. 198 Compact TLS, (cTLS) [I-D.ietf-tls-ctls-08] defines a version of 199 TLS1.3 which allows a pre-configured client and server to establish a 200 session with minimal overhead on the wire. In particular, it 201 supports the use of a predefined list of certificates known to both 202 parties which can be compressed. However, cTLS is still at an early 203 stage and may be challenging to deploy in a WebPKI context due to the 204 need for clients and servers to have prior knowledge of handshake 205 profile in use. 207 TLS Cached Information Extension [RFC7924] introduced a new extension 208 allowing clients to signal they had cached certificate information 209 from a previous connection and for servers to signal that the clients 210 should use that cache instead of transmitting a redundant set of 211 certificates. However this RFC has seen little adoption in the wild 212 due to concerns over client privacy. 214 Handling long certificate chains in TLS-Based EAP Methods [RFC9191] 215 discusses the challenges of long certificate chains outside the 216 WebPKI ecosystem. Although the scheme proposed in this draft is 217 targeted at WebPKI use, defining alternative shared dictionaries for 218 other major ecosystems may be of interest. 220 1.4. Status 222 This draft is still at an early stage. Open questions are marked 223 with the tag *DISCUSS*. 225 2. Conventions and Definitions 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 229 "OPTIONAL" in this document are to be interpreted as described in 230 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 231 capitals, as shown here. 233 This draft refers to dates in Internet Date/Time Format as specified 234 in Section 5.6 of [DATES] without the optional T separator. 236 3. Abridged Compression Scheme 238 This section describes a compression scheme suitable for compressing 239 certificate chains used in TLS. The scheme is defined in two parts. 240 An initial pass compressing known intermediate and root certificates 241 and then a subsequent pass compressing the end-entity certificate. 243 The compression scheme in this draft has two parameters listed below 244 which influence the construction of the static dictionary. Future 245 versions of this draft would use different parameters and so 246 construct different dictionaries which would be registered under 247 different TLS Certificate Compression code points. This is discussed 248 further in Section 5. 250 * CCADB_SNAPSHOT_TIME - 2023-01-01 00:00:00Z 252 * CT_CERT_WINDOW - 2022-12-01 00:00:00Z to 2023-01-01 00:00:00Z 254 3.1. Pass 1: Intermediate and Root Compression 256 This pass relies on a shared listing of intermediate and root 257 certificates known to both client and server. As many clients (e.g. 258 Mozilla Firefox and Google Chrome) already ship with a list of 259 trusted intermediate and root certificates, this pass allows their 260 existing lists to be reused, rather than requiring them to have to be 261 duplicated and stored in a separate format. The first subsection 262 details how the certificates are enumerated in an ordered list. This 263 ordered list is distributed to client and servers which use it to 264 compress and decompress certificate chains as detailed in the 265 subsequent subsection. 267 3.1.1. Enumeration of Known Intermediate and Root Certificates 269 The Common CA Database [CCADB] is operated by Mozilla on behalf of a 270 number of Root Program operators including Mozilla, Microsoft, 271 Google, Apple and Cisco. The CCADB contains a listing of all the 272 root certificates trusted by these root programs, as well as their 273 associated intermediate certificates and not yet trusted certificates 274 from new applicants to one or more root programs. 276 At the time of writing, the CCADB contains around 200 root program 277 certificates and 2000 intermediate certificates which are trusted for 278 TLS Server Authentication, occupying 3 MB of disk space. The listing 279 used in this draft will be the relevant certificates included in the 280 CCADB at CCADB_SNAPSHOT_TIME. 282 As entries on this list typically have a lifespan of 10+ years and 283 new certificates are added to the CCADB a year or or more before 284 being marked as trusted, future drafts which include newer 285 certificates will only need to be issued infrequently. This is 286 discussed further in Section 5. 288 The algorithm for enumerating the list of compressible intermediate 289 and root certificates is given below: 291 1. Query the CCADB for all known root and intermediate certificates 292 [CCADBAllCerts] as of CCADB_SNAPSHOT_TIME 294 2. Remove all certificates which have an extendedKeyUsage extension 295 but do not have the TLS Server Authentication bit set or the 296 anyExtendedKeyUsage bit set. 298 3. Remove all certificates whose notAfter date is on or before 299 CCADB_SNAPSHOT_TIME. 301 4. Remove all root certificates which are not marked as trusted or 302 in the process of applying to be trusted by at least one of the 303 following browser root programs: Mozilla, Google, Microsoft, 304 Apple. 306 5. Remove all intermediate certificates which do not chain back to 307 root certificates still in the listing. 309 6. Remove any certificates which are duplicates (have the same 310 SHA256 certificate fingerprint) 312 7. Order the list of certificates by the timestamp for when each was 313 added to the CCADB, breaking any ties with the lexicographic 314 ordering of the SHA256 certificate fingerprint. 316 8. Associate each element of the list with the concatenation of the 317 constant 0xff and its index in the list represented as a uint16. 319 [[*DISCUSS:* The four programs were selected because they represent 320 certificate consumers in the CCADB. Are there any other root 321 programs which ought to be included? The only drawback is a larger 322 disk requirement, since this compression scheme does not impact trust 323 decisions.]] 325 [[*TODO:* Ask CCADB to provide an authoritative copy of this listing. 326 A subset of these lists is available in benchmarks/data in this 327 draft's repository.]] 329 3.1.2. Compression of CA Certificates in Certificate Chain 331 Compression Algorithm: 333 * Input: The byte representation of a Certificate message as defined 334 in [TLS13] whose contents are X509 certificates. 336 * Output: opaque bytes suitable for transmission in a 337 CompressedCertificate message defined in [TLSCertCompress]. 339 1. Parse the message and extract a list of CertificateEntrys, 340 iterate over the list. 342 2. Check if cert_data is bitwise identical to any of the known 343 intermediate or root certificates from the listing in the 344 previous section. 346 1. If so, replace the opaque cert_data member of 347 CertificateEntry with its adjusted three byte identifier and 348 copy the CertificateEntry structure with corrected lengths to 349 the output. 351 2. Otherwise, copy the CertificateEntry entry to the output 352 without modification. 354 3. Correct the length field for the Certificate message. 356 The resulting output should be a well-formatted Certificate message 357 payload with the recognized intermediate and root certificates 358 replaced with three byte identifiers and resulting lengths corrected. 359 Note that the extensions field in each CertificateEntry remains 360 unchanged, as does the certificate_request_context and any 361 unrecognized certificates. 363 The decompression algorithm requires the above steps but in reverse, 364 swapping any recognized three-byte identifier in a cert_data field 365 with the DER representation of the associated certificate and 366 updating the lengths. Unrecognized three-byte identifiers are 367 ignored. Note that this does not have security implications, as the 368 peer could send a Certificate message with an arbitrary payload 369 directly. If the compressed certificate chain cannot be parsed (e.g. 370 due to incorrect length fields) the decompression algorithm MUST 371 report the failure and as required by [TLSCertCompress], the 372 connection MUST be terminated with the "bad_certificate" alert. 374 TLS implementations intending to only use this scheme as a compressor 375 (e.g. servers) SHOULD minimize the storage requirements of pass 1 by 376 using a lookup table which maps the cryptographic hash of each 377 certificate in the pass 1 listing to its assigned three byte 378 identifier. This avoids the need for the compressor to retain a full 379 copy of the pass 1 list. The hashing algorithm used in this lookup 380 table is internal to the implementation and not exposed, but MUST be 381 cryptographically secure. Note that implementations using this 382 scheme as a decompressor (e.g. clients) typically already ship with a 383 listing of trusted root and intermediate certificates which can be 384 reused by the decompressor without any additional storage overhead. 386 3.2. Pass 2: End-Entity Compression 388 This section describes a pass based on Zstandard [ZSTD] with 389 application-specified dictionaries. The dictionary is constructed 390 with reference to the list of intermediate and root certificates 391 discussed earlier in Section 3.1.1, as well as several external 392 sources of information. 394 [[*DISCUSS:* This draft is unopinionated about the underlying 395 compression scheme is used as long as it supports application 396 specified dictionaries. Is there an argument for using a different 397 scheme?]] 399 3.2.1. Construction of Shared Dictionary 401 [[*DISCUSS / TODO:* This section remains a work in progress and needs 402 refinement. The goal is to produce a dictionary of minimal size 403 which provides maximum compression whilst treating every CA 404 equitably. Currently this dictionary occupies ~65KB of space, is 405 equitable and has performance within a ~100 bytes of the best known 406 alternative. This is discussed further in Section 4.]] 408 The dictionary is built by systematic combination of the common 409 strings used in certificates by each issuer in the known list 410 described in Section 3.1.1. This dictionary is constructed in three 411 stages, with the output of each stage being concatenated with the 412 next. Implementations of this scheme need only consume the finished 413 dictionary and do not need to construct it themselves. 415 * Firstly, for each intermediate certificate enumerated in the 416 listing in Section 3.1.1., extract the issuer field 417 (Section 4.1.2.4 of [RFC5280]) and derive the matching authority 418 key identifier (Section 4.2.1.1 of [RFC5280]) for the certificate. 419 Order them according to the listing in Section 3.1.1, then copy 420 them to the output. 422 * Secondly, take the listing of certificate transparency logs 423 trusted by the root programs selected in Section 3.1.1, which are 424 located at[AppleCTLogs] [GoogleCTLogs] as of CCADB_SNAPSHOT_TIME 425 and extract the list of log identifiers. Remove duplicates and 426 order them lexicographically, then copy them to the output. 428 * Finally, enumerate all certificates contained within certificate 429 transparency logs above and witnessed during CT_CERT_WINDOW. For 430 each issuer in the listing in Section 3.1.1, select the first end- 431 entity certificate when ordered by the log id (lexicographically) 432 and latest witnessed date. 434 Extract the contents of the following extensions from the end- 435 entity certificate selected for each issuer: 437 - Authority Information Access (Section 4.2.2.1 of [RFC5280]) 439 - Certificate Policies (Section 4.2.1.4 of [RFC5280]) 441 - CRL Distribution Points (Section 4.2.1.13 of [RFC5280]) 443 - Freshest CRL (Section 4.2.1.15 of [RFC5280]) 445 Concatenate the byte representation of each extension (including 446 extension id and length) and copy it to the output. If no end- 447 entity certificate can be found for an issuer with this process, 448 omit the entry for that issuer. 450 [[*DISCUSS:* This last step is picking a single certificate issued by 451 each issuer as a canonical reference to use for compression. The 452 ordering chosen allows the dictionary builder to stop traversing CT 453 as soon as they've found an entry for each issuer. It would be much 454 more efficient to just ask CAs to submit this information to the 455 CCADB directly.]] 457 3.2.1.1. Compression of End-Entity Certificates in Certificate Chain 459 The resulting bytes from Pass 1 are passed to ZStandard [ZSTD] with 460 the dictionary specified in the previous section. It is RECOMMENDED 461 that the compressor (i.e. the server) use the following parameters: 463 * chain_log=30 465 * search_log=30 467 * hash_log=30 469 * target_length=6000 470 * threads=1 472 * compression_level=22 474 * force_max_window=1 476 These parameters are recommended in order to achieve the best 477 compression ratio however implementations MAY use their preferred 478 parameters as long as the resulting output can be decompressed by a 479 [ZSTD]-compliant implementation. With TLS Certificate Compression, 480 the server needs to only perform a single compression at startup and 481 cache the result, so optimizing for maximal compression is 482 recommended. The client's decompression speed is insensitive to 483 these parameters. 485 4. Preliminary Evaluation 487 [[*NOTE:* This section to be removed prior to publication.]] 489 The storage footprint refers to the on-disk size required for the 490 end-entity dictionary. The other columns report the 5th, 50th and 491 95th percentile of the resulting certificate chains. The evaluation 492 set was a ~75,000 certificate chains from the Tranco list using the 493 python scripts in the draft's Github repository. 495 +==========================+===================+======+======+======+ 496 | Scheme | Storage | p5 | p50 | p95 | 497 | | Footprint | | | | 498 +==========================+===================+======+======+======+ 499 | Original | 0 | 2308 | 4032 | 5609 | 500 +--------------------------+-------------------+------+------+------+ 501 | TLS Cert Compression | 0 | 1619 | 3243 | 3821 | 502 +--------------------------+-------------------+------+------+------+ 503 | Intermediate Suppression | 0 | 1020 | 1445 | 3303 | 504 | and TLS Cert Compression | | | | | 505 +--------------------------+-------------------+------+------+------+ 506 | *This Draft* | 65336 | 661 | 1060 | 1437 | 507 +--------------------------+-------------------+------+------+------+ 508 | *This Draft with opaque | 3000 | 562 | 931 | 1454 | 509 | trained dictionary* | | | | | 510 +--------------------------+-------------------+------+------+------+ 511 | Hypothetical Optimal | 0 | 377 | 742 | 1075 | 512 | Compression | | | | | 513 +--------------------------+-------------------+------+------+------+ 515 Table 1 517 * 'Original' refers to the sampled certificate chains without any 518 compression. 520 * 'TLS Cert Compression' used ZStandard with the parameters 521 configured for maximum compression as defined in 522 [TLSCertCompress]. 524 * 'Intermediate Suppression and TLS Cert Compression' was modelled 525 as the elimination of all certificates in the intermediate and 526 root certificates with the Basic Constraints CA value set to true. 527 If a cert chain included an unrecognized certificate with CA 528 status, then no CA certificates were removed from that chain. The 529 cert chain was then passed to 'TLS Cert Compression' as a second 530 pass. 532 * 'This Draft with opaque trained dictionary' refers to pass 1 and 533 pass 2 as defined by this draft, but instead using a 3000 byte 534 dictionary for pass 2 which was produced by the Zstandard 535 dictionary training algorithm. This illustrates a ceiling on what 536 ought to be possible by improving the construction of the pass 2 537 dictionary in this document. However, using this trained 538 dictionary directly will not treat all CA's equitably, as the 539 dictionary will be biased towards compressing the most popular CAs 540 more effectively. 542 * 'Hypothetical Optimal Compression' is the resulting size of the 543 cert chain after reducing it to only the public key in the end- 544 entity certificate, the CA signature over the EE cert, the 545 embedded SCT signatures and a compressed list of domains in the 546 SAN extension. This represents the best possible compression as 547 it entirely removes any CA certs, identifiers, field tags and 548 lengths and non-critical extensions such as OCSP, CRL and policy 549 extensions. 551 5. Deployment Considerations 553 5.1. Dictionary Versioning 555 The scheme defined in this draft is deployed with the static 556 dictionaries constructed from the parameters listed in Section 3 557 fixed to a particular TLS Certificate Compression code point. 559 As new CA certificates are added to the CCADB and deployed on the 560 web, new versions of this draft would need to be issued with their 561 own code point and dictionary parameters. However, the process of 562 adding new root certificates to a root store is already a two to 563 three year process and this scheme includes untrusted root 564 certificates still undergoing the application process in its 565 dictionary. As a result, it would be reasonable to expect a new 566 version of this scheme with updated dictionaries to be issued at most 567 once a year and more likely once every two or three years. 569 A more detailed analysis and discussion of CA certificate lifetimes 570 and root store operations is included in Appendix B, as well as an 571 alternative design which would allow for dictionary negotiation 572 rather than fixing one dictionary per code point. 574 [[*DISCUSS:* Are there concerns over this approach? Would using at 575 most one code point per year be acceptable? Currently 3 of the 16384 576 'Specification Required' IANA managed code points are in use.]] 578 5.2. Version Migration 580 As new versions of this scheme are specified, clients and servers 581 would benefit from migrating to the latest version. Whilst servers 582 using CA certificates outside the scheme's listing can still offer 583 this compression scheme and partially benefit from it, migrating to 584 the latest version ensures that new CAs can compete on a level 585 playing field with existing CAs. It is possible for a client or 586 server to offer multiple versions of this scheme without having to 587 pay twice the storage cost, since the majority of the stored data is 588 in the pass 1 certificate listing and the majority of certificates 589 will be in both versions and so need only be stored once. 591 Clients and servers SHOULD offer the latest version of this scheme 592 and MAY offer one or more historical versions. Although clients and 593 servers which fall out of date will no longer benefit from the 594 scheme, they will not suffer any other penalties or 595 incompatibilities. Future schemes will likely establish recommended 596 lifetimes for sunsetting a previous version and adopting a new one. 598 As the majority of clients deploying this scheme are likely to be web 599 browsers which typically use monthly release cycles (even long term 600 support versions like Firefox ESR offer point releases on a monthly 601 basis), this is unlikely to be a restriction in practice. The 602 picture is more complex for servers as operators are often to 603 reluctant to update TLS libraries, but as a new version only requires 604 changes to static data without any new code and would happen 605 infrequently, this is unlikely to be burdensome in practice. 607 5.3. Disk Space Requirements 609 Clients and servers implementing this scheme need to store a listing 610 of root and intermediate certificates for pass 1, which currently 611 occupies around ~3 MB and a smaller dictionary on the order of ~100 612 KB for pass 2. Clients and servers offering multiple versions of 613 this scheme do not need to duplicate the pass 1 listing, as multiple 614 versions can refer to same string. 616 As popular web browsers already ship a complete list of trusted 617 intermediate and root certificates, their additional storage 618 requirements are minimal. Servers offering this scheme are intended 619 to be 'full-fat' web servers and so typically have plentiful storage 620 already. This draft is not intended for use in storage-constrained 621 IoT devices, but alternative versions with stripped down listings may 622 be suitable. 624 [[*DISCUSS:* The current draft priorities an equitable treatment for 625 every recognized and applicant CA over minimizing storage 626 requirements. The required disk space could be significantly reduced 627 by only including CAs which meet a particular popularity threshold 628 via CT log sampling.]] 630 5.4. Implementation Complexity 632 Although much of this draft is dedicated to the construction of the 633 certificate list and dictionary used in the scheme, implementations 634 are indifferent to these details. Pass 1 can be implemented as a 635 simple string substitution and pass 2 with a single call to 636 permissively licensed and widely distributed Zstandard 637 implementations such as [ZstdImpl]. Future versions of this draft 638 which vary the dictionary construction then only require changes to 639 the static data shipped with these implementations and the use of a 640 new code point. 642 There are several options for handling the distribution of the 643 associated static data. One option is to distribute it directly with 644 the TLS library and update it as part of that library's regular 645 release cycle. Whilst this is easy for statically linked libraries 646 written in languages which offer first-class package management and 647 compile time feature selection (e.g. Go, Rust), it is trickier for 648 dynamically linked libraries who are unlikely to want to incur the 649 increased distribution size. In these ecosystems it may make sense 650 to distribute the dictionaries are part of an independent package 651 managed by the OS which can be discovered by the library at run-time. 652 Another promising alternative would be to have existing automated 653 certificate tooling provision the library with both the full 654 certificate chain and multiple precompressed chains during the 655 certificate issuance / renewal process. 657 6. Security Considerations 659 This draft does not introduce new security considerations for TLS, 660 except for the considerations already identified in 661 [TLSCertCompress], in particular: 663 * The decompressed Certificate message MUST be processed as if it 664 were encoded without being compressed in order to ensure parsing 665 and verification have the same security properties as they would 666 in TLS normally. 668 * Since Certificate chains are presented on a per-server-name or 669 per-user basis, a malicious application cannot introduce 670 individual fragments into the Certificate message in order to leak 671 information by modifying the plaintext. 673 Further, implementors SHOULD use a memory-safe language to implement 674 this compression schemes. 676 Note that as this draft specifies a compression scheme, it does not 677 impact the negotiation of trust between clients and servers and is 678 robust in the face of changes to CCADB or trust in a particular 679 WebPKI CA. The client's trusted list of CAs does not need to be a 680 subset or superset of the CCADB list and revocation of trust in a CA 681 does not impact the operation of this compression scheme. Similarly, 682 servers who use roots or intermediates outside the CCADB can still 683 offer and benefit from this scheme. 685 7. Privacy Considerations 687 Some servers may attempt to identify clients based on their TLS 688 configuration, known as TLS fingerprinting [FingerprintingPost]. If 689 there is significant diversity in the number of TLS Certificate 690 Compression schemes supported by clients, this might enable more 691 powerful fingerprinting attacks. However, this compression scheme 692 can be used by a wide range of clients, even if they make different 693 or contradictory trust decisions and so the resulting diversity is 694 expected to be low. 696 In TLS1.3, the extension carrying the client's supported TLS 697 Certificate Compression schemes is typically transmitted unencrypted 698 and so can also be exploited by passive network observers in addition 699 to the server with whom the client is communicating. Deploying 700 Encrypted Client Hello [ECH] enables the encryption of the Client 701 Hello and the TLS Certificate Compression extension within it which 702 can mitigate this leakage. 704 8. IANA Considerations 706 [[*TODO:* Adopt an identifier for experimental purposes.]] 708 9. References 710 9.1. Normative References 712 [AppleCTLogs] 713 Apple, "Certificate Transparency Logs trusted by Apple", 5 714 June 2023, . 717 [CCADBAllCerts] 718 Mozilla, Microsoft, Google, Apple, and Cisco, "CCADB 719 Certificates Listing", 5 June 2023, 720 . 723 [DATES] Klyne, G. and C. Newman, "Date and Time on the Internet: 724 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 725 . 727 [GoogleCTLogs] 728 Google, "Certificate Transparency Logs trusted by Google", 729 5 June 2023, . 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, 735 DOI 10.17487/RFC2119, March 1997, 736 . 738 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 739 Housley, R., and W. Polk, "Internet X.509 Public Key 740 Infrastructure Certificate and Certificate Revocation List 741 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 742 . 744 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 745 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 746 May 2017, . 748 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 749 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 750 . 752 [TLSCertCompress] 753 Ghedini, A. and V. Vasiliev, "TLS Certificate 754 Compression", RFC 8879, DOI 10.17487/RFC8879, December 755 2020, . 757 [ZSTD] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression 758 and the 'application/zstd' Media Type", RFC 8878, 759 DOI 10.17487/RFC8878, February 2021, 760 . 762 9.2. Informative References 764 [CCADB] Mozilla, Microsoft, Google, Apple, and Cisco, "Common CA 765 Database", 5 June 2023, . 767 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 768 Encrypted Client Hello", Work in Progress, Internet-Draft, 769 draft-ietf-tls-esni-17, 9 October 2023, 770 . 773 [FastlyStudy] 774 McManus, P., "Does the QUIC handshake require compression 775 to be fast?", 18 May 2020, . 779 [FingerprintingPost] 780 Team, F. S. R., "The state of TLS fingerprinting What’s 781 Working, What Isn’t, and What’s Next", 20 July 2022, 782 . 785 [I-D.ietf-cose-cbor-encoded-cert-05] 786 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 787 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 788 Certificates)", Work in Progress, Internet-Draft, draft- 789 ietf-cose-cbor-encoded-cert-05, 10 January 2023, 790 . 793 [I-D.ietf-tls-ctls-08] 794 Rescorla, E., Barnes, R., Tschofenig, H., and B. M. 795 Schwartz, "Compact TLS 1.3", Work in Progress, Internet- 796 Draft, draft-ietf-tls-ctls-08, 13 March 2023, 797 . 800 [PQStudy] Westerbaan, B., "Sizing Up Post-Quantum Signatures", 8 801 November 2021, . 804 [QUICStudy] 805 Nawrocki, M., Tehrani, P., Hiesgen, R., Mücke, J., 806 Schmidt, T., and M. Wählisch, "On the interplay between 807 TLS certificates and QUIC performance", ACM, Proceedings 808 of the 18th International Conference on emerging 809 Networking EXperiments and Technologies, 810 DOI 10.1145/3555050.3569123, November 2022, 811 . 813 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 814 (TLS) Cached Information Extension", RFC 7924, 815 DOI 10.17487/RFC7924, July 2016, 816 . 818 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 819 Multiplexed and Secure Transport", RFC 9000, 820 DOI 10.17487/RFC9000, May 2021, 821 . 823 [RFC9191] Sethi, M., Preuß Mattsson, J., and S. Turner, "Handling 824 Large Certificates and Long Certificate Chains in TLS- 825 Based EAP Methods", RFC 9191, DOI 10.17487/RFC9191, 826 February 2022, . 828 [SCA] Kampanakis, P., Bytheway, C., Westerbaan, B., and M. 829 Thomson, "Suppressing CA Certificates in TLS 1.3", Work in 830 Progress, Internet-Draft, draft-kampanakis-tls-scas- 831 latest-03, 5 January 2023, 832 . 835 [SCAStudy] Kampanakis, P. and M. Kallitsis, "Faster Post-Quantum TLS 836 Handshakes Without Intermediate CA Certificates", Springer 837 International Publishing, Lecture Notes in Computer 838 Science pp. 337-355, DOI 10.1007/978-3-031-07689-3_25, 839 ISBN ["9783031076886", "9783031076893"], 2022, 840 . 842 [ZstdImpl] Facebook, "ZStandard (Zstd)", 5 June 2023, 843 . 845 Appendix A. Acknowledgments 847 The authors thank Bas Westerbaan, Martin Thomson and Kathleen Wilson 848 for feedback on early versions of this document. 850 Appendix B. CCADB Churn and Dictionary Negotiation 852 B.1. CCADB Churn 854 Typically around 10 or so new root certificates are introduced to the 855 WebPKI each year. The various root programs restrict the lifetimes 856 of these certificates, Microsoft to between 8 and 25 years (3.A.3 857 (https://learn.microsoft.com/en-us/security/trusted-root/program- 858 requirements)), Mozilla to between 0 and 14 years (Summary 859 (https://wiki.mozilla.org/CA/Root_CA_Lifecycles)). Chrome has 860 proposed a maximum lifetime of 7 years in the future (Blog Post 861 (https://www.chromium.org/Home/chromium-security/root-ca-policy/ 862 moving-forward-together/)). Some major CAs have objected to this 863 proposed policy as the root inclusion process currently takes around 864 3 years from start to finish (Digicert Blog 865 (https://www.digicert.com/blog/googles-moving-forward-together- 866 proposals-for-root-ca-policy)). Similarly, Mozilla requires CAs to 867 apply to renew their roots with at least 2 years notice (Summary 868 (https://wiki.mozilla.org/CA/Root_CA_Lifecycles)). 870 Typically around 100 to 200 new WebPKI intermediate certificates are 871 issued each year. No WebPKI root program currently limits the 872 lifetime of intermediate certificates, but they are in practice 873 capped by the lifetime of their parent root certificate. The vast 874 majority of these certificates are issued with 10 year lifespans. A 875 small but notable fraction (<10%) are issued with 2 or 3 year 876 lifetimes. Chrome's Root Program has proposed that Intermediate 877 Certificates be limited to 3 years in the future (Update 878 (https://www.chromium.org/Home/chromium-security/root-ca-policy/ 879 moving-forward-together/)). However, the motivation for this 880 requirement is unclear. Unlike root certificates, intermediate 881 certificates are only required to be disclosed with a month's notice 882 to the CCADB (Mozilla Root Program Section 5.3.2 883 (https://www.mozilla.org/en-US/about/governance/policies/security- 884 group/certs/policy/#53-intermediate-certificates), Chrome Policy 885 (https://www.chromium.org/Home/chromium-security/root-ca-policy/)). 887 B.2. Dictionary Negotiation 889 This draft is currently written with a view to being adopted as a 890 particular TLS Certificate Compression Scheme. However, this means 891 that each dictionary used in the wild must have an assigned code 892 point. A new dictionary would likely need to be issued no more than 893 yearly. However, negotiating the dictionary used would avoid the 894 overhead of minting a new draft and code point. A sketch for how 895 dictionary negotiation might work is below. 897 This draft would instead define a new extension, which would define 898 TLS Certificate Compression with ZStandard Dictionaries. 899 Dictionaries would be identified by an IANA-assigned identifier of 900 two bytes, with a further two bytes for the major version and two 901 more for the minor version. Adding new certificates to a dictionary 902 listing would require a minor version bump. Removing certificates or 903 changing the pass 2 dictionary would require a major version bump. 905 struct { 906 uint16 identifier; 907 uint16 major_version; 908 uint16 minor_version; 909 } DictionaryId 911 struct { 912 DictionaryId supported_dictionaries<6..2^16-1> 913 } ZStdSharedDictXtn 915 The client lists their known dictionaries in an extension in the 916 ClientHello. The client need only retain and advertise the highest 917 known minor version for any major version of a dictionary they are 918 willing to offer. The server may select any dictionary it has a copy 919 of with matching identifier, matching major version number and a 920 minor version number not greater than the client's minor version 921 number. 923 The expectation would be that new minor versions would be issued 924 monthly or quarterly, with new major versions only every year or 925 multiple years. This reflects the relative rates of when 926 certificates are added or removed to the CCADB listing. This means 927 in practice clients would likely offer a single dictionary containing 928 their latest known version. Servers would only need to update their 929 dictionaries yearly when a new major version is produced. 931 Author's Address 933 Dennis Jackson 934 Mozilla 935 Email: ietf@dennis-jackson.uk