Internet DRAFT - draft-weimer-tls-previous-certificate

draft-weimer-tls-previous-certificate






TLS                                                               Weimer
Internet-Draft                                                   Red Hat
Intended status: Informational                         November 12, 2012
Expires: May 16, 2013


TLS Extension For Indicating A Previously-Seen Server Certificate Chain
                draft-weimer-tls-previous-certificate-01

Abstract

   This document describes a TLS extension which enables a TLS client to
   send to a TLS server a certificate chain which the client has
   previously received from the same server.  Server operators are
   expected to use this information to detect use of fraudulent
   certificates on the Internet.

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 May 16, 2013.

Copyright Notice

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



Weimer                    Expires May 16, 2013                  [Page 1]

Internet-Draft     Previous Certificate TLS Extension      November 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Extension Definitions . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Extension for large certificate chains  . . . . . . . . . . 4
     2.2.  Server-Side Processing  . . . . . . . . . . . . . . . . . . 5
   3.  Interaction With Client Certificates  . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6








































Weimer                    Expires May 16, 2013                  [Page 2]

Internet-Draft     Previous Certificate TLS Extension      November 2012


1.  Introduction

   The TLS protocol [RFC5246] does not provide any non-cryptographic
   mechanism to detect which server certificates are in use.  The OCSP
   protocol [RFC2560] does not embed the actual certificate in requests,
   which means that certificate authorities are not able to detect
   unexpected certificates, either.

   This document describes an extension which a TLS client can use
   during the TLS handshake to send back to a server the certificate
   chain that the client has seen during a previous connection attempt
   (presumably the last).  The server operator can analyze incoming
   certificates and investigate those which it has not obtained itself.

   It is expected that attackers simply strip the extension, to avoid
   alerting server operators.  However, assuming that a subset of the
   clients which are exposed to a fraudulent certificate are mobile,
   some of them will eventually move to a network which provides a clear
   path to the server.  At this point, the server will receive the
   fraudulent certificate, and the server operator can initiate
   countermeasures.

   Compared to client-side detection, server-side detection has the
   advantage that the client user interface does not need changing.
   Additionally, the server operator is in a better position to tell
   fraudulent from authorized certificates.

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


2.  Extension Definitions

   In order to send a previously-encountered server certificate chain,
   clients MAY include an extension of type "previous_certificate_chain"
   in the client hello, with extension type TBD.

   The "extension_data" field of this extension SHALL contain a
   "PreviousCertificateChain" structure, which is defined as:

   struct {
       Certificate certificate;
   } PreviousCertificateChain;

   This extension can be used with DTLS [RFC4347].



Weimer                    Expires May 16, 2013                  [Page 3]

Internet-Draft     Previous Certificate TLS Extension      November 2012


   The client MUST take the certificate chain from the "certificate"
   message in a previous, successful TLS handshake with the same
   endpoint, and include it in the "certificate" field.  The most recent
   handshake matching these criteria SHOULD be used.  Two endpoints are
   the same if they have the same name or address, as supplied by the
   user or an application protocol which uses TLS.  Successful
   handshakes MAY include those where the user has overridden
   certificate validaty or trust checks.

   If the certificate chain does not fit into the client hello, the
   extension defined in the next section SHOULD be used.

   A TLS server MAY ignore this extension.  It MUST NOT assume a
   particular order of the presented certificates.  It SHOULD NOT
   include it in the server hello.  A client MUST ignore the extension
   if it is included in the server hello.

2.1.  Extension for large certificate chains

   The TLS protocol limits for certificate chain lengths exceed those
   for extension lengths.  An attacker can therefore evade detection by
   intentionally supplying a certificate chain which contains many
   certificates or a large certificate.  In order to address this
   problem, a client implementing the "previous_certificate_chain"
   extension SHOULD use the "large_previous_certificate_chain"
   extension.

   The "large_previous_certificate_chain" has type TBD, and the the
   "extension_data" field SHALL contain the "PreviousCertificateChain"
   structure defined above.

   The certificate chain in the "certificate" field SHOULD be prepared
   in the following manner:

      If the certificate chain that caused the client to accept the
      certificate as valid does not exceed the imposed size limit, this
      certificate chain MUST be used.

      Otherwise, if including the server certificate does not exceed the
      size limit, it SHOULD be included.

      The client should add as many certificates as possible, within the
      size constraint, starting at the trusted root CA and going down
      the chain.

   Otherwise, server and client behavior is the same as for the
   "previous_certificate_chain" extension.




Weimer                    Expires May 16, 2013                  [Page 4]

Internet-Draft     Previous Certificate TLS Extension      November 2012


   If a client is not able to process certificate chains at all which
   would exceed the limits implicitly imposed by the
   "previous_certificate_chain" extension, implementation of the
   "large_previous_certificate_chain" extension is OPTIONAL.

2.2.  Server-Side Processing

   No server-side processing is required.  It is expected that operators
   analyze incoming extensions on an intrusion detection system, and
   trigger internal alerts when unknown certificates chained to a global
   trust root are encountered.  This is possible because the extension
   is transmitted in the clear.


3.  Interaction With Client Certificates

   The extensions described above can and should be used with client
   certificates.

   Authentication with client certificates typically includes a hash
   (signed by the client) which covers the entire handshake.  Therefore,
   replacement of the server certificate by an attacker leads to a
   handshake failure.  Depending on how client certificate verification
   is implemented in the server, an attacker could obtain a successful
   handshake if the client certificate is replaced as well, but this is
   observable on the server side.


4.  Security Considerations

   The mechanism described in this document is by no means
   cryptographically strong.  It is the explicit goal of this document
   to provide detection capabilities which do not rely on cryptography
   and cryptography-related infrastructure.

   If a server dynamically generates its server certificate, it can
   recognize reconnecting clients.  In comparison to the session
   resumption mechanism built into TLS, this ability last for a longer
   time.  For privacy-sensitive applications, use of these extensions
   should be disabled or restricted.

   Clients may deliberately transmit incorrect certificate chains.  For
   the "previous_certificate_chain" extension, this can be detected on
   the server side because such a certificate chain will not be linked
   to a globally accepted root certificate.

   If a client downgrades its advertised TLS protocol version or set of
   extensions on handshake failures, an attacker may suppress sending



Weimer                    Expires May 16, 2013                  [Page 5]

Internet-Draft     Previous Certificate TLS Extension      November 2012


   these extensions, especially if the attacker can force the client to
   perform such a downgraded handshake after the fraudulent certificate
   has been used.


5.  Normative References

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

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.


Author's Address

   Florian Weimer
   Red Hat GmbH
   Wankelstrasse 5
   Stuttgart  70563
   DE

   Email: fweimer@redhat.com





















Weimer                    Expires May 16, 2013                  [Page 6]