idnits 2.17.1 draft-ietf-tls-cached-info-06.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 : ---------------------------------------------------------------------------- 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 (March 30, 2010) is 5141 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: October 1, 2010 March 30, 2010 6 Transport Layer Security (TLS) Cached Information Extension 7 9 Abstract 11 This document defines a Transport Layer Security (TLS) extension for 12 cached information. This extension allows the TLS client to inform a 13 server of cached information from previous TLS sessions, allowing the 14 server to omit sending cached static information to the client during 15 the TLS handshake protocol exchange. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 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 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 68 Annex A - 64 bit FNV-1a digest . . . . . . . . . . . . . . . . . 10 69 A.1. Definition (Normative) . . . . . . . . . . . . . . . . . 10 70 A.2 Example code (Informative) . . . . . . . . . . . . . . . 11 71 A.3. Digest samples (Informative) . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 TLS handshakes often include fairly static information such as server 77 certificate and a list of trusted Certification Authorities (CAs). 78 Static information such as a server certificate can be of 79 considerable size. This is the case in particular if the server 80 certificate is bundled with a complete certificate path, including 81 all intermediary certificates up to the trust anchor public key. 83 Significant benefits can be achieved in low bandwidth and high 84 latency networks, in particular if the communication channel also has 85 a relatively high rate of transmission errors, if a known and 86 previously cached server certificate path can be omitted from the TLS 87 handshake. 89 This specification defines the Cached Information TLS extension, 90 which may be used by a client and a server to exclude transmission of 91 known cached parameters from the TLS handshake. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2. Cached Information Extension 101 A new extension type (cached_information(TBD)) is defined and used in 102 both the client hello and server hello messages. The extension type 103 is specified as follows. 105 enum { 106 cached_information(TBD), (65535) 107 } ExtensionType; 109 The "extension_data" field of this extension, when included in the 110 client hello, SHALL contain "CachedInformation" according to the 111 following structure: 113 enum { 114 certificate_chain(1), trusted_cas(2), (255) 115 } CachedInformationType; 117 struct { 118 CachedInformationType type; 119 opaque digest_value<0..8>; 120 } CachedObject; 122 struct { 123 CachedObject cached_info<1..2^16-1>; 124 } CachedInformation; 126 The digest_value of a CachedObject MUST either be empty (0 bytes) or 127 contain a 64 bit FNV digest (8 bytes) as specified in Annex A. The 64 128 bit integer is represented as an 8 byte digest_value in big-endian 129 order (with most significant bits in the first byte and least 130 significant bits in the last byte). 132 When CachedInformationType identifies certificate_chain, then 133 digest_value MUST include a digest calculated over the 134 certificate_list element of a server side Certificate message, 135 excluding the three length bytes of the certificate_list vector. 137 When CachedInformationType identifies trusted_cas, then digest_value 138 MUST include a digest calculated over the certificate_authorities 139 element of a server side CertificateRequest message, excluding the 140 two length bytes of the certificate_authorities vector. 142 Other specifications MAY define more CachedInformationType types. 144 4. Extension Exchange 146 4.1. Reconnaissance 148 A client MAY include an empty cached_information extension (with 149 empty extension_data field) in its (extended) client hello to query 150 whether the server supports cached information. 152 A server indicates that it supports cached information in handshakes 153 according to section 4.2. by including a cached_information extension 154 in its (extended) server hello. 156 4.2. Cached Information 158 Clients MAY specify cached information from previous handshakes by 159 including a "cached_information" extension in the (extended) client 160 hello, which contains at least one cached object (CachedObject) for 161 each present object type (CachedInformationType), as specified in 162 section 2. Clients MAY need the ability to cache different values 163 depending on other information in the Client Hello that modify what 164 values the server uses, in particular the Server Name Indication 165 [RFC4366] value. Clients sending a non-empty cached_information 166 extension MUST provide a 64 bit (8 byte) digest_value for each cached 167 object. 169 Servers that receive an extended client hello containing a 170 "cached_information" extension, MAY indicate that they support 171 caching of information objects by including an cached_information 172 extension in their (extended) server hello. 174 A cached_information extension provided in the server hello has the 175 following semantics: 177 o An empty cached_information extension indicates that the server 178 supports information caching but provides no information about 179 what information types it supports. 181 o A non-empty cached information extension indicates that the 182 server supports only those CachedInformationType types that are 183 identified by each present CachedObject. 185 o A CachedObject with an empty digest_value indicates that the 186 server supports caching of the specified object type 187 (CachedInformationType), but does not specify any digest values 188 it will accept. 190 o A present non-empty digest_value indicates that the server will 191 honor caching of objects of the specified type that matches the 192 present digest value. 194 5. Data Substitution 196 Following a successful exchange of "cached_information" extensions, 197 the server may substitute data objects in the handshake exchange with 198 a matching digest_value representing a matching object type. received 199 from the client in its client hello. 201 The handshake protocol will proceed using the cached data as if it 202 was provided in the handshake protocol. The Finished message will 203 however be calculated over the actual data exchanged in the handshake 204 protocol. That is, the Finished message will be calculated over the 205 digest values of cached information objects and not over the cached 206 objects that were omitted from transmission. 208 Each CachedInformationType MUST specify how actual data is replaced 209 by a digest in a way that does not violate the defined syntax of 210 existing handshake messages. the data exchange syntax for 211 certificate_chain(1) and trusted_cas(2) are provided below. 213 The server MUST NOT provide more than one digest value as 214 substitution for the cached data. 216 5.1. Data Substitution Syntax for certificate_chain 218 When a digest for an object of type certificate_chain is provided in 219 the client hello, the server MAY substitute the cached data with a 220 matching digest value received from the client by expanding the 221 Certificate handshake message as follows. 223 Original handshake message syntax defined in RFC 5246 [RFC5246]: 225 opaque ASN.1Cert<1..2^24-1>; 227 struct { 228 ASN.1Cert certificate_list<0..2^24-1>; 229 } Certificate; 231 Substitution syntax is defined by expanding the definition of the 232 opaque ASN.1Cert structure: 234 DigestInfo ASN.1Cert<1..2^24-1>; 236 struct { 237 opaque digest_value<0..8>; 238 } DigestInfo; 240 5.2. Data Substitution Syntax for trusted_cas 242 When a digest for an object of type trusted_cas is provided in the 243 client hello, the server MAY substitute the cached data with a 244 matching digest value received from the client by expanding the 245 CertificateRequest handshake message as follows. 247 Original handshake message syntax defined in RFC 5246 [RFC5246]: 249 opaque DistinguishedName<1..2^16-1>; 251 struct { 252 ClientCertificateType certificate_types<1..2^8-1>; 253 SignatureAndHashAlgorithm 254 supported_signature_algorithms<2^16-1>; 255 DistinguishedName certificate_authorities<0..2^16-1>; 256 } CertificateRequest 258 The substitution syntax is defined by expanding the definition of the 259 opaque DistinguishedName structure: 261 DigestInfo DistinguishedName<1..2^16-1>; 263 struct { 264 opaque digest_value<0..8>; 265 } DigestInfo; 267 6. Security Considerations 269 The digest algorithm used in this specification is required to have 270 reasonable random properties in order to provide reasonably unique 271 identifiers. There is no requirement that this digest algorithm must 272 have strong collision resistance. A non unique digest may at most 273 lead to a failed TLS handshake followed by a new attempt without the 274 cached information extension. There are no identified security 275 threats that require the selected digest algorithm to have strong 276 collision resistance. 278 7. IANA Considerations 280 1) Create an entry, cached_information(TBD), in the existing registry 281 for ExtensionType (defined in RFC 5246 [RFC5246]). 283 2) Establish a registry for TLS CachedInformationType values. The 284 first entries in the registry are certificate_chain(1) and 285 trusted_cas(2). TLS CachedInformationType values in the inclusive 286 range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards 287 Action. Values from the inclusive range 64-223 (decimal) are 288 assigned via RFC 5226 Specification Required. Values from the 289 inclusive range 224-255 (decimal) are reserved for RFC 5226 290 Private Use. 292 8. Acknowledgements 294 The author acknowledge input from many members of the TLS working 295 group, Martin Rex for extensive review and input and Marsh Ray for 296 testing and providing digest samples. 298 9. Normative References 300 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997 303 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 304 Considerations Section in RFCs", RFC 5226, May 2008 306 [RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security 307 (TLS) Protocol Version 1.2", RFC 5246, August 2008 309 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 310 Wright, "Transport Layer Security (TLS) Extensions", RFC 311 4366, April 2006 313 NOTE: RFC 4366 will be updated by RFC4366bis, currently in IESG 314 process. 316 Annex A - 64 bit FNV-1a digest 318 A.1. Definition (Normative) 320 FNV-1 digest algorithm is a non-cryptographic hash function created 321 by Glenn Fowler, Landon Curt Noll, and Phong Vo. The FNV digest 322 algorithms and sample FNV source code have been released into the 323 public domain. FNV-1 has two defined variants, FNV-1 and FNV-1a. The 324 algorithm specified in this annex specifies the FNV-1a variant. 326 The FNV-1a digest is generated as follows: 328 digest = FNV_offset_basis 329 for each octet_of_data to be digested { 330 digest = digest XOR octet_of_data 331 digest = digest * FNV_prime } 332 return digest 334 In the above pseudocode, all variables are unsigned integers. All 335 variables, except for octet_of_data, have the same number of bits as 336 the FNV digest (64 Bits). The variable, octet_of_data, is an 8 bit 337 unsigned integer. Specifically for a 64 bit FNV-1a digest the 338 following applies: 340 o All variables, except for octet_of_data, are 64-bit unsigned 341 integers. 343 o The variable, octet_of_data, is an 8 bit unsigned integer. 345 o The FNV_offset_basis is the 64-bit FNV offset basis value: 346 14695981039346656037. 348 o The FNV_prime is the 64-bit FNV prime value: 1099511628211. 350 o The multiply function (indicated by the '*' symbol) returns the 351 lower 64-bits of the product. 353 o The XOR is an 8-bit operation that modifies only the lower 8-bits 354 of the digest value. 356 o The digest value returned is an 64-bit unsigned integer. 358 A.2 Example code (Informative) 360 /** 361 * Java example code implementing FNV-1a according to Annex A 362 */ 364 import java.math.BigInteger; 366 public class FNV { 368 static public BigInteger getFNV1a64Digest (String inpString) { 370 BigInteger m = new BigInteger("2").pow(64); 371 BigInteger fnvPrime = new BigInteger("1099511628211"); 372 BigInteger fnvOffsetBasis = new BigInteger 373 ("14695981039346656037"); 375 BigInteger digest = fnvOffsetBasis; 377 for (int i = 0; i < inpString.length(); i++) { 378 digest = digest.xor(BigInteger.valueOf( 379 (int) inpString.charAt(i))); 380 digest = digest.multiply(fnvPrime).mod(m); 381 } 383 return (digest); 385 } 386 } 388 A.3. Digest samples (Informative) 390 Digest samples for 64 bit FNV-1a according to A.1. 392 For input data: 393 null ("") 394 0 bytes 396 Digest is: CB F2 9C E4 84 22 23 25 398 For input data: 399 hex: 61 ("a") 400 1 byte 402 Digest is: AF 63 DC 4C 86 01 EC 8C 404 For input data: 405 hex: FF 00 00 01 406 4 bytes 408 Digest is: 69 61 19 64 91 CC 68 2D 410 For input data: 411 hex: 68 74 74 70 3A 2F 2F 65 6E 2E 77 69 6B 69 70 65 412 64 69 61 2E 6F 72 67 2F 77 69 6B 69 2F 46 6F 77 413 6C 65 72 5F 4E 6F 6C 6C 5F 56 6F 5F 68 61 73 68 414 ("http://en.wikipedia.org/wiki/Fowler_Noll_Vo_hash") 415 48 bytes 417 Digest is: D9 B9 57 FB 7F E7 94 C5 419 Authors' Addresses 421 Stefan Santesson 423 3xA Security AB 424 Bjornstorp 744 425 247 98 Genarp 426 Sweden 428 EMail: sts@aaa-sec.com