idnits 2.17.1 draft-ietf-tls-cached-info-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2010) is 5181 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Santesson (3xA Security) 3 Intended Status: Proposed Standard 4 Expires: August 22, 2010 February 18, 2010 6 Transport Layer Security (TLS) Cached Information Extension 7 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Copyright and License Notice 32 Copyright (c) 2010 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. Code Components extracted from this document must 41 include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as 43 described in the BSD License. 45 Abstract 47 This document defines a Transport Layer Security (TLS) extension for 48 cached information. This extension allows the TLS client to inform a 49 server of cached information from previous TLS sessions, allowing the 50 server to omit sending cached static information to the client during 51 the TLS handshake protocol exchange. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2 Cached Information Extension . . . . . . . . . . . . . . . . . . 4 57 4 Message flow . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 59 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 7 Normative References . . . . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1 Introduction 65 TLS handshakes often include fairly static information such as server 66 certificate and a list of trusted Certification Authorities (CAs). 67 Static information such as a server certificate can be of 68 considerable size. This is the case in particular if the server 69 certificate is bundled with a complete certificate path, including 70 all intermediary certificates up to the trust anchor public key. 72 Significant benefits can be achieved in low bandwidth and high 73 latency networks, in particular if the communication channel also has 74 a relatively high rate of transmission errors, if a known and 75 previously cached server certificate path can be omitted from the TLS 76 handshake. 78 This specification defines the Cached Information TLS extension, 79 which may be used by a client and a server to exclude transmission of 80 known cached parameters from the TLS handshake. 82 1.1 Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 2 Cached Information Extension 90 A new extension type (cached_information(TBD)) is defined and used in 91 both the client hello and server hello messages. The extension type 92 is specified as follows. 94 enum { 95 cached_information(TBD), (65535) 96 } ExtensionType; 98 The "extension_data" field of this extension, when included in the 99 client hello, SHALL contain "CachedInformation" according to the 100 following structure: 102 enum { 103 certificate_chain(1), trusted_cas(2), (255) 104 } CachedInformationType; 106 struct { 107 HashAlgorithm hash; 108 opaque hash_value<1..255>; 109 } CachedInformationHash; 111 struct { 112 CachedInformationType type; 113 CachedInformationHash hashes<1..2^16-1>; 114 } CachedObject; 116 struct { 117 CachedObject cached_info<1..2^16-1>; 118 } CachedInformation; 120 Hash algorithm identifiers are provided by the RFC 5246 [RFC5246] 121 HashAlgorithm registry. Compliant implementations MUST support 122 sha1(2) as HashAlgorithm. 124 When CachedInformationType identifies certificate_chain, then 125 hash_value MUST include at least one hash value calculated over the 126 certificate_list element of a server side Certificate message. 128 When CachedInformationType identifies trusted_cas, then hash_value 129 MUST include at least one hash value calculated over the 130 certificate_authorities element of a server side CertificateRequest 131 message. 133 The client MUST NOT include hashes for multiple objects in the same 134 CachedObject structure. If more than one hash is present in the 135 CachedObject structure, they MUST be hashes over the same information 136 object using different hash algorithms. 138 Other specifications MAY define more CachedInformationType types. 140 4 Message flow 142 Clients MAY include an extension of type "cached_information" in the 143 (extended) client hello, which SHALL contain at least one 144 CachedObject as specified in section 2. Clients MAY need the ability 145 to cache different values depending on other information in the 146 Client Hello that modify what values the server uses, in particular 147 the Server Name Indication [RFC4366] value. 149 Servers that receive an extended client hello containing a 150 "cached_information" extension, MAY indicate that they support 151 caching of information objects by including an extension of type 152 "cached_information" with an empty extension_data field in their 153 (extended) server hello. 155 Following a successful exchange of "cached_information" extensions, 156 the server may replace data objects identified through the client 157 extension with any of the CachedInformationHash values received from 158 the client, which matches the replaced object. 160 The handshake protocol will proceed using the cached data as if it 161 was provided in the handshake protocol. The Finished message will 162 however be calculated over the actual data exchanged in the handshake 163 protocol. That is, the Finished message will be calculated over the 164 hash values of cached information objects and not over the cached 165 objects that were omitted from transmission. 167 5 Security Considerations 169 Hash algorithms used in this specification are required to have 170 reasonable random properties in order to provide reasonably unique 171 identifiers. Failure of a provided hash to correctly and uniquely 172 identify the correct set of hashed parameters may at most lead to a 173 failed TLS handshake followed by a new attempt without the cached 174 information extension. No serious security threat requires selected 175 hash algorithms to have strong collision resistance. 177 6 IANA Considerations 179 1) Create an entry, cached_information(TBD), in the existing registry 180 for ExtensionType (defined in RFC 5246 [RFC5246]). 182 2) Establish a registry for TLS CachedInformationType values. The 183 first entries in the registry are certificate_chain(1) and 184 trusted_cas(2). TLS CachedInformationType values in the inclusive 185 range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards 186 Action. Values from the inclusive range 64-223 (decimal) are 187 assigned via RFC 5226 Specification Required. Values from the 188 inclusive range 224-255 (decimal) are reserved for RFC 5226 189 Private Use. 191 7 Normative References 193 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, March 1997 196 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 197 Considerations Section in RFCs", RFC 5226, May 2008 199 [RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security 200 (TLS) Protocol Version 1.2", RFC 5246, August 2008 202 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 203 Wright, "Transport Layer Security (TLS) Extensions", RFC 204 4366, April 2006 206 NOTE: RFC 4366 will be updated by RFC4366bis, currently in IESG 207 process. 209 Authors' Addresses 211 Stefan Santesson 213 3xA Security AB 214 Bjornstorp 744 215 247 98 Genarp 216 Sweden 218 EMail: sts@aaa-sec.com