| 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
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.
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 (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.
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.
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].
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].
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.
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:
Otherwise, server and client behavior is the same as for the "previous_certificate_chain" extension.
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.
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.
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.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4347] | Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. |
| [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. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. |