idnits 2.17.1 draft-ietf-tls-cached-info-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2010) is 5145 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: September 26, 2010 March 25, 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 Simplified 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Cached Information Extension . . . . . . . . . . . . . . . . . 4 58 4. Extension Exchange . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Cached Information . . . . . . . . . . . . . . . . . . . . 5 61 5. Data Substitution . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Data Substitution Syntax for certificate_chain . . . . . . 6 63 5.2. Data Substitution Syntax for trusted_cas . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 67 Annex A - 64 bit FNV Digest . . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 TLS handshakes often include fairly static information such as server 73 certificate and a list of trusted Certification Authorities (CAs). 74 Static information such as a server certificate can be of 75 considerable size. This is the case in particular if the server 76 certificate is bundled with a complete certificate path, including 77 all intermediary certificates up to the trust anchor public key. 79 Significant benefits can be achieved in low bandwidth and high 80 latency networks, in particular if the communication channel also has 81 a relatively high rate of transmission errors, if a known and 82 previously cached server certificate path can be omitted from the TLS 83 handshake. 85 This specification defines the Cached Information TLS extension, 86 which may be used by a client and a server to exclude transmission of 87 known cached parameters from the TLS handshake. 89 1.1. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 2. Cached Information Extension 97 A new extension type (cached_information(TBD)) is defined and used in 98 both the client hello and server hello messages. The extension type 99 is specified as follows. 101 enum { 102 cached_information(TBD), (65535) 103 } ExtensionType; 105 The "extension_data" field of this extension, when included in the 106 client hello, SHALL contain "CachedInformation" according to the 107 following structure: 109 enum { 110 certificate_chain(1), trusted_cas(2), (255) 111 } CachedInformationType; 113 struct { 114 CachedInformationType type; 115 opaque digest_value<0..8>; 116 } CachedObject; 118 struct { 119 CachedObject cached_info<1..2^16-1>; 120 } CachedInformation; 122 The digest_value of a CachedObject MUST either be empty (0 bytes) or 123 contain a 64 bit FNV digest (8 bytes) as specified in Annex A. 125 When CachedInformationType identifies certificate_chain, then 126 digest_value MUST include a digest calculated over the 127 certificate_list element of a server side Certificate message. 129 When CachedInformationType identifies trusted_cas, then digest_value 130 MUST include a digest calculated over the certificate_authorities 131 element of a server side CertificateRequest message. 133 Other specifications MAY define more CachedInformationType types. 135 4. Extension Exchange 137 4.1. Reconnaissance 139 A client MAY include an empty cached_information extension (with 140 empty extension_data field) in its (extended) client hello to query 141 whether the server supports cached information. 143 A server indicates that it supports cached information in handshakes 144 according to section 4.2. by including a cached_information extension 145 in its (extended) server hello. 147 4.2. Cached Information 149 Clients MAY specify cached information from previous handshakes by 150 including a "cached_information" extension in the (extended) client 151 hello, which contains at least one cached object (CachedObject) for 152 each present object type (CachedInformationType), as specified in 153 section 2. Clients MAY need the ability to cache different values 154 depending on other information in the Client Hello that modify what 155 values the server uses, in particular the Server Name Indication 156 [RFC4366] value. Clients sending a non-empty cached_information 157 extension MUST provide a 64 bit (8 byte) digest_value for each cached 158 object. 160 Servers that receive an extended client hello containing a 161 "cached_information" extension, MAY indicate that they support 162 caching of information objects by including an cached_information 163 extension in their (extended) server hello. 165 A cached_information extension provided in the server hello has the 166 following semantics: 168 o An empty cached_information extension indicates that the server 169 supports information caching but provides no information about 170 what information types it supports. 172 o A non-empty cached information extension indicates that the 173 server supports only those CachedInformationType types that are 174 identified by each present CachedObject. 176 o A CachedObject with an empty digest_value indicates that the 177 server supports caching of the specified object type 178 (CachedInformationType), but does not specify any digest values 179 it will accept. 181 o A present non-empty digest_value indicates that the server will 182 honor caching of objects of the specified type that matches the 183 present digest value. 185 5. Data Substitution 187 Following a successful exchange of "cached_information" extensions, 188 the server may substitute data objects in the handshake exchange with 189 a matching digest_value representing a matching object type. received 190 from the client in its client hello. 192 The handshake protocol will proceed using the cached data as if it 193 was provided in the handshake protocol. The Finished message will 194 however be calculated over the actual data exchanged in the handshake 195 protocol. That is, the Finished message will be calculated over the 196 digest values of cached information objects and not over the cached 197 objects that were omitted from transmission. 199 Each CachedInformationType MUST specify how actual data is replaced 200 by a digest in a way that does not violate the defined syntax of 201 existing handshake messages. the data exchange syntax for 202 certificate_chain(1) and trusted_cas(2) are provided below. 204 The server MUST NOT provide more than one digest value as 205 substitution for the cached data. 207 5.1. Data Substitution Syntax for certificate_chain 209 When a digest for an object of type trusted_cas is provided in the 210 client hello, the server MAY substitute the cached data with a 211 matching digest value received from the client by expanding the 212 Certificate handshake message as follows. 214 Original handshake message syntax defined in RFC 5246 [RFC5246]: 216 opaque ASN.1Cert<1..2^24-1>; 218 struct { 219 ASN.1Cert certificate_list<0..2^24-1>; 220 } Certificate; 222 Substitution syntax is defined by expanding the definition of the 223 opaque ASN.1Cert structure: 225 struct { 226 opaque digest_value<0..8>; 227 } ASN.1Cert 229 5.2. Data Substitution Syntax for trusted_cas 231 When a digest for an object of type trusted_cas is provided in the 232 client hello, the server MAY substitute the cached data with a 233 matching digest value received from the client by expanding the 234 CertificateRequest handshake message as follows. 236 Original handshake message syntax defined in RFC 5246 [RFC5246]: 238 opaque DistinguishedName<1..2^16-1>; 240 struct { 241 ClientCertificateType certificate_types<1..2^8-1>; 242 SignatureAndHashAlgorithm 243 supported_signature_algorithms<2^16-1>; 244 DistinguishedName certificate_authorities<0..2^16-1>; 245 } CertificateRequest 247 The substitution syntax is defined by expanding the definition of the 248 opaque DistinguishedName structure: 250 struct { 251 opaque digest_value<0..8>; 252 } DistinguishedName 254 5. Security Considerations 256 The digest algorithm used in this specification is required to have 257 reasonable random properties in order to provide reasonably unique 258 identifiers. There is no requirement that this digest algorithm must 259 have strong collision resistance. A non unique digest may at most 260 lead to a failed TLS handshake followed by a new attempt without the 261 cached information extension. There are no identified security 262 threats that require the selected digest algorithm to have strong 263 collision resistance. 265 6. IANA Considerations 267 1) Create an entry, cached_information(TBD), in the existing registry 268 for ExtensionType (defined in RFC 5246 [RFC5246]). 270 2) Establish a registry for TLS CachedInformationType values. The 271 first entries in the registry are certificate_chain(1) and 272 trusted_cas(2). TLS CachedInformationType values in the inclusive 273 range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards 274 Action. Values from the inclusive range 64-223 (decimal) are 275 assigned via RFC 5226 Specification Required. Values from the 276 inclusive range 224-255 (decimal) are reserved for RFC 5226 277 Private Use. 279 7. Normative References 281 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997 284 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 285 Considerations Section in RFCs", RFC 5226, May 2008 287 [RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security 288 (TLS) Protocol Version 1.2", RFC 5246, August 2008 290 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 291 Wright, "Transport Layer Security (TLS) Extensions", RFC 292 4366, April 2006 294 NOTE: RFC 4366 will be updated by RFC4366bis, currently in IESG 295 process. 297 Annex A - 64 bit FNV Digest 299 FNV-1 digest algorithm is a non-cryptographic hash function created 300 by Glenn Fowler, Landon Curt Noll, and Phong Vo. The FNV digest 301 algorithms and sample FNV source code have been released into the 302 public domain. 304 The FNV-1 digest is generated as follows: 306 digest = FNV_offset_basis 307 for each octet_of_data to be digested 308 digest = digest * FNV_prime 309 digest = digest XOR octet_of_data 310 return digest 312 In the above pseudocode, all variables are unsigned integers. All 313 variables, except for octet_of_data, have the same number of bits as 314 the FNV digest (64 Bits). The variable, octet_of_data, is an 8 bit 315 unsigned integer. Specifically for a 64 bit FNV-1 digest the 316 following applies: 318 o All variables, except for octet_of_data, are 64-bit unsigned 319 integers. 321 o The variable, octet_of_data, is an 8 bit unsigned integer. 323 o The FNV_offset_basis is the 64-bit FNV offset basis value: 324 14695981039346656037. 326 o The FNV_prime is the 64-bit FNV prime value: 1099511628211. 328 o The multiply function (indicated by the '*' symbol) returns the 329 lower 64-bits of the product. 331 o The XOR is an 8-bit operation that modifies only the lower 8-bits 332 of the digest value. 334 o The digest value returned is an 64-bit unsigned integer. 336 Authors' Addresses 338 Stefan Santesson 340 3xA Security AB 341 Bjornstorp 744 342 247 98 Genarp 343 Sweden 345 EMail: sts@aaa-sec.com