draft-ietf-tls-cached-info-15.txt   draft-ietf-tls-cached-info-16.txt 
TLS S. Santesson TLS S. Santesson
Internet-Draft 3xA Security AB Internet-Draft 3xA Security AB
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: April 20, 2014 Nokia Solutions and Networks Expires: August 18, 2014 ARM Ltd.
October 17, 2013 February 14, 2014
Transport Layer Security (TLS) Cached Information Extension Transport Layer Security (TLS) Cached Information Extension
draft-ietf-tls-cached-info-15.txt draft-ietf-tls-cached-info-16.txt
Abstract Abstract
Transport Layer Security (TLS) handshakes often include fairly static Transport Layer Security (TLS) handshakes often include fairly static
information, such as the server certificate and a list of trusted information, such as the server certificate and a list of trusted
Certification Authorities (CAs). This information can be of Certification Authorities (CAs). This information can be of
considerable size, particularly if the server certificate is bundled considerable size, particularly if the server certificate is bundled
with a complete certificate path (including all intermediary with a complete certificate chain (i.e., the certificates of
certificates up to the trust anchor public key). intermediate CAs up to the root CA).
This document defines an extension that omits the exchange of already This document defines an extension that allows a TLS client to inform
available information. The TLS client informs a server of cached a server of cached information, allowing the server to omit already
information, for example from a previous TLS handshake, allowing the available information.
server to omit the already available information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Cached Information Extension . . . . . . . . . . . . . . . . 3 3. Cached Information Extension . . . . . . . . . . . . . . . . 3
4. Exchange Specification . . . . . . . . . . . . . . . . . . . 4 4. Exchange Specification . . . . . . . . . . . . . . . . . . . 4
4.1. Omitting the Certificate Chain . . . . . . . . . . . . . 5 4.1. Omitting the Certificate Chain . . . . . . . . . . . . . 5
4.2. Omitting the Trusted CAs . . . . . . . . . . . . . . . . 6 4.2. Omitting the Trusted CAs . . . . . . . . . . . . . . . . 5
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 8 7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 8
7.2. New Registry for CachedInformationType . . . . . . . . . 8 7.2. New Registry for CachedInformationType . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Transport Layer Security (TLS) handshakes often include fairly static Transport Layer Security (TLS) handshakes often include fairly static
information, such as the server certificate and a list of trusted information, such as the server certificate and a list of trusted
Certification Authorities (CAs). This information can be of Certification Authorities (CAs). This information can be of
considerable size, particularly if the server certificate is bundled considerable size, particularly if the server certificate is bundled
with a complete certificate path (including all intermediary with a complete certificate chain (i.e., the certificates of
certificates up to the trust anchor public key). intermediate CAs up to the root CA).
Optimizing the exchange of information to a minimum helps to improve Optimizing the exchange of information to a minimum helps to improve
performance in environments where devices are connected to a network performance in environments where devices are connected to a network
with characteristics like low bandwidth, high latency and high loss with a low bandwidth, and lossy radio technology. These types of
rate. These types of networks exist, for example, when smart objects environments exist, for example, when smart objects are connected
are connected using a low power IEEE 802.15.4 radio. For more using a low power IEEE 802.15.4 radio or via Bluetooth Low Energy.
information about the challenges with smart object deployments please For more information about the challenges with smart object
see [RFC6574]. deployments please see [RFC6574].
This specification defines a TLS extension that allows a client and a This specification defines a TLS extension that allows a client and a
server to exclude transmission of cached information from the TLS server to exclude transmission of cached information from the TLS
handshake. handshake.
A typical example exchange may therefore look as follows. First, the A typical example exchange may therefore look as follows. First, the
client and the server executes the usual TLS handshake. The client client and the server executes the usual TLS handshake. The client
may, for example, decide to cache the certificate provided by the may, for example, decide to cache the certificate provided by the
server. When the TLS client connects to the TLS server some time in server. When the TLS client connects to the TLS server some time in
the future, without using session resumption, it then attaches the the future, without using session resumption, it then attaches the
cached_information extension defined in this document to the client cached_information extension defined in this document to the client
hello message to indicate that it had cached the certificate, and it hello message to indicate that it had cached the certificate, and it
provides the fingerprint of it. If the server's certificate had not provides the fingerprint of it. If the server's certificate had not
changed then the TLS server does not need to send the full changed then the TLS server does not need to send the complete
certificate to the client again. In case the information had certificate chain to the client again. In case the information had
changed, the certificate payload is transmitted to the client to changed, the certificate payload is transmitted to the client to
allow the client to update it's state information. allow the client to update its state information.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Cached Information Extension 3. Cached Information Extension
This document defines a new extension type (cached_information(TBD)), This document defines a new extension type (cached_information(TBD)),
skipping to change at page 9, line 41 skipping to change at page 9, line 29
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
9.2. Informative References 9.2. Informative References
[I-D.ietf-tls-oob-pubkey] [I-D.ietf-tls-oob-pubkey]
Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Out-of-Band Public Key Validation for T. Kivinen, "Using Raw Public Keys in Transport Layer
Transport Layer Security (TLS)", draft-ietf-tls-oob- Security (TLS) and Datagram Transport Layer Security
pubkey-09 (work in progress), July 2013. (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
January 2014.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, April 2012. Workshop", RFC 6574, April 2012.
Authors' Addresses Authors' Addresses
skipping to change at page 10, line 14 skipping to change at page 10, line 4
Authors' Addresses Authors' Addresses
Stefan Santesson Stefan Santesson
3xA Security AB 3xA Security AB
Scheelev. 17 Scheelev. 17
Lund 223 70 Lund 223 70
Sweden Sweden
Email: sts@aaa-sec.com Email: sts@aaa-sec.com
Hannes Tschofenig Hannes Tschofenig
Nokia Solutions and Networks ARM Ltd.
Linnoitustie 6 110 Fulbourn Rd
Espoo 02600 Cambridge CB1 9NJ
Finland Great Britain
Phone: +358 (50) 4871445 Email: Hannes.tschofenig@gmx.net
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 17 change blocks. 
34 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/