idnits 2.17.1 draft-hallambaker-tlsfeature-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended Status: id', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (March 9, 2015) is 3336 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) ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) ** Downref: Normative reference to an Informational RFC: RFC 2986 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: id March 9, 2015 4 Expires: September 10, 2015 6 X.509v3 TLS Feature Extension 7 draft-hallambaker-tlsfeature-07 9 Abstract 11 The purpose of the TLS Feature extension is to prevent downgrade 12 attacks that are not otherwise prevented by the TLS protocol. In 13 particular, the TLS Feature extension may be used to mandate support 14 for revocation checking features in the TLS protocol such as OCSP 15 stapling. Informing clients that an OCSP status response will always 16 be stapled permits an immediate failure in the case that the response 17 is not stapled. This in turn prevents a denial of service attack that 18 might otherwise be possible. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. TLS Feature . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. TLS Feature . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2.1. Certificate Signing Request . . . . . . . . . . . . 5 60 3.2.2. Certificate Signing Certificate . . . . . . . . . . 5 61 3.2.3. End Entity Certificate . . . . . . . . . . . . . . . 5 62 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3.1. Certification Authority . . . . . . . . . . . . . . 6 64 3.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 5.1. Alternative Certificates and Certificate Issuers . . . . 7 69 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 7 70 5.3. Cipher Suite Downgrade Attack . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Definitions 78 1.1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 1.2. TLS Feature 86 In order to avoid the confusion that would occur in attempting to 87 describe an X.509 extension describing the use of TLS extensions, in 88 this document the term 'extension' is reserved to refer to X.509v3 89 extensions and the term 'feature' is used to refer to a TLS 90 extension. 92 2. Purpose 94 The purpose of the TLS Feature extension is to prevent downgrade 95 attacks that are not otherwise prevented by the TLS protocol. 97 Since the TLS protocol itself provides strong protection against most 98 forms of downgrade attack including downgrade attacks against cipher 99 suite choices offered and client credentials, the TLS Feature is only 100 relevant to the validation of TLS protocol credentials. In 101 particular to the revocation status of the server credentials 102 presented. 104 At the time of writing, the only TLS feature extensions that are 105 relevant to the revocation status of credentials are the Certificate 106 Status Request extension (status_request) and the Multiple 107 Certificate Status Extension (status_request_v2). These extensions 108 are used to support in-band exchange of OCSP tokens, otherwise known 109 as OCSP stapling. These extensions are described in [RFC6066] and 110 [RFC6961]. 112 The OCSP stapling mechanism described in [RFC6066] permits a TLS 113 server to provide evidence of valid certificate status inband. When 114 this information is provided inband, the privacy, performance and 115 reliability concerns arising from the need to make a third party 116 connection during the TLS handshake are eliminated. A client cannot 117 however draw any conclusion from the absence of inband status 118 information unless it knows that the legitimate server would have 119 provided it. The status information might have been omitted because 120 the server does not support the extension or because the server is 121 witholding the information intentionally, knowing the certificate to 122 be invalid. 124 The inclusion of a TLS feature extension advertising the 125 status_request feature in the server end entity certificate permits a 126 client to fail immediately if the certificate status information is 127 not provided by the server. The need to query the OCSP responder is 128 eliminated entirely. This improves client efficiency and more 129 importantly prevents a denial of service attack against the client by 130 either blocking the OCSP response or mounting a denial of service 131 attack against the OCSP responder. 133 Since the TLS Feature extension is an option, it is not likely that 134 an attacker attempting to obtain a certificate through fraud will 135 choose to have a certificate issued with this extension. Such risks 136 are more appropriately addressed by mechanisms such as Certification 137 Authority Authorization DNS records RFC 6844 [RFC6844] that are 138 designed to prevent or mitigate mis-issue. Nevertheless a 139 Certification Authority MAY consider the presence or absence of a 140 required TLS feature as one factor in determining the level of 141 additional scrutiny a request should be subject to. 143 A server offering an end entity certificate with a TLS feature 144 extension MUST satisfy a client request for the specified feature 145 unless this would be redundant as described below. Otherwise clients 146 MAY refuse connection. It is important therefore that a 147 Certification Authority only issue certificates that specify features 148 that match the configuration of the server and that the server is 149 capable of verifying that its configuration is compatible with the 150 feature declaration of the certificates it offers. Ideally, the TLS 151 feature declaration would be specified by the certificate request 152 generator as part of the certificate issue process. 154 This document describes the use of the TLS feature in PKIX end entity 155 and certificate signing certificate and a mechanism that MAY be used 156 to describe support for the specified features in-band for the most 157 commonly used certificate registration protocol. 159 3. Syntax 161 The TLS Feature extension has the following format: 163 tls-feature OBJECT IDENTIFIER ::= { id-pe 24 } 165 Features ::= SEQUENCE OF INTEGER 167 The TLS Feature Extension SHOULD NOT be marked critical. RFC 5280 168 [RFC5280] requires that implementations that do not understand 169 critical extensions MUST reject the certificate. Marking the TLS 170 Feature Extension critical breaks backward compatibility and is not 171 recommended unless this is the desired behavior. 173 3.1. TLS Feature 175 The object member Features is a sequence of TLS extension identifiers 176 (features, in this specification's terminology). If these features 177 are requested by the client in its ClientHello message, then they 178 MUST be present in the server's ServerHello. 180 This specification does not require a TLS client to offer or support 181 any TLS feature regardless of whether it is specified in the server 182 certificate's TLS Feature extension or not. In particular a client 183 MAY request and a server MAY support any TLS extension regardless of 184 whether it is specified in a TLS Feature extension or not. 186 If a TLS Feature extension specifies a TLS feature, a server offering 187 the certificate MUST support the extension specified and MUST comply 188 with any specific requirements specified for that feature in this 189 document or in the document that specifies the TLS feature. 191 3.2. Use 193 3.2.1. Certificate Signing Request 195 If the certificate issue mechanism makes use of the PKCS#10 196 Certificate Signing Request (CSR) [RFC2986], the CSR MAY specify a 197 TLS Feature extension as a CSR attribute. A server or server 198 administration tool should only generate key signing requests that it 199 knows can be supported by the server for which the certificate is 200 intended. 202 3.2.2. Certificate Signing Certificate 204 When present in a Certificate Signing Certificate (i.e., CA 205 certificate with the key usage extension value set to keyCertSign), 206 the TLS Feature extension specifies a constraint on valid certificate 207 chains. Specifically, a certificate that is signed by a Certificate 208 Signing Certificate that contains a TLS Feature extension MUST 209 contain a TLS Feature extension which MUST offer the same set or a 210 superset of the features advertised in the signing certificate. 212 While relying parites (i.e., clients) MAY reject certificates that do 213 not comply with this requirement, the use of TLS Feature extension in 214 Certificate Signing Certificates is primarily intended for use by 215 parties seeking to evaluate the performance of certificate issuers 216 and MAY be ignored by clients. 218 3.2.3. End Entity Certificate 220 When specified in a server end entity Certificate (i.e. a certificate 221 that specifies the id-kp-server EKU), the TLS Feature extension 222 specifies criteria that a server MUST meet to be compliant with the 223 feature declaration. 225 In the case that a client determines that the server configuration is 226 inconsistent with the specified feature declaration it MAY reject the 227 TLS configuration. 229 In the case that a client determines that the server configuration is 230 inconsistent with a feature declaration specifying support for the 231 TLS status_request extension it SHOULD reject the TLS configuration. 233 3.3. Processing 235 3.3.1. Certification Authority 237 A CA SHOULD NOT issue certs with a TLS Feature extension unless there 238 is an affirmative statement to the effect that the end entity intends 239 to support the specified features. For example the use of a Feature 240 extension in the CSR or through an out of band communication. 242 3.3.2. Server 244 A TLS server certificate containing a TLS Feature extension MAY be 245 used with any TLS server that supports the specified features. It is 246 not necessary for the server to provide support for the TLS Feature 247 extension itself. Such support is nevertheless desirable as it can 248 reduce the risk of administrative error. 250 A server SHOULD verify that its configuration is compatible with the 251 TLS Feature extension expressed in a certificate it presents. A 252 server MAY override local configuration options if necessary to 253 ensure consistency but SHOULD inform the administrator whenever such 254 an inconsistency is discovered. 256 A server SHOULD support generation of the Feature extension in CSRs 257 if key generation is supported. 259 3.3.3. Client 261 A client MUST treat a certificate with a TLS Feature extension if the 262 features offered by the server do not contain all features present in 263 both the client's ClientHello message and the TLS Feature extension 265 In the case that use of TLS with a valid certificate is mandated by 266 explicit security policy, application protocol specification or other 267 means, the client MUST refuse the connection. If the use of TLS with 268 a valid certificate is optional, a client MAY accept the connection 269 but MUST NOT treat the certificate as valid. 271 4. Acknowledgements 273 This proposal incorporates text and other contributions from 274 participants in the IETF and CA-Browser forum. In particular, Robin 275 Alden, Richard Barnes, Viktor Dukhovni, Stephen Farrell, Gervase 276 Markham, Yoav Nir, Tom Ritter, Jeremy Rowley, Stefan Santesson, Ryan 277 Sleevi, Brian Smith, Rob Stradling and Sean Turner 279 5. Security Considerations 281 5.1. Alternative Certificates and Certificate Issuers 283 Use of the TLS Feature extension to mandate support for a particular 284 form of revocation checking is optional. This control can provide 285 protection in the case that a certificate with a TLS Feature is 286 compromised after issue but not in the case that the attacker obtains 287 an unmarked certificate from an issuer through fraud. 289 The TLS Feature extension is a post-issue security control. Such 290 risks can only be addressed by security controls that take effect 291 before issue. 293 5.2. Denial of Service 295 A certificate Issuer could issue a certificate that intentionally 296 specified a feature statement that they knew the server could not 297 support. 299 The risks of such refusal would appear to be negligible since a 300 Certification Authority could equally refuse to issue the 301 certificate. 303 5.3. Cipher Suite Downgrade Attack 305 The TLS Feature extension does not provide protection against a 306 cipher suite downgrade attack. This is left to the existing controls 307 in the TLS protocol itself. 309 6. IANA Considerations 311 On approval, IANA shall add in the SMI Security for PKIX Certificate 312 Extension (1.3.6.1.5.5.7.1) registry the following entry: 314 Decimal Description References 315 ------- ------------------------------ --------------------- 316 24 id-pe-tlsfeature {this RFC} 318 7. References 320 7.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 326 Extension Definitions", RFC 6066, January 2011. 328 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 329 Multiple Certificate Status Request Extension", RFC 6961, 330 June 2013. 332 [RFC6844] Hallam-Baker, P.,Stradling, R., "DNS Certification 333 Authority Authorization (CAA) Resource Record", RFC 6844, 334 January 2013. 336 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 337 R.,Polk, W., "Internet X.509 Public Key Infrastructure 338 Certificate and Certificate Revocation List (CRL) 339 Profile", RFC 5280, May 2008. 341 [RFC2986] Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request 342 Syntax Specification Version 1.7", RFC 2986, November 343 2000. 345 Author's Address 347 Phillip Hallam-Baker 348 Comodo Group Inc. 350 philliph@comodo.com