idnits 2.17.1 draft-hallambaker-tlsfeature-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: ---------------------------------------------------------------------------- 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 -- The document date (April 24, 2013) is 3991 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) == Unused Reference: 'RFC1035' is defined on line 326, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. M. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Standards Track April 24, 2013 5 Expires: October 26, 2013 7 X.509v3 TLS Feature Extension 8 draft-hallambaker-tlsfeature-02 10 Abstract 12 The purpose of the TLS Feature extension is to prevent downgrade 13 attacks that are not otherwise prevented by the TLS protocol. In 14 particular, the TLS Feature extension may be used to mandate support 15 for revocation checking features in the TLS protocol such as OCSP 16 stapling. Informing clients that an OCSP status response will always 17 be stapled permits an immediate failure in the case that the response 18 is not stapled. This in turn prevents a denial of service attack 19 that might otherwise be possible. 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 http://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 October 26, 2013. 38 Copyright Notice 40 Copyright (c) 2013 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 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 57 1.2. TLS Feature . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. TLS Feature . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. status_request . . . . . . . . . . . . . . . . . . . 5 62 3.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2.1. Certificate Signing Request . . . . . . . . . . . . . 5 64 3.2.2. Certificate Signing Certificate . . . . . . . . . . . 5 65 3.2.3. End Entity Certificate . . . . . . . . . . . . . . . 6 66 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3.1. Certification Authority . . . . . . . . . . . . . . . 6 68 3.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 5.1. Alternative Certificates and Certificate Issuers . . . . 7 73 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 7 74 5.3. Cipher Suite Downgrade Attack . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Definitions 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 1.2. TLS Feature 89 In order to avoid the confusion that would occur in attempting to 90 describe an X.509 extension describing the use of TLS extensions, in 91 this document the term 'extension' is reserved to refer to X.509v3 92 extensions and the term 'feature' is used to refer to a TLS 93 extension. 95 2. Purpose 96 The purpose of the TLS Feature extension is to prevent downgrade 97 attacks that are not otherwise prevented by the TLS protocol. 99 Since the TLS protocol itself provides strong protection against most 100 forms of downgrade attack including downgrade attacks against cipher 101 suite choices offered and client credentials, the TLS Feature is only 102 relevant to the validation of TLS protocol credentials. In 103 particular to the revocation status of the server credentials 104 presented. 106 At the time of writing, the only TLS feature extensions that are 107 relevant to the revocation status of credentials is the Certificate 108 Status Request extension (status_request) Multiple Certificate Status 109 Extension (status_request_v2) These extensions are used to support 110 in-band exchange of OCSP tokens, otherwise known as OCSP stapling. 111 These extensions are described in [RFC6066] and [draft-pettersen-tls- 112 ext-multiple-ocsp-03]. 114 The OCSP stapling mechanism described in [RFC6066] permits a TLS 115 server to provide evidence of valid certificate status inband. When 116 this information is provided inband, the privacy, performance and 117 reliability concerns arising from the need to make a third party 118 connection during the TLS handshake are eliminated. A client cannot 119 however draw any conclusion from the absence of inband status 120 information unless it knows that the legitimate server would have 121 provided it. The status information might have been omitted because 122 the server does not support the extension or because the server is 123 witholding the information intentionally, knowing the certificate to 124 be invalid. 126 The inclusion of a TLS feature extension advertising the 127 status_request feature in the server end entity certificate permits a 128 client to fail immediately if the certificate status information is 129 not provided by the server. The need to query the OCSP responder is 130 eliminated entirely. This improves client efficiency and more 131 importantly prevents a denial of service attack against the client by 132 either blocking the OCSP response or mounting a denial of service 133 attack against the OCSP responder. 135 Since the TLS Feature extension is an option, it is not likely that 136 an attacker attempting to obtain a certificate through fraud will 137 choose to have a certificate issued with this extension. Such risks 138 are more approrpriately addressed by mechanisms such as Certificate 139 Authority Authorization DNS records RFC 6844 [RFC6844] that are 140 designed to prevent or mitigate mis-issue. Nevertheless a 141 Certification Authority MAY consider the presence or absence of a 142 required TLS feature as one factor in determining the level of 143 additional scruitiny a request should be subject to. 145 A server offering an end entity certificate with a TLS feature 146 extension MUST satisfy a client request for the specified feature 147 unless this would be redundant as described below. Otherwise clients 148 MAY refuse connection. It is important therefore that a 149 Certification Authority only issue certificates that specify features 150 that match the configuration of the server and that the server is 151 capable of verifying that its configuration is compatible with the 152 feature declaration of the certificates it offers. Ideally, the TLS 153 feature declaration would be specified by the certificate request 154 generator as part of the certificate issue process. 156 A client feature request is redundant if the purpose of the request 157 is fully satisfied by another feature. For example, a server need 158 not satisfy a client request for the status_request feature if the 159 status_request_v2 is offered and satisfied. 161 In the case that the cached_information feature is offered and 162 satisfied, a client request for the status_request or 163 status_request_v2 features is satisfied if and only if the cached 164 credentials referenced include the OCSP status information necessary 165 to establish the certificate status. 167 This document describes the use of the TLS feature in PKIX end entity 168 and certificate signing certificate and a mechanism that MAY be used 169 to describe support for the specified features in-band for the most 170 commonly used certificate registration protocol. 172 3. Syntax 174 The TLS Feature extension has the following format: 176 tls-feature OBJECT IDENTIFIER ::= { id-pe 1 } 178 Features ::= SEQUENCE OF INTEGER 180 The TLS Feature Extension SHOULD NOT be marked critical. RFC 5280 181 [RFC5280] requires that implementations that do not understand the 182 extension MUST reject the certificate. Marking the TLS Feature 183 Extension critical breaks backward compatibility and is not 184 recommended unless this is the desired behavior. Implementations 185 that process the extension MUST ignore the criticality bit setting. 187 3.1. TLS Feature 189 The TLS Feature extension lists a sequence of TLS extension 190 identifiers (features) that a TLS server compliant with the feature 191 declaration MUST support and satisfy on client request. 193 This specification does not require a TLS client to offer or support 194 any TLS feature regardless of whether it is specified in the server 195 certificate's TLS Feature extension or not. In particular a client 196 MAY request and a server MAY support any TLS extension regardless of 197 whether it is specified in a TLS Feature extension or not. 199 If a TLS Feature extension specifies a TLS feature, a server offering 200 the certificate MUST support the extension specified and MUST comply 201 with any specific requirements specified for that feature in this 202 document or in the document that specifies the TLS feature. 204 3.1.1. status_request 206 If the TLS status_request feature is specified in the TLS Feature 207 extension and a TLS client specifies the status_request feature in 208 the Client Hello, a server MUST return a valid OCSP token for the 209 specified server's End Entity certificate in the response. 211 3.2. Use 213 3.2.1. Certificate Signing Request 215 If the certificate issue mechanism makes use of the PKCS#10 216 Certificate Signing Request (CSR) [RFC2986], the CSR MAY specify a 217 TLS Feature extension as a CSR attribute. A server or server 218 administration tool should only generate key signing requests that it 219 knows can be supported by the server for which the certificate is 220 intended. 222 3.2.2. Certificate Signing Certificate 224 When present in a Certificate Signing Certificate (i.e., CA 225 certificate with the key usage extension value set to keyCertSign), 226 the TLS Feature extension specifies a constraint on valid certificate 227 chains. Specifically, a certificate that is signed by a Certificate 228 Signing Certificate that contains a TLS Feature extension MUST 229 contain a TLS Feature extension which MUST offer the same set or a 230 superset of the features advertised in the signing certificate. 232 While relying parites (i.e., clients) MAY reject certificates that do 233 not comply with this requirement, the use of TLS Feature extension in 234 Certificate Signing Certificates is primarily intended for use by 235 parties seeking to evaluate the performance of certificate issuers 236 and MAY be ignored by clients. 238 3.2.3. End Entity Certificate 240 When specified in a server End Entity Certificate (i.e. a 241 certificate that specifies the id-kp-server EKU), the TLS Feature 242 extension specifies criteria that a server MUST meet to be compliant 243 with the feature declaration. 245 In the case that a client determines that the server configuration is 246 inconsistent with the specified feature declaration it MAY reject the 247 TLS configuration. 249 In the case that a client determines that the server configuration is 250 inconsistent with a feature declaration specifying support for the 251 TLS status_request extension it SHOULD reject the TLS configuration. 253 3.3. Processing 255 3.3.1. Certification Authority 257 A CA SHOULD NOT issue certs with a TLS Feature extension unless there 258 is an affirmative statement to the effect that the end entity intends 259 to support the specified features. For example the use of a Feature 260 extension in the CSR or through an out of band communication. 262 3.3.2. Server 264 A TLS server certificate containing a TLS Feature extension MAY be 265 used with any TLS server that supports the specified features. It is 266 not necessary for the server to provide support for the TLS Feature 267 extension itself. Such support is nevertheless desirable as it can 268 reduce the risk of administrative error. 270 A server SHOULD verify that its configuration is compatible with the 271 TLS Feature extension expressed in a certificate it presents. A 272 server MAY override local configuration options if necessary to 273 ensure consistency but SHOULD inform the administrator whenever such 274 an inconsitency is discovered. 276 A server SHOULD support generation of the Feature extension in CSRs 277 if key generation is supported. 279 3.3.3. Client 281 A compliant client SHOULD reject a TLS connection with security 282 properties that are inconsistent with the specified TLS Feature 283 extension. A compliant client MAY accept such a TLS connection 284 request however if it is determined that doing so is appropriate in 285 particular circumstances. 287 4. Acknowledgements 289 [List of CABForum and PKIX contributors] 291 5. Security Considerations 293 5.1. Alternative Certificates and Certificate Issuers 295 Use of the TLS Feature extension to mandate support for a particular 296 form of revocation checking is optional. This control can provide 297 protection in the case that a certificate with a TLS Feature is 298 compromised after issue but not in the case that the attacker obtains 299 an unmarked certificate from an issuer through fraud. 301 The TLS Feature extension is a post-issue security control. Such 302 risks can only be addressed by security controls that take effect 303 before issue. 305 5.2. Denial of Service 307 A certificate Issuer could issue a certificate that intentionally 308 specified a feature statement that they knew the server could not 309 support. 311 The risks of such refusal would appear to be negligible since a 312 Certificate Authority could equally refuse to issue the certificate. 314 5.3. Cipher Suite Downgrade Attack 316 The TLS Feature extension does not provide protection against a 317 cipher suite downgrade attack. This is left to the existing controls 318 in the TLS protocol itself. 320 6. IANA Considerations 322 No action by IANA is required. 324 7. Normative References 326 [RFC1035] Mockapetris, P., "Domain names - implementation and 327 specification", STD 13, RFC 1035, November 1987. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 333 Request Syntax Specification Version 1.7", RFC 2986, 334 November 2000. 336 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 337 Housley, R., and W. Polk, "Internet X.509 Public Key 338 Infrastructure Certificate and Certificate Revocation List 339 (CRL) Profile", RFC 5280, May 2008. 341 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 342 Extension Definitions", RFC 6066, January 2011. 344 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 345 Authority Authorization (CAA) Resource Record", RFC 6844, 346 January 2013. 348 [X.509] International Telecommunication Union , "ITU-T 349 Recommendation X.509 (11/2008): Information technology - 350 Open systems interconnection - The Directory: Public-key 351 and attribute certificate frameworks ", ITU-T 352 Recommendation X.509, November 2008. 354 [X.680] International Telecommunication Union , "ITU-T 355 Recommendation X.680 (11/2008): Information technology - 356 Abstract Syntax Notation One (ASN.1): Specification of 357 basic notation ", ITU-T Recommendation X.680, November 358 2008. 360 Author's Address 362 Phillip Hallam-Baker 363 Comodo Group Inc. 365 Email: philliph@comodo.com