idnits 2.17.1 draft-ietf-tls-cached-info-08.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 (April 20, 2010) is 5113 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 22, 2010 April 20, 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 3. Extension Exchange . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Cached Information . . . . . . . . . . . . . . . . . . . . 5 61 4. Data Substitution . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Data Substitution Syntax for certificate_chain . . . . . . 6 63 4.2. Data Substitution Syntax for trusted_cas . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 68 Annex A - 64 bit FNV-1a digest . . . . . . . . . . . . . . . . . 10 69 A.1. Definition (Normative) . . . . . . . . . . . . . . . . . 10 70 A.2 Java code sample (Informative) . . . . . . . . . . . . . 11 71 A.3. C code sample (Informative) . . . . . . . . . . . . . . . 12 72 A.4. Digest samples (Informative) . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 TLS handshakes often include fairly static information such as server 78 certificate and a list of trusted Certification Authorities (CAs). 79 Static information such as a server certificate can be of 80 considerable size. This is the case in particular if the server 81 certificate is bundled with a complete certificate path, including 82 all intermediary certificates up to the trust anchor public key. 84 Significant benefits can be achieved in low bandwidth and high 85 latency networks, in particular if the communication channel also has 86 a relatively high rate of transmission errors, if a known and 87 previously cached server certificate path can be omitted from the TLS 88 handshake. 90 This specification defines the Cached Information TLS extension, 91 which may be used by a client and a server to exclude transmission of 92 known cached parameters from the TLS handshake. 94 1.1. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Cached Information Extension 102 A new extension type (cached_information(TBD)) is defined and used in 103 both the client hello and server hello messages. The extension type 104 is specified as follows. 106 enum { 107 cached_information(TBD), (65535) 108 } ExtensionType; 110 The "extension_data" field of this extension, when included in the 111 client hello, SHALL contain "CachedInformation" according to the 112 following structure: 114 enum { 115 certificate_chain(1), trusted_cas(2), (255) 116 } CachedInformationType; 118 struct { 119 CachedInformationType type; 120 opaque digest_value<0..8>; 121 } CachedObject; 123 struct { 124 CachedObject cached_info<1..2048>; 125 } CachedInformation; 127 The digest_value of a CachedObject MUST either be empty (0 bytes) or 128 contain a 64 bit FNV digest (8 bytes) as specified in Annex A. The 64 129 bit integer is represented as an 8 byte digest_value in big-endian 130 order (with most significant bits in the first byte and least 131 significant bits in the last byte). 133 When CachedInformationType identifies certificate_chain, then 134 digest_value MUST include a digest calculated over the 135 certificate_list element of a server side Certificate message, 136 excluding the three length bytes of the certificate_list vector. 138 When CachedInformationType identifies trusted_cas, then digest_value 139 MUST include a digest calculated over the certificate_authorities 140 element of a server side CertificateRequest message, excluding the 141 two length bytes of the certificate_authorities vector. 143 Other specifications MAY define more CachedInformationType types. 145 3. Extension Exchange 147 3.1. Reconnaissance 149 A client MAY include an empty cached_information extension (with 150 empty extension_data field) in its (extended) client hello to query 151 whether the server supports cached information. 153 A server indicates that it supports cached information in handshakes 154 according to section 3.2. by including a cached_information extension 155 in its (extended) server hello. 157 3.2. Cached Information 159 Clients MAY specify cached information from previous handshakes by 160 including a "cached_information" extension in the (extended) client 161 hello, which contains at least one cached object (CachedObject) for 162 each present object type (CachedInformationType), as specified in 163 section 2. Clients MAY need the ability to cache different values 164 depending on other information in the Client Hello that modify what 165 values the server uses, in particular the Server Name Indication 166 [RFC4366] value. Clients sending a non-empty cached_information 167 extension MUST provide a 64 bit (8 byte) digest_value for each cached 168 object. 170 Servers that receive an extended client hello containing a 171 "cached_information" extension, MAY indicate that they support 172 caching of information objects by including an cached_information 173 extension in their (extended) server hello. 175 A cached_information extension provided in the server hello has the 176 following semantics: 178 o An empty cached_information extension indicates that the server 179 supports information caching but provides no information about 180 what information types it supports. 182 o A non-empty cached information extension indicates that the 183 server supports only those CachedInformationType types that are 184 identified by each present CachedObject. 186 o A CachedObject with an empty digest_value indicates that the 187 server supports caching of the specified object type 188 (CachedInformationType), but does not specify any digest values 189 it will accept. 191 o A present non-empty digest_value indicates that the server will 192 honor caching of objects of the specified type that matches the 193 present digest value. 195 4. Data Substitution 197 Following a successful exchange of "cached_information" extensions, 198 the server may substitute data objects in the handshake exchange with 199 a matching digest_value representing a matching object type. received 200 from the client in its client hello. 202 The handshake protocol will proceed using the cached data as if it 203 was provided in the handshake protocol. The Finished message will 204 however be calculated over the actual data exchanged in the handshake 205 protocol. That is, the Finished message will be calculated over the 206 digest values of cached information objects and not over the cached 207 objects that were omitted from transmission. 209 Each CachedInformationType MUST specify how actual data is replaced 210 by a digest in a way that does not violate the defined syntax of 211 existing handshake messages. the data exchange syntax for 212 certificate_chain(1) and trusted_cas(2) are provided below. 214 The server MUST NOT provide more than one digest value as 215 substitution for the cached data. 217 4.1. Data Substitution Syntax for certificate_chain 219 When a digest for an object of type certificate_chain is provided in 220 the client hello, the server MAY substitute the cached data with a 221 matching digest value received from the client by expanding the 222 Certificate handshake message as follows. 224 Original handshake message syntax defined in RFC 5246 [RFC5246]: 226 opaque ASN.1Cert<1..2^24-1>; 228 struct { 229 ASN.1Cert certificate_list<0..2^24-1>; 230 } Certificate; 232 Substitution syntax is defined by expanding the definition of the 233 opaque ASN.1Cert structure: 235 DigestInfo ASN.1Cert<1..2^24-1>; 237 struct { 238 opaque digest_value<0..8>; 239 } DigestInfo; 241 4.2. Data Substitution Syntax for trusted_cas 243 When a digest for an object of type trusted_cas is provided in the 244 client hello, the server MAY substitute the cached data with a 245 matching digest value received from the client by expanding the 246 CertificateRequest handshake message as follows. 248 Original handshake message syntax defined in RFC 5246 [RFC5246]: 250 opaque DistinguishedName<1..2^16-1>; 252 struct { 253 ClientCertificateType certificate_types<1..2^8-1>; 254 SignatureAndHashAlgorithm 255 supported_signature_algorithms<2^16-1>; 256 DistinguishedName certificate_authorities<0..2^16-1>; 257 } CertificateRequest 259 The substitution syntax is defined by expanding the definition of the 260 opaque DistinguishedName structure: 262 DigestInfo DistinguishedName<1..2^16-1>; 264 struct { 265 opaque digest_value<0..8>; 266 } DigestInfo; 268 5. Security Considerations 270 The digest algorithm used in this specification is required to have 271 reasonable random properties in order to provide reasonably unique 272 identifiers. There is no requirement that this digest algorithm must 273 have strong collision resistance. A non unique digest may at most 274 lead to a failed TLS handshake followed by a new attempt without the 275 cached information extension. There are no identified security 276 threats that require the selected digest algorithm to have strong 277 collision resistance. 279 6. IANA Considerations 281 1) Create an entry, cached_information(TBD), in the existing registry 282 for ExtensionType (defined in RFC 5246 [RFC5246]). 284 2) Establish a registry for TLS CachedInformationType values. The 285 first entries in the registry are certificate_chain(1) and 286 trusted_cas(2). TLS CachedInformationType values in the inclusive 287 range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards 288 Action. Values from the inclusive range 64-223 (decimal) are 289 assigned via RFC 5226 Specification Required. Values from the 290 inclusive range 224-255 (decimal) are reserved for RFC 5226 291 Private Use. 293 7. Acknowledgements 295 The author acknowledge input from many members of the TLS working 296 group, Martin Rex for extensive review and input, Marsh Ray and Simon 297 Josefsson for coding and test vectors. 299 8. Normative References 301 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997 304 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 305 Considerations Section in RFCs", RFC 5226, May 2008 307 [RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security 308 (TLS) Protocol Version 1.2", RFC 5246, August 2008 310 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 311 Wright, "Transport Layer Security (TLS) Extensions", RFC 312 4366, April 2006 314 NOTE: RFC 4366 will be updated by RFC4366bis, currently in IESG 315 process. 317 Annex A - 64 bit FNV-1a digest 319 A.1. Definition (Normative) 321 FNV-1 digest algorithm is a non-cryptographic hash function created 322 by Glenn Fowler, Landon Curt Noll, and Phong Vo. The FNV digest 323 algorithms and sample FNV source code have been released into the 324 public domain. FNV-1 has two defined variants, FNV-1 and FNV-1a. The 325 algorithm specified in this annex specifies the FNV-1a variant. 327 The FNV-1a digest is generated as follows: 329 digest = FNV_offset_basis 330 for each octet_of_data to be digested { 331 digest = digest XOR octet_of_data 332 digest = digest * FNV_prime } 333 return digest 335 In the above pseudocode, all variables are unsigned integers. All 336 variables, except for octet_of_data, have the same number of bits as 337 the FNV digest (64 Bits). The variable, octet_of_data, is an 8 bit 338 unsigned integer. Specifically for a 64 bit FNV-1a digest the 339 following applies: 341 o All variables, except for octet_of_data, are 64-bit unsigned 342 integers. 344 o The variable, octet_of_data, is an 8 bit unsigned integer. 346 o The FNV_offset_basis is the 64-bit FNV offset basis value: 347 14695981039346656037. 349 o The FNV_prime is the 64-bit FNV prime value: 1099511628211. 351 o The multiply function (indicated by the '*' symbol) returns the 352 lower 64-bits of the product. 354 o The XOR is an 8-bit operation that modifies only the lower 8-bits 355 of the digest value. 357 o The digest value returned is an 64-bit unsigned integer. 359 A.2 Java code sample (Informative) 361 /** 362 * Java code sample, implementing 64 bit FNV-1a 363 * By Stefan Santesson 364 */ 366 import java.math.BigInteger; 368 public class FNV { 370 static public BigInteger getFNV1a64Digest (String inpString) { 372 BigInteger m = new BigInteger("2").pow(64); 373 BigInteger fnvPrime = new BigInteger("1099511628211"); 374 BigInteger fnvOffsetBasis = new BigInteger 375 ("14695981039346656037"); 377 BigInteger digest = fnvOffsetBasis; 379 for (int i = 0; i < inpString.length(); i++) { 380 digest = digest.xor(BigInteger.valueOf( 381 (int) inpString.charAt(i))); 382 digest = digest.multiply(fnvPrime).mod(m); 383 } 385 return (digest); 387 } 388 } 390 A.3. C code sample (Informative) 392 fnv1a64.h: 394 #ifndef FNV1A64_H 395 #define FNV1A64_H 397 #include /* For size_t */ 398 #include /* For uint64_t */ 400 extern uint64_t fnv1a64 (const uint8_t *buffer, size_t len); 402 #endif 404 fnv1a64.c: 406 /* fnv1a.c -- Implementation of the FNV-1A non-cryptographic 407 * hash function. 408 * By Simon Josefsson on 2010-03-30. 409 */ 411 #include "fnv1a64.h" 413 #define FNV1A64_OFFSET_BASIS 14695981039346656037ULL 414 #define FNV1A64_PRIME 1099511628211ULL 416 uint64_t 417 fnv1a64 (const uint8_t *buffer, size_t len) 418 { 419 uint64_t hash; 420 size_t i; 422 hash = FNV1A64_OFFSET_BASIS; 423 for (i = 0; i < len; i++) 424 { 425 hash = hash ^ buffer[i]; 426 hash = hash * FNV1A64_PRIME; 427 } 429 return hash; 430 } 432 A.4. Digest samples (Informative) 434 Digest samples for 64 bit FNV-1a 436 For input data: 437 null ("") 438 0 bytes 440 Digest is: CB F2 9C E4 84 22 23 25 442 For input data: 443 hex: 61 ("a") 444 1 byte 446 Digest is: AF 63 DC 4C 86 01 EC 8C 448 For input data: 449 hex: FF 00 00 01 450 4 bytes 452 Digest is: 69 61 19 64 91 CC 68 2D 454 For input data: 455 hex: 68 74 74 70 3A 2F 2F 65 6E 2E 77 69 6B 69 70 65 456 64 69 61 2E 6F 72 67 2F 77 69 6B 69 2F 46 6F 77 457 6C 65 72 5F 4E 6F 6C 6C 5F 56 6F 5F 68 61 73 68 458 ("http://en.wikipedia.org/wiki/Fowler_Noll_Vo_hash") 459 48 bytes 461 Digest is: D9 B9 57 FB 7F E7 94 C5 463 Authors' Addresses 465 Stefan Santesson 467 3xA Security AB 468 Bjornstorp 744 469 247 98 Genarp 470 Sweden 472 EMail: sts@aaa-sec.com