idnits 2.17.1 draft-ietf-tls-cached-info-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (September 15, 2009) is 5335 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: March 19, 2010 September 15, 2009 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 Internet- 17 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 Notice 32 Copyright (c) 2009 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 in effect on the date of 37 publication of this document (http://trustee.ietf.org/license-info). 38 Please review these documents carefully, as they describe your rights 39 and restrictions with respect to this document. 41 Abstract 43 This document defines a Transport Layer Security (TLS) extension for 44 cached information. This extension allows the TLS client to inform a 45 server of cached information from previous TLS sessions, allowing the 46 server to omit sending cached static information to the client during 47 the TLS handshake protocol exchange. 49 Table of Contents 51 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2 Cached Information Extension . . . . . . . . . . . . . . . . . . 3 53 4 Message flow . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 4 55 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 7 Normative References . . . . . . . . . . . . . . . . . . . . . . 5 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 59 1 Introduction 61 TLS handshakes often include fairly static information such as server 62 certificate and a list of trusted Certification Authorities (CAs). 63 Static information such as a server certificate can be of 64 considerable size. This is the case in particular if the server 65 certificate is bundled with a complete certificate path, including 66 all intermediary certificates up to the trust anchor public key. 68 Significant benefits can be achieved in low bandwidth and high 69 latency networks, in particular if the communication channel also has 70 a relatively high rate of transmission errors, if a known and 71 previously cached server certificate path can be omitted from the TLS 72 handshake. 74 This specification defines the Cached Information TLS extension, 75 which may be used by a client and a server to exclude transmission of 76 known cached parameters from the TLS handshake. 78 1.1 Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2 Cached Information Extension 86 A new extension type (cached_information(TBD)) is defined and used in 87 both the client hello and server hello messages. The extension type 88 is specified as follows. 90 enum { 91 cached_information(TBD), (65535) 92 } ExtensionType; 94 The "extension_data" field of this extension, when included in the 95 client hello, SHALL contain "CachedInformation" according to the 96 following structure: 98 enum { 99 certificate_chain(1), trusted_cas(2), (255) 100 } CachedInformationType; 102 struct { 103 HashAlgorithm hash; 104 opaque hash_value<1..255>; 105 } CachedInformationHash; 107 struct { 108 CachedInformationType type; 109 CachedInformationHash hashes<1..2^16-1>; 110 } CachedObject; 112 struct { 113 CachedObject cached_info<1..2^24-1>;; 114 } CachedInformation; 116 Hash algorithm identifiers are provided by the RFC 5246 [RFC5246] 117 HashAlgorithm registry. Compliant implementations MUST support 118 sha1(2) as HashAlgorithm. 120 When CachedInformationType identifies certificate_chain, then 121 hash_value MUST include at least one hash value calculated over the 122 certificate_list element of a server side Certificate message. 124 When CachedInformationType identifies trusted_cas, then hash_value 125 MUST include at least one hash value calculated over the 126 certificate_authorities element of a server side CertificateRequest 127 message. 129 The client MUST NOT include hashes for multiple objects in the same 130 CachedObject structure. If more than one hash is present in the 131 CachedObject structure, they MUST be hashes over the same information 132 object using different hash algorithms. 134 Other specifications MAY define more CachedInformationType types. 136 4 Message flow 138 Clients MAY include an extension of type "cached_information" in the 139 (extended) client hello, which SHALL contain at least one 140 CachedObject as specified in section 2. Clients MAY need the ability 141 to cache different values depending on other information in the 142 Client Hello that modify what values the server uses, in particular 143 the Server Name Indication [RFC4366] value. 145 Servers that receive an extended client hello containing a 146 "cached_information" extension, MAY indicate that they support 147 caching of information objects by including an extension of type 148 "cached_information" with an empty extension_data field in their 149 (extended) server hello. 151 Following a successful exchange of "cached_information" extensions, 152 the server may replace data objects identified through the client 153 extension with any of the CachedInformationHash values received from 154 the client, which matches the replaced object. 156 The handshake protocol will proceed using the cached data as if it 157 was provided in the handshake protocol. The Finished message will 158 however be calculated over the actual data exchanged in the handshake 159 protocol. That is, the Finished message will be calculated over the 160 hash values of cached information objects and not over the cached 161 objects that were omitted from transmission. 163 5 Security Considerations 165 Hash algorithms used in this specification are required to have 166 reasonable random properties in order to provide reasonably unique 167 identifiers. Failure of a provided hash to correctly and uniquely 168 identify the correct set of hashed parameters may at most lead to a 169 failed TLS handshake followed by a new attempt without the cached 170 information extension. No serious security threat requires selected 171 hash algorithms to have strong collision resistance. 173 6 IANA Considerations 175 1) Create an entry, cached_information(TBD), in the existing registry 176 for ExtensionType (defined in RFC 5246 [RFC5246]). 178 2) Establish a registry for TLS CachedInformationType values. The 179 first entries in the registry are certificate_chain(1) and 180 trusted_cas(2). TLS CachedInformationType values in the inclusive 181 range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards 182 Action. Values from the inclusive range 64-223 (decimal) are 183 assigned via RFC 5226 Specification Required. Values from the 184 inclusive range 224-255 (decimal) are reserved for RFC 5226 185 Private Use. 187 7 Normative References 189 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, March 1997 192 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 193 Considerations Section in RFCs", RFC 5226, May 2008 195 [RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security 196 (TLS) Protocol Version 1.2", RFC 5246, August 2008 198 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 199 Wright, "Transport Layer Security (TLS) Extensions", RFC 200 4366, April 2006 202 NOTE: RFC 4366 will be updated by RFC4366bis, currently in IESG 203 process. 205 Authors' Addresses 207 Stefan Santesson 209 3xA Security AB 210 Bjornstorp 744 211 247 98 Genarp 212 Sweden 214 EMail: sts@aaa-sec.com