RFC 7633 PROPOSED STANDARD TLS · CERTIFICATES · REVOCATION
X.509v3 Transport Layer Security (TLS) Feature Extension
A certificate extension that tells clients which TLS features the server must provide, so a missing OCSP staple means failure.
RFC EDITOR
Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) Feature Extension", RFC 7633, DOI 10.17487/RFC7633, October 2015, <https://www.rfc-editor.org/info/rfc7633>.
BIBTEX
@misc{rfc7633,
series = {Request for Comments},
number = 7633,
howpublished = {RFC 7633},
publisher = {RFC Editor},
doi = {10.17487/RFC7633},
url = {https://www.rfc-editor.org/info/rfc7633},
author = {P. Hallam-Baker},
title = {{X.509v3 Transport Layer Security (TLS) Feature Extension}},
pagetotal = 11,
year = 2015,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) P. Hallam-Baker
Request for Comments: 7633 Comodo Group Inc.
Category: Standards Track October 2015
ISSN: 2070-1721
X.509v3 Transport Layer Security (TLS) Feature Extension
Abstract
The purpose of the TLS feature extension is to prevent downgrade
attacks that are not otherwise prevented by the TLS protocol. In
particular, the TLS feature extension may be used to mandate support
for revocation checking features in the TLS protocol such as Online
Certificate Status Protocol (OCSP) stapling. Informing clients that
an OCSP status response will always be stapled permits an immediate
failure in the case that the response is not stapled. This in turn
prevents a denial-of-service attack that might otherwise be possible.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7633.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2.2. TLS Feature, X.509 Extension . . . . . . . . . . . . . . 3
3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. TLS Feature . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Certificate Signing Request . . . . . . . . . . . . . 5
4.2.2. Certificate Signing Certificate . . . . . . . . . . . 5
4.2.3. End-Entity Certificate . . . . . . . . . . . . . . . 5
4.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. Certification Authority . . . . . . . . . . . . . . . 6
4.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5.1. Alternative Certificates and Certificate Issuers . . . . 7
5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 8
5.3. Cipher Suite Downgrade Attack . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Transport Layer Security (TLS) feature extension provides a means
of preventing downgrade attacks that are not otherwise prevented by
the TLS protocol.
Since the TLS protocol itself provides strong protection against most
forms of downgrade attack including downgrade attacks against cipher
suite choices offered and client credentials, the TLS feature
extension is only relevant to the validation of TLS protocol
credentials.
2. Definitions
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. TLS Feature, X.509 Extension
In order to avoid the confusion that would occur in attempting to
specify an X.509 extension describing the use of TLS extensions, in
this document the term "extension" is reserved to refer to X.509v3
extensions and the term "TLS feature extension" is used to refer to
what the TLS specification [RFC5246] refers to as an "extension".
3. Purpose
Currently, the only TLS feature extensions that are relevant to the
revocation status of credentials are the Certificate Status Request
extension (status_request) and the Multiple Certificate Status
Extension (status_request_v2). These extensions are used to support
in-band exchange of Online Certificate Status Protocol (OCSP) tokens,
otherwise known as OCSP stapling. These extensions are described in
[RFC6066] and [RFC6961].
The OCSP stapling mechanism described in [RFC6066] permits a TLS
server to provide evidence of valid certificate status in-band. When
this information is provided in-band, the privacy, performance, and
reliability concerns arising from the need to make a third-party
connection during the TLS handshake are eliminated. However, a
client cannot draw any conclusion from the absence of in-band status
information unless it knows that the legitimate server would have
provided it. The status information might have been omitted because
the server does not support the extension or because the server is
withholding the information intentionally, knowing the certificate to
be invalid.
The inclusion of a TLS feature extension advertising the
status_request feature in the server end-entity certificate permits a
client to fail immediately if the certificate status information is
not provided by the server. The need to query the OCSP responder is
eliminated entirely. This improves client efficiency and, more
importantly, prevents a denial-of-service attack against the client
by either blocking the OCSP response or mounting a denial-of-service
attack against the OCSP responder.
Since the TLS feature extension is an option, it is not likely that
an attacker attempting to obtain a certificate through fraud will
choose to have a certificate issued with this extension. Such risks
are more appropriately addressed by mechanisms such as Certification
Authority Authorization DNS records [RFC6844] that are designed to
prevent or mitigate mis-issue.
A server offering an end-entity certificate with a TLS feature
extension MUST satisfy a client request for the specified feature
unless this would be redundant as described below. Clients MAY
refuse to accept the connection if the server does not accept a
request for a specified feature.
A Certification Authority SHOULD NOT issue certificates that specify
a TLS feature extension advertising features that the server does not
support.
A server MAY advise a Certification Authority that it is capable of
supporting a feature by including the corresponding TLS feature
extension in a Certificate Signing Request [RFC2986]. A server
SHOULD verify that its configuration supports the features advertised
in the credentials presented to a client requesting connection.
This document describes the use of the TLS feature in PKIX end-entity
certificates and Certificate Signing Certificates. A mechanism that
MAY be used to describe support for the specified features in-band
for the most commonly used certificate registration protocol is also
provided.
4. Syntax
See Appendix A for an ASN.1 module
The TLS feature extension has the following format:
id-pe-tlsfeature OBJECT IDENTIFIER ::= { id-pe 24 }
Features ::= SEQUENCE OF INTEGER
The extnValue of the id-pe-tlsfeature extension is the ASN.1 DER
encoding of the Features structure.
The TLS feature extension SHOULD NOT be marked critical. RFC 5280
[RFC5280] requires that implementations that do not understand
critical extensions MUST reject the certificate. Marking the TLS
feature extension critical breaks backward compatibility and is not
recommended unless this is the desired behavior.
4.1. TLS Feature
The object member "Features" is a sequence of TLS extension
identifiers (features, in this specification's terminology) as
specified in the IANA Transport Layer Security (TLS) Extensions
registry. If these features are requested by the client in its
ClientHello message, then the server MUST return a ServerHello
message that satisfies this request.
This specification does not require a TLS client to offer or support
any TLS feature regardless of whether or not it is specified in the
server certificate's TLS feature extension. In particular, a client
MAY request and a server MAY support any TLS extension regardless of
whether or not it is specified in a TLS feature extension.
A server that offers a certificate that contains a TLS feature
extension MUST support the features specified and comply with the
corresponding requirements.
4.2. Use
4.2.1. Certificate Signing Request
If the certificate issue mechanism makes use of the PKCS #10
Certificate Signing Request (CSR) [RFC2986], the CSR MAY specify a
TLS feature extension as a CSR Attribute as defined in Section 4.1 of
[RFC2986]. A server or server administration tool should only
generate key signing requests that it knows can be supported by the
server for which the certificate is intended.
4.2.2. Certificate Signing Certificate
When present in a Certificate Signing Certificate (i.e.,
Certification Authority certificate with the key usage extension
value set to keyCertSign), the TLS feature extension specifies a
constraint on valid certificate chains. Specifically, a certificate
that is signed by a Certificate Signing Certificate that contains a
TLS feature extension MUST contain a TLS feature extension that
offers the same set or a superset of the features advertised in the
signing certificate.
This behavior provides a means of requiring support for a particular
set of features for certificates issued under a particular
Certificate Signing Certificate without requiring TLS clients to
verify compliance with TLS feature extensions in multiple
certificates.
4.2.3. End-Entity Certificate
When specified in a server end-entity certificate (i.e., a
certificate that specifies the id-kp-serverAuth Extended Key Usage
(EKU)), the TLS feature extension specifies criteria that a server
MUST meet to be compliant with the feature declaration.
In the case that a client determines that the server configuration is
inconsistent with the specified feature declaration, it MAY reject
the TLS configuration.
4.2.3.1. TLS status_request
In the case that a client determines that the server configuration is
inconsistent with a feature declaration specifying support for the
TLS status_request extension, it SHOULD reject the TLS configuration.
A client MAY accept a TLS configuration despite it being inconsistent
with the TLS feature declaration if the validity of the certificate
chain presented can be established through other means (for example,
by successfully obtaining the OCSP data from another source).
There are certain situations in which the alternative to establishing
a connection with imperfect TLS security is to transmit the same
information with no security controls whatsoever. Accordingly, a
client MAY accept a TLS configuration despite it being inconsistent
with the TLS feature declaration but MUST NOT distinguish that
connection as secure.
4.3. Processing
Advertising a TLS feature extension may change the expectations of
relying parties. If these expectations are not met, a valid
certificate may be rejected as invalid. Particular attention is
required at the start of a certificate lifecycle. A server will be
unable to comply with a TLS feature extension if the certificate is
issued and released to the subject before the corresponding status
token is published.
4.3.1. Certification Authority
A Certification Authority SHOULD NOT issue certificates with a TLS
feature extension unless there is an affirmative statement to the
effect that the end entity intends to support the specified features
(for example, the use of a feature extension in the CSR or through an
out-of-band communication).
A Certification Authority SHOULD ensure that the certificate
provisioning process for certificates containing a TLS feature
extension permits the certificate subject to meet the requirements
(for example, ensuring that OCSP tokens are published before the
corresponding certificate is released to the subscriber).
4.3.2. Server
A TLS server certificate containing a TLS feature extension MAY be
used with any TLS server that supports the specified features. It is
not necessary for the server to provide support for the TLS feature
extension itself. Such support is nevertheless desirable as it can
reduce the risk of administrative error.
A server SHOULD verify that its configuration is compatible with the
TLS feature extension expressed in a certificate it presents. When
an existing certificate is to be replaced by a new one, the server
SHOULD NOT begin using the new certificate until the necessary OCSP
status token or tokens are available.
A server MAY override local configuration options if necessary to
ensure consistency, but it SHOULD inform the administrator whenever
such an inconsistency is discovered.
A server SHOULD support generation of the feature extension in CSRs
if key generation is supported.
4.3.3. Client
A client MUST treat a certificate with a TLS feature extension as an
invalid certificate if the features offered by the server do not
contain all features present in both the client's ClientHello message
and the TLS feature extension.
In the case that use of TLS with a valid certificate is mandated by
explicit security policy, application protocol specification, or
other means, the client MUST refuse the connection. If the use of
TLS with a valid certificate is optional, a client MAY accept the
connection but MUST NOT treat the certificate as valid.
5. Security Considerations
5.1. Alternative Certificates and Certificate Issuers
Use of the TLS feature extension to mandate support for a particular
form of revocation checking is optional. This control can provide
protection in the case that a certificate with a TLS feature is
compromised after issue but not in the case that the attacker obtains
an unmarked certificate from an issuer through fraud.
The TLS feature extension is a post-issue security control. Such
risks can only be addressed by security controls that take effect
before issue.
5.2. Denial of Service
A certificate issuer could issue a certificate that intentionally
specified a feature statement that they knew the server could not
support.
The consequences of such refusal would appear to be limited since a
Certification Authority could equally refuse to issue the
certificate.
5.3. Cipher Suite Downgrade Attack
The TLS feature extension does not provide protection against a
cipher suite downgrade attack. This is left to the existing controls
in the TLS protocol itself.
6. IANA Considerations
IANA has added the following entry in the "SMI Security for PKIX
Certificate Extension" (1.3.6.1.5.5.7.1) registry:
Decimal Description References
------- ------------------------------ ---------------------
24 id-pe-tlsfeature this document (RFC 7633)
IANA has added the following entry in the "SMI Security for PKIX
Module Identifier" (1.3.6.1.5.5.7.0) registry:
Decimal Description References
------- ------------------------------ ---------------------
86 id-mod-tls-feature-2015 this document (RFC 7633)
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<http://www.rfc-editor.org/info/rfc2986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013,
<http://www.rfc-editor.org/info/rfc6844>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
Appendix A. ASN.1 Module
TLS-Feature-Module-2015 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-tls-feature-2015(86)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS -- From RFC 5912
id-pe
FROM PKIX1Explicit-2009 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
EXTENSION
FROM PKIX-CommonTypes-2009 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)}
;
CertExtensions EXTENSION ::= {
ext-TLSFeatures, ... }
-- TLS Features Extension
ext-TLSFeatures EXTENSION ::= { SYNTAX
Features IDENTIFIED BY id-pe-tlsfeature }
id-pe-tlsfeature OBJECT IDENTIFIER ::= { id-pe 24 }
Features ::= SEQUENCE OF INTEGER
END
Acknowledgements
This proposal incorporates text and other contributions from
participants in the IETF and CA-Browser forum -- in particular, Robin
Alden, Richard Barnes, Viktor Dukhovni, Stephen Farrell, Gervase
Markham, Yoav Nir, Tom Ritter, Jeremy Rowley, Stefan Santesson, Ryan
Sleevi, Brian Smith, Rob Stradling, and Sean Turner.
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
AI ELI5
On this page
PROBLEMA client cannot conclude anything from a missing OCSP stapled response, because the server may not support stapling or may be hiding the response on purpose because the certificate is invalid.
MECHANISMThe TLS feature extension is an X.509v3 certificate extension that lists TLS extension identifiers the server must support, such as status_request. A client that sees the feature listed can fail immediately when the server does not deliver it.
WHY IT MATTERSClients no longer have to query the OCSP responder when the staple is absent, which removes a denial-of-service opening. The extension protects against downgrades only for certificates that carry it.
§1The Problem With a Missing Staple
RFC 7633 is a Standards Track document. It defines a way to prevent downgrade attacks that the TLS protocol does not already prevent. The RFC says TLS itself protects strongly against most downgrades, including attacks on cipher suite choices and client credentials, so this extension is relevant only to validating TLS credentials.
The main case is revocation checking. With OCSP stapling (RFC 6066 and RFC 6961) a TLS server supplies proof of valid certificate status inside the handshake. That avoids the privacy, performance and reliability problems of making a third-party connection mid-handshake.
The weakness is the absent staple. A client cannot draw a conclusion from missing status information unless it knows the real server would have sent it. The server may simply not support stapling, or it may be withholding the response because it knows the certificate is invalid.
If a shop is supposed to show you a fresh safety certificate and it shows nothing, you cannot tell if it forgot or is hiding something. A note on the shop's licence saying 'must always show it' settles that.
§2Two Meanings of Extension
Both X.509 and TLS use the word extension. To avoid confusion, this document reserves the term extension for X.509v3 certificate extensions. It uses TLS feature extension for what RFC 5246 calls an extension in the TLS protocol.
The only TLS features relevant to revocation status are status_request and status_request_v2 (Multiple Certificate Status). Both carry OCSP tokens in-band.
The same word means two different things here, like 'bat' for an animal and 'bat' for baseball. The RFC picks clear names so nobody mixes them up.
§3The TLS Feature Extension
The extension is identified by id-pe-tlsfeature, defined as { id-pe 24 }. Its value is the DER encoding of Features ::= SEQUENCE OF INTEGER. Each integer is a TLS extension identifier taken from the IANA TLS Extensions registry.
The extension SHOULD NOT be marked critical. RFC 5280 requires implementations to reject certificates with critical extensions they do not understand, so marking it critical breaks backward compatibility unless that is the intent.
If the client requests one of the listed features in its ClientHello, the server MUST return a ServerHello that satisfies the request. A server offering a certificate with this extension MUST support the listed features. The RFC does not require a client to offer or support any feature, whether or not the certificate lists it.
The note is just a list of feature numbers written in the certificate. The server promises to support everything on the list.
ASN.1 definition
id-pe-tlsfeature OBJECT IDENTIFIER ::= { id-pe 24 }
Features ::= SEQUENCE OF INTEGER§4Where It Is Used and Who Does What
The extension can appear in three places. In a PKCS #10 Certificate Signing Request (RFC 2986) it may be given as a CSR attribute, so a server can tell the Certification Authority (CA) what it supports. In a CA certificate (key usage keyCertSign) it constrains chains: a certificate signed by such a CA MUST carry the same set of features or a superset. In a server end-entity certificate (EKU id-kp-serverAuth) it states what the server MUST provide.
A CA SHOULD NOT issue the extension unless the end entity has said it intends to support the features, and SHOULD make sure OCSP tokens are published before the certificate is released. A server SHOULD verify its configuration matches the certificate, and SHOULD NOT start using a replacement certificate until the needed OCSP tokens are available.
A client MUST treat the certificate as invalid if the server's features do not include everything present in both the ClientHello and the extension. If valid TLS is mandated by policy or the application protocol, the client MUST refuse the connection. Otherwise it MAY continue but MUST NOT treat the certificate as valid.
The shop asks for the note, the licence office only adds it if the shop can really do it, and the visitor leaves if the shop breaks the promise.
§5Security Considerations
Using the extension is optional, and it is a post-issue control. It helps when a certificate carrying the feature is compromised after issue. It does not help when an attacker obtains an unmarked certificate from an issuer through fraud, which needs controls that act before issue, such as CAA records (RFC 6844).
A CA could issue a certificate demanding a feature it knows the server cannot support. The RFC judges the consequences limited, since the CA could equally refuse to issue the certificate. The extension also gives no protection against cipher suite downgrade, which is left to TLS itself.
The note only helps for certificates that carry it. A crook with a plain certificate with no note is not stopped by this.
§6IANA Registrations
IANA added id-pe-tlsfeature as decimal 24 in the SMI Security for PKIX Certificate Extension registry (1.3.6.1.5.5.7.1). It also added id-mod-tls-feature-2015 as decimal 86 in the PKIX Module Identifier registry (1.3.6.1.5.5.7.0). Appendix A gives the ASN.1 module.
The official list of numbers got two new entries so everyone uses the same number for this note.
§7References
[RFC2986]RFC 2986Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.November 2000[RFC5246]RFC 5246Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.August 2008[RFC5280]RFC 5280Cooper, D., et al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.May 2008[RFC6066]RFC 6066Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.January 2011[RFC6844]RFC 6844Hallam-Baker, P. and R. Stradling, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, January 2013.January 2013[RFC6961]RFC 6961Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, June 2013.June 2013