Transport Layer Security (TLS) Cached Information Extension
RFC 7924
Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 7924 3xA Security AB
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 ARM Ltd.
July 2016
Transport Layer Security (TLS) Cached Information Extension
Abstract
Transport Layer Security (TLS) handshakes often include fairly static
information, such as the server certificate and a list of trusted
certification authorities (CAs). This information can be of
considerable size, particularly if the server certificate is bundled
with a complete certificate chain (i.e., the certificates of
intermediate CAs up to the root CA).
This document defines an extension that allows a TLS client to inform
a server of cached information, thereby enabling the server to omit
already available information.
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 7841.
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/rfc7924.
Santesson & Tschofenig Standards Track [Page 1]
RFC 7924 TLS Cached Information Extension July 2016
Copyright Notice
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Cached Information Extension . . . . . . . . . . . . . . . . 3
4. Exchange Specification . . . . . . . . . . . . . . . . . . . 5
4.1. Server Certificate Message . . . . . . . . . . . . . . . 6
4.2. CertificateRequest Message . . . . . . . . . . . . . . . 7
5. Fingerprint Calculation . . . . . . . . . . . . . . . . . . . 7
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. New Entry to the TLS ExtensionType Registry . . . . . . . 10
8.2. New Registry for CachedInformationType . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Santesson & Tschofenig Standards Track [Page 2]
RFC 7924 TLS Cached Information Extension July 2016
1. Introduction
Reducing the amount of information exchanged during a Transport Layer
Security handshake to a minimum helps to improve performance in
environments where devices are connected to a network with a low
bandwidth and lossy radio technology. With the Internet of Things,
such environments exist, for example, when devices use IEEE 802.15.4,
Bluetooth Low Energy, or low power wide area networks. For more
information about the challenges with smart object deployments,
please see [RFC6574].
This specification defines a TLS extension that allows a client and a
server to exclude transmission information cached in an earlier TLS
handshake.
A typical example exchange may therefore look as follows. First, the
client and the server execute the full TLS handshake. The client
then caches the certificate provided by the server. When the TLS
client connects to the TLS server some time in the future, without
using session resumption, it then attaches the "cached_info"
extension defined in this document to the ClientHello message to
Show full document text