Internet Engineering Task Force                       P. M. Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended status: Standards Track                          March 26, 2013
Expires: September 27, 2013


                     X.509v3 TLS Feature Extension
                    draft-hallambaker-tlsfeature-00

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 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 27, 2013.

Copyright Notice

   Copyright (c) 2013 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



Hallam-Baker           Expires September 27, 2013               [Page 1]


Internet-Draft       X.509v3 TLS Feature Extension            March 2013


   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.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
     1.2.  TLS Feature . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  TLS Feature . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  status_request  . . . . . . . . . . . . . . . . . . .   4
     3.2.  Use . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Certificate Signing Request . . . . . . . . . . . . .   5
       3.2.2.  Certificate Signing Certificate . . . . . . . . . . .   5
       3.2.3.  End Entity Certificate  . . . . . . . . . . . . . . .   5
     3.3.  Processing  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  Certification Authority . . . . . . . . . . . . . . .   6
       3.3.2.  Server  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.3.  Client  . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     5.1.  Alternative Certificates and Certificate Issuers  . . . .   6
     5.2.  Denial of Service . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Cipher Suite Downgrade Attack . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Definitions

1.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].

1.2.  TLS Feature

   In order to avoid the confusion that would occur in attempting to
   describe 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 'feature' is used to refer to a TLS
   extension.

2.  Purpose




Hallam-Baker           Expires September 27, 2013               [Page 2]


Internet-Draft       X.509v3 TLS Feature Extension            March 2013


   The purpose of the TLS Feature extension is to prevent 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, the TLS Feature is only relevant to the
   validation of TLS protocol credentials.  In particular to the
   revocation status of the credentials presented.

   At the time of writing, the only TLS feature that is relevant to the
   revocation status of credentials is the Certificate Status Request
   extension (status_request) used to support in-band exchange of OCSP
   tokens, otherwise known as OCSP stapling.  This extension is
   described in RFC 4366 [RFC4366].

   The OCSP stapling mechanism described in RFC 4366 [RFC4366] permits a
   TLS server to provide evidence of valid certificate status inband and
   thus improve client response.  A TLS Feature extension that
   advertises the status_request extension informs a client that if the
   status_request is specified in a TLS Client Helo, that a server
   compliant with the feature declaration MUST respond with a valid OCSP
   token for the End Entity Certificate it presents.

   Use of the TLS Feature extension in this fashion permits a client to
   avoid reliance on certificates that are revoked for the reasons that
   occur most frequently.  In particular it allows a client to avoid
   mis-reliance on certificates that are revoked for cause or at the
   request of the subject (e.g.  because of a compromised private key).

   Advertising the status_request feature permits a client to fail
   immediately in the case that the token is not provided by the server
   without the need to query the OCSP responder in addition.  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 approrpriately addressed by mechanisms such as Certificate
   Authority Authorization DNS records RFC 6844 [RFC6844] that are
   designed to prevent or mitigate mis-issue.  Nevertheless a
   Certification Authority MAY consider the presence or absence of a
   required TLS feature as one factor in determining the level of
   additional scruitiny a request should be subject to.

   Any TLS feature declaration specified in an End Entity certificate
   MUST be offered by the server or clients MAY refuse connection.  It



Hallam-Baker           Expires September 27, 2013               [Page 3]


Internet-Draft       X.509v3 TLS Feature Extension            March 2013


   is important therefore that a Certification Authority only issue
   certificates that specify policies that match the configuration of
   the server and that the server is capable of verifying that its
   configuration is compatible with the feature declaration of the
   certificates it offers.  Ideally, the TLS feature declaration would
   be specified by the certificate request generator as part of the
   certificate issue process.

   This document describes a mechanism that MAY be used to provide this
   communication in-band for the most commonly used certificate
   registration protocol.

3.  Syntax

   The TLS Feature extension has the following format:

   cabf-tls-feature OBJECT IDENTIFIER ::=  { cabf 1 }

   Features ::= SEQUENCE OF INTEGER


   The TLS Feature Extension MAY be marked critical.  RFC 5280 [RFC5280]
   requires that implementations that do not understand the extension
   MUST reject the certificate.  Marking the TLS Feature Extension
   critical breaks backward compatibility and is not recommended unless
   this is the desired behavior.  Implementations that process the
   extension MUST ignore the criticality bit setting.

3.1.  TLS Feature

   The TLS Feature extension lists a sequence of TLS extension
   identifiers that a server compliant with the feature declaration MUST
   support and accept on client request.

   This specification does not require a TLS client to offer or support
   any TLS extension regardless of whether it is specified in the TLS
   Feature or not.  In particular a client MAY request and a server MAY
   support any TLS extension regardless of whether it is specified in a
   TLS Feature extension or not.

   If a TLS Feature extension specifies a TLS extension, a server
   offering the certificate MUST support the extension specified and
   MUST comply with any specific requirements specified for that
   extension in this document or in the document that specifies the TLS
   extension.

3.1.1.  status_request




Hallam-Baker           Expires September 27, 2013               [Page 4]


Internet-Draft       X.509v3 TLS Feature Extension            March 2013


   If the TLS status_request extension is specified in the TLS Feature
   extension and a TLS client specifies the status_request extensionin
   the Client Hello, a server MUST return a valid OCSP token for the
   specified End Entity certificate in the response.

3.2.  Use

3.2.1.  Certificate Signing Request

   If the certificate issue mechanism makes use of the PKCS#10
   Certificate Signing Request (CSR) RFC 4366 [RFC4366], the CSR MAY
   specify a TLS Feature extension as a CSR attribute.  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.

3.2.2.  Certificate Signing Certificate

   When present in a Certificate Signing Certificate, 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 which MUST offer the same set or a superset of the
   features advertised in the signing certificate.

   While relying clients MAY reject certificates that do not comply with
   this requirement, the use of TLS Feature extension in Certificate
   Signing Certificates is primarily intended for use by parties seeking
   to evaluate the performance of certificate issuers and MAY be ignored
   by clients.

3.2.3.  End Entity Certificate

   When specified in an End Entity Certificate, 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.

   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.

3.3.  Processing





Hallam-Baker           Expires September 27, 2013               [Page 5]


Internet-Draft       X.509v3 TLS Feature Extension            March 2013


3.3.1.  Certification Authority

   A CA SHOULD NOT issue certs with a 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.

3.3.2.  Server

   The TLS Feature extension MAY be used with any TLS server regardless
   of whether the server offers support.  Server support for the TLS
   Feature extension 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.  A
   server MAY override local configuration options if necessary to
   ensure consistency but SHOULD inform the administrator whenever such
   an inconsitency is discovered.

   A server SHOULD support generation of the Feature extension in CSRs
   if key generation is supported.

3.3.3.  Client

   A compliant client MUST process the TLS Feature Extension and MUST
   ignore the setting of the X.509 criticality flag.

   A compliant client SHOULD reject a TLS connection with security
   properties that are inconsistent with the specified TLS Feature
   extension.  A compliant client MAY accept such a TLS connection
   request however if it is determined that doing so is appropriate in
   particular circumstances.

4.  Acknowledgements

   [List of CABForum and PKIX contributors]

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.




Hallam-Baker           Expires September 27, 2013               [Page 6]


Internet-Draft       X.509v3 TLS Feature Extension            March 2013


   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 risks of such refusal would appear to be negligible since a
   Certificate 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

   No action by IANA is required.

7.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [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, May 2008.

   [RFC6844]  Hallam-Baker, P. and R. Stradling, "DNS Certification
              Authority Authorization (CAA) Resource Record", RFC 6844,
              January 2013.








Hallam-Baker           Expires September 27, 2013               [Page 7]


Internet-Draft       X.509v3 TLS Feature Extension            March 2013


   [X.509]    International Telecommunication Union , "ITU-T
              Recommendation X.509 (11/2008): Information technology -
              Open systems interconnection - The Directory: Public-key
              and attribute certificate frameworks ", ITU-T
              Recommendation X.509, November 2008.

   [X.680]    International Telecommunication Union , "ITU-T
              Recommendation X.680 (11/2008): Information technology -
              Abstract Syntax Notation One (ASN.1): Specification of
              basic notation ", ITU-T Recommendation X.680, November
              2008.

Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   Email: philliph@comodo.com
































Hallam-Baker           Expires September 27, 2013               [Page 8]