[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 draft-ietf-tls-cached-info
INTERNET-DRAFT S. Santesson (AAA-sec)
Intended Status: Proposed Standard
Expires September 2009 March 2009
TLS Cached Certificates Extension
<draft-santesson-tls-certcache-00.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document defines a Transport Layer Security (TLS) extension for
cached certificates. This extension allows the TLS client to inform a
server of a previously cached server certificate path, allowing the
server to omit sending an identified certificate chain to the client
during the TLS handshake protocol exchange.
1. Introduction
A server certificate sent to the client during a TLS handshake can be
of considerable size. This is the case in particular if the server
certificate is bundled with a complete certificate path, including
all intermediary certificates up to the trust anchor public key.
Significant benefits can be achieved in low bandwidth and high
Santesson [Page 1]
INTERNET DRAFT TLS Cached Certificates Extension March 2009
latency networks, in particular if the communication channel also has
a relatively high rate of transmission errors, if a known and
previously cached server certificate path can be omitted from the TLS
handshake.
This specification defines the CertCache TLS extension, which may be
used by a client to and a server to omit sending known certificate
data in the Server Certificate message.
1.1 Terminology
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 [N1].
2 Cached Certs Extension
A new extension type (cached_certs(TBD)) is defined and used in both
the client hello and server hello messages. The extension type is
specified as follows.
enum {
cached_certs(TBD), (65535)
} ExtensionType;
The "extension_data" field of this extension SHALL contain
"CachedCerts" containing a hash of cached server certificates:
struct {
opaque certificate_hash; <1..2^8-1>
} CachedCerts;
The certificate_hash value MUST include at least one hash value
calculated over an expected certificate_list element of a server side
Certificate message.
The hash algorithm used to generate hash included in certificate_hash
MUST be SHA-1.
4 Message flow
In order to allow negotiation to omit certificate data in the Server
Certificate message, the client MUST include an extension of type
"cached_certs" in the (extended) client hello, which SHALL contain at
Santesson [Page 2]
INTERNET DRAFT TLS Cached Certificates Extension March 2009
least one certificate hash as specified in section 2.
Servers that receive an extended client hello containing a
"cached_certs" extension, MAY indicate that they are willing to
accept omitting certificate data in the Server Certificate message by
including an extension of type "cached_certs" in the (extended)
server hello, which SHALL contain a hash received in the cached_certs
extension from the client, which is a complete hash calculated over
all omitted certificates.
After negotiation of the use of cached certificates has been
successfully completed (by exchanging hello messages including
"cached_certs" extensions), the server MAY replace the
certificate_list element in its Certificate message with the hash
included in the cached_certs extension of the server hello message.
All operations of the handshake protocol will be processed as if the
hash value carried in the certificate_list element is the actual bits
of the server certificate path, with the only exception that all
public key operations will be done using the real certificates and
associated keys identified by the hash value. For example hash and
length values in the Finished message will be calculated over the
modified Server Certificate message (with omitted certificate data)
that was sent to the client.
Santesson [Page 3]
INTERNET DRAFT TLS Cached Certificates Extension March 2009
5 Security Considerations
The use of hash algorithm in this specification requires reasonable
random properties in order to provide unique identifiers. No security
threat requires the hash algorithm to have strong collision
resistance. Consequently, there is no reason to provide hash agility
at the cost of protocol complexity.
6 IANA Considerations
TBD
7 Normative References
[N1] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
TBD
Santesson [Page 4]
INTERNET DRAFT TLS Cached Certificates Extension March 2009
Authors' Addresses
Stefan Santesson
AAA-sec AB
Bjornstorp 744
247 98 Genarp
Sweden
EMail: stefan@aaa-sec.com
Full Copyright Statement
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/licenseinfo).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Expires September 2009
Santesson [Page 5]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/