Internet DRAFT - draft-weimer-tls-previous-certificate
draft-weimer-tls-previous-certificate
TLS Weimer
Internet-Draft BFK
Intended status: Informational September 26, 2011
Expires: March 29, 2012
TLS Extension For Indicating A Previously-Seen Server Certificate Chain
draft-weimer-tls-previous-certificate-00
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 March 29, 2012.
Copyright Notice
Copyright (c) 2011 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 March 29, 2012 [Page 1]
Internet-Draft Previous Certificate TLS Extension September 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Extension Definitions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Extension for large certificate chains . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Weimer Expires March 29, 2012 [Page 2]
Internet-Draft Previous Certificate TLS Extension September 2011
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 March 29, 2012 [Page 3]
Internet-Draft Previous Certificate TLS Extension September 2011
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.
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 March 29, 2012 [Page 4]
Internet-Draft Previous Certificate TLS Extension September 2011
3. 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
these extensions, especially if the attacker can force the client to
perform such a downgraded handshake after the fraudulent certificate
has been used.
4. 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.
Weimer Expires March 29, 2012 [Page 5]
Internet-Draft Previous Certificate TLS Extension September 2011
Author's Address
Florian Weimer
BFK edv-consulting GmbH
Kriegsstrasse 100
Karlsruhe 76133
DE
Email: fweimer@bfk.de
Weimer Expires March 29, 2012 [Page 6]
