idnits 2.17.1 draft-hallambaker-tlsfeature-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: ---------------------------------------------------------------------------- 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 01, 2013) is 4042 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 313, 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 01, 2013 5 Expires: October 03, 2013 7 X.509v3 TLS Feature Extension 8 draft-hallambaker-tlsfeature-01 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 03, 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 . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 5.1. Alternative Certificates and Certificate Issuers . . . . 6 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, the TLS Feature is only relevant to the 101 validation of TLS protocol credentials. In particular to the 102 revocation status of the credentials presented. 104 At the time of writing, the only TLS feature that is relevant to the 105 revocation status of credentials is the Certificate Status Request 106 extension (status_request) used to support in-band exchange of OCSP 107 tokens, otherwise known as OCSP stapling. This extension is 108 described in [RFC6066]. 110 The OCSP stapling mechanism described in [RFC6066] permits a TLS 111 server to provide evidence of valid certificate status inband and 112 thus improve client response. A TLS Feature extension that 113 advertises the status_request extension informs a client that if the 114 status_request is specified in a TLS Client Helo, that a server 115 compliant with the feature declaration MUST respond with a valid OCSP 116 token for the End Entity Certificate it presents unless another 117 extension offered by the client indicates that this is unnecessary. 118 For example, if the client indicates that it already has a valid OCSP 119 token cached. 121 Use of the TLS Feature extension in this fashion permits a client to 122 avoid reliance on certificates that are revoked for the reasons that 123 occur most frequently. In particular it allows a client to avoid 124 mis-reliance on certificates that are revoked for cause or at the 125 request of the subject (e.g. because of a compromised private key). 127 Advertising the status_request feature permits a client to fail 128 immediately in the case that the token is not provided by the server 129 without the need to query the OCSP responder in addition. This 130 improves client efficiency and more importantly prevents a denial of 131 service attack against the client by either blocking the OCSP 132 response or mounting a denial of service attack against the OCSP 133 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 Any TLS feature declaration specified in an End Entity certificate 146 MUST be offered by the server or clients MAY refuse connection. It 147 is important therefore that a Certification Authority only issue 148 certificates that specify features that match the configuration of 149 the server and that the server is capable of verifying that its 150 configuration is compatible with the feature declaration of the 151 certificates it offers. Ideally, the TLS feature declaration would 152 be specified by the certificate request generator as part of the 153 certificate issue process. 155 This document describes a mechanism that MAY be used to provide this 156 communication in-band for the most commonly used certificate 157 registration protocol. 159 3. Syntax 161 The TLS Feature extension has the following format: 163 cabf-tls-feature OBJECT IDENTIFIER ::= { cabf 1 } 165 Features ::= SEQUENCE OF INTEGER 167 The TLS Feature Extension MAY be marked critical. RFC 5280 [RFC5280] 168 requires that implementations that do not understand the extension 169 MUST reject the certificate. Marking the TLS Feature Extension 170 critical breaks backward compatibility and is not recommended unless 171 this is the desired behavior. Implementations that process the 172 extension MUST ignore the criticality bit setting. 174 3.1. TLS Feature 176 The TLS Feature extension lists a sequence of TLS extension 177 identifiers that a server compliant with the feature declaration MUST 178 support and accept on client request. 180 This specification does not require a TLS client to offer or support 181 any TLS extension regardless of whether it is specified in the TLS 182 Feature or not. In particular a client MAY request and a server MAY 183 support any TLS extension regardless of whether it is specified in a 184 TLS Feature extension or not. 186 If a TLS Feature extension specifies a TLS extension, a server 187 offering the certificate MUST support the extension specified and 188 MUST comply with any specific requirements specified for that 189 extension in this document or in the document that specifies the TLS 190 extension. 192 3.1.1. status_request 194 If the TLS status_request extension is specified in the TLS Feature 195 extension and a TLS client specifies the status_request extensionin 196 the Client Hello, a server MUST return a valid OCSP token for the 197 specified End Entity certificate in the response. 199 3.2. Use 201 3.2.1. Certificate Signing Request 203 If the certificate issue mechanism makes use of the PKCS#10 204 Certificate Signing Request (CSR) [RFC2986], the CSR MAY specify a 205 TLS Feature extension as a CSR attribute. A server or server 206 administration tool should only generate key signing requests that it 207 knows can be supported by the server for which the certificate is 208 intended. 210 3.2.2. Certificate Signing Certificate 212 When present in a Certificate Signing Certificate, the TLS Feature 213 extension specifies a constraint on valid certificate chains. 214 Specifically, a certificate that is signed by a Certificate Signing 215 Certificate that contains a TLS Feature extension MUST contain a TLS 216 Feature extension which MUST offer the same set or a superset of the 217 features advertised in the signing certificate. 219 While relying clients MAY reject certificates that do not comply with 220 this requirement, the use of TLS Feature extension in Certificate 221 Signing Certificates is primarily intended for use by parties seeking 222 to evaluate the performance of certificate issuers and MAY be ignored 223 by clients. 225 3.2.3. End Entity Certificate 227 When specified in an End Entity Certificate, the TLS Feature 228 extension specifies criteria that a server MUST meet to be compliant 229 with the feature declaration. 231 In the case that a client determines that the server configuration is 232 inconsistent with the specified feature declaration it MAY reject the 233 TLS configuration. 235 In the case that a client determines that the server configuration is 236 inconsistent with a feature declaration specifying support for the 237 TLS status_request extension it SHOULD reject the TLS configuration. 239 3.3. Processing 241 3.3.1. Certification Authority 243 A CA SHOULD NOT issue certs with a Feature extension unless there is 244 an affirmative statement to the effect that the end entity intends to 245 support the specified features. For example the use of a Feature 246 extension in the CSR or through an out of band communication. 248 3.3.2. Server 250 The TLS Feature extension MAY be used with any TLS server regardless 251 of whether the server offers support. Server support for the TLS 252 Feature extension is nevertheless desirable as it can reduce the risk 253 of administrative error. 255 A server SHOULD verify that its configuration is compatible with the 256 TLS Feature extension expressed in a certificate it presents. A 257 server MAY override local configuration options if necessary to 258 ensure consistency but SHOULD inform the administrator whenever such 259 an inconsitency is discovered. 261 A server SHOULD support generation of the Feature extension in CSRs 262 if key generation is supported. 264 3.3.3. Client 266 A compliant client MUST process the TLS Feature Extension and MUST 267 ignore the setting of the X.509 criticality flag. 269 A compliant client SHOULD reject a TLS connection with security 270 properties that are inconsistent with the specified TLS Feature 271 extension. A compliant client MAY accept such a TLS connection 272 request however if it is determined that doing so is appropriate in 273 particular circumstances. 275 4. Acknowledgements 277 [List of CABForum and PKIX contributors] 279 5. Security Considerations 281 5.1. Alternative Certificates and Certificate Issuers 282 Use of the TLS Feature extension to mandate support for a particular 283 form of revocation checking is optional. This control can provide 284 protection in the case that a certificate with a TLS Feature is 285 compromised after issue but not in the case that the attacker obtains 286 an unmarked certificate from an issuer through fraud. 288 The TLS Feature extension is a post-issue security control. Such 289 risks can only be addressed by security controls that take effect 290 before issue. 292 5.2. Denial of Service 294 A certificate Issuer could issue a certificate that intentionally 295 specified a feature statement that they knew the server could not 296 support. 298 The risks of such refusal would appear to be negligible since a 299 Certificate Authority could equally refuse to issue the certificate. 301 5.3. Cipher Suite Downgrade Attack 303 The TLS Feature extension does not provide protection against a 304 cipher suite downgrade attack. This is left to the existing controls 305 in the TLS protocol itself. 307 6. IANA Considerations 309 No action by IANA is required. 311 7. Normative References 313 [RFC1035] Mockapetris, P., "Domain names - implementation and 314 specification", STD 13, RFC 1035, November 1987. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 320 Request Syntax Specification Version 1.7", RFC 2986, 321 November 2000. 323 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 324 Housley, R., and W. Polk, "Internet X.509 Public Key 325 Infrastructure Certificate and Certificate Revocation List 326 (CRL) Profile", RFC 5280, May 2008. 328 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 329 Extension Definitions", RFC 6066, January 2011. 331 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 332 Authority Authorization (CAA) Resource Record", RFC 6844, 333 January 2013. 335 [X.509] International Telecommunication Union , "ITU-T 336 Recommendation X.509 (11/2008): Information technology - 337 Open systems interconnection - The Directory: Public-key 338 and attribute certificate frameworks ", ITU-T 339 Recommendation X.509, November 2008. 341 [X.680] International Telecommunication Union , "ITU-T 342 Recommendation X.680 (11/2008): Information technology - 343 Abstract Syntax Notation One (ASN.1): Specification of 344 basic notation ", ITU-T Recommendation X.680, November 345 2008. 347 Author's Address 349 Phillip Hallam-Baker 350 Comodo Group Inc. 352 Email: philliph@comodo.com