idnits 2.17.1 draft-thomson-tls-sic-00.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: ---------------------------------------------------------------------------- No issues found here. 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 27, 2019) is 1857 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 (-02) exists of draft-nir-tls-tlsflags-00 == Outdated reference: A later version (-10) exists of draft-ietf-tls-certificate-compression-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 March 27, 2019 5 Expires: September 28, 2019 7 Suppressing Intermediate Certificates in TLS 8 draft-thomson-tls-sic-00 10 Abstract 12 A TLS client that has access to the complete set of published 13 intermediate certificates can inform servers of this fact so that the 14 server can avoid sending intermediates, reducing the size of the TLS 15 handshake. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 28, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 53 3. Got Intermediates Flag . . . . . . . . . . . . . . . . . . . 2 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 58 6.2. Informative References . . . . . . . . . . . . . . . . . 3 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1. Introduction 63 In some uses of public key infrastructure (PKI) intermediate 64 certificates are used to sign end-entity certificates. In the web 65 PKI, clients require that certificate authorities disclose all 66 intermediate certificates that they create. Though the set of 67 intermediate certificates is large, the size is bounded, so it is 68 possible to provide a complete set of certificates. 70 For a client that has all intermediates, having the server send 71 intermediates in the TLS handshake increases the size of the 72 handshake unnecessarily. This document creates a signal that a 73 client can send that informs the server that it has a complete set of 74 intermediates. A server that receives this signal can limit the 75 certificate chain it sends to just the end-entity certificate, saving 76 on handshake size. 78 This mechanism is intended to be complementary with certificate 79 compression [COMPRESS] in that it reduces the size of the handshake. 81 2. Terms and Definitions 83 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in BCP 86 14 [RFC2119] [RFC8174] when, and only when, they appear in all 87 capitals, as shown here. 89 3. Got Intermediates Flag 91 A client that believes that it has a current, complete set of 92 intermediate certificates sends the tls_flags extension [TLS-FLAGS] 93 with the 0xTBD flag set to 1. A server can also set the flag in a 94 CertificateRequest extension. 96 A server that receives a value of 1 in the 0xTBD flag from a 97 ClientHello message SHOULD omit all certificates other than the end- 98 entity certificate from its Certificate message. A client that 99 receives a value of 1 in the 0xTBD flag in a CertificateRequest 100 message SHOULD omit all certificates other than the end-entity 101 certificate from the Certificate message that it sends in response. 103 The 0xTBD flag can only be send in a ClientHello or 104 CertificateRequest message. Endpoints that receive a value of 1 in 105 any other handshake message MUST generate a fatal illegal_parameter 106 alert. 108 4. Security Considerations 110 This creates an unencrypted signal that might be used to identify 111 which clients believe that they have all intermediates. This might 112 allow cilents to be more effectively fingerprinted by peers and any 113 elements on the network path. 115 5. IANA Considerations 117 This document registers the 0xTBD flag in the registry created by 118 [TLS-FLAGS]. 120 6. References 122 6.1. Normative References 124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 125 Requirement Levels", BCP 14, RFC 2119, 126 DOI 10.17487/RFC2119, March 1997, 127 . 129 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 130 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 131 May 2017, . 133 [TLS-FLAGS] 134 Nir, Y., "A Flags Extension for TLS 1.3", draft-nir-tls- 135 tlsflags-00 (work in progress), March 2019. 137 6.2. Informative References 139 [COMPRESS] 140 Ghedini, A. and V. Vasiliev, "TLS Certificate 141 Compression", draft-ietf-tls-certificate-compression-04 142 (work in progress), October 2018. 144 Author's Address 146 Martin Thomson 147 Mozilla 149 Email: mt@lowentropy.net