idnits 2.17.1 draft-ietf-tls-cached-info-05.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 26, 2010) is 5142 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 27, 2010 March 26, 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 . . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 67 Annex A - 64 bit FNV-1 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. The 64 124 bit integer is represented as an 8 byte digest_value in big-endian 125 order (with most significant bits in the first byte and least 126 significant bits in the last byte). 128 When CachedInformationType identifies certificate_chain, then 129 digest_value MUST include a digest calculated over the 130 certificate_list element of a server side Certificate message, 131 excluding the three length bytes of the certificate_list vector. 133 When CachedInformationType identifies trusted_cas, then digest_value 134 MUST include a digest calculated over the certificate_authorities 135 element of a server side CertificateRequest message, excluding the 136 two length bytes of the certificate_authorities vector. 138 Other specifications MAY define more CachedInformationType types. 140 4. Extension Exchange 142 4.1. Reconnaissance 144 A client MAY include an empty cached_information extension (with 145 empty extension_data field) in its (extended) client hello to query 146 whether the server supports cached information. 148 A server indicates that it supports cached information in handshakes 149 according to section 4.2. by including a cached_information extension 150 in its (extended) server hello. 152 4.2. Cached Information 154 Clients MAY specify cached information from previous handshakes by 155 including a "cached_information" extension in the (extended) client 156 hello, which contains at least one cached object (CachedObject) for 157 each present object type (CachedInformationType), as specified in 158 section 2. Clients MAY need the ability to cache different values 159 depending on other information in the Client Hello that modify what 160 values the server uses, in particular the Server Name Indication 161 [RFC4366] value. Clients sending a non-empty cached_information 162 extension MUST provide a 64 bit (8 byte) digest_value for each cached 163 object. 165 Servers that receive an extended client hello containing a 166 "cached_information" extension, MAY indicate that they support 167 caching of information objects by including an cached_information 168 extension in their (extended) server hello. 170 A cached_information extension provided in the server hello has the 171 following semantics: 173 o An empty cached_information extension indicates that the server 174 supports information caching but provides no information about 175 what information types it supports. 177 o A non-empty cached information extension indicates that the 178 server supports only those CachedInformationType types that are 179 identified by each present CachedObject. 181 o A CachedObject with an empty digest_value indicates that the 182 server supports caching of the specified object type 183 (CachedInformationType), but does not specify any digest values 184 it will accept. 186 o A present non-empty digest_value indicates that the server will 187 honor caching of objects of the specified type that matches the 188 present digest value. 190 5. Data Substitution 192 Following a successful exchange of "cached_information" extensions, 193 the server may substitute data objects in the handshake exchange with 194 a matching digest_value representing a matching object type. received 195 from the client in its client hello. 197 The handshake protocol will proceed using the cached data as if it 198 was provided in the handshake protocol. The Finished message will 199 however be calculated over the actual data exchanged in the handshake 200 protocol. That is, the Finished message will be calculated over the 201 digest values of cached information objects and not over the cached 202 objects that were omitted from transmission. 204 Each CachedInformationType MUST specify how actual data is replaced 205 by a digest in a way that does not violate the defined syntax of 206 existing handshake messages. the data exchange syntax for 207 certificate_chain(1) and trusted_cas(2) are provided below. 209 The server MUST NOT provide more than one digest value as 210 substitution for the cached data. 212 5.1. Data Substitution Syntax for certificate_chain 214 When a digest for an object of type certificate_chain is provided in 215 the client hello, the server MAY substitute the cached data with a 216 matching digest value received from the client by expanding the 217 Certificate handshake message as follows. 219 Original handshake message syntax defined in RFC 5246 [RFC5246]: 221 opaque ASN.1Cert<1..2^24-1>; 223 struct { 224 ASN.1Cert certificate_list<0..2^24-1>; 225 } Certificate; 227 Substitution syntax is defined by expanding the definition of the 228 opaque ASN.1Cert structure: 230 DigestInfo ASN.1Cert<1..2^24-1>; 231 struct { 232 opaque digest_value<0..8>; 233 } DigestInfo; 235 5.2. Data Substitution Syntax for trusted_cas 237 When a digest for an object of type trusted_cas is provided in the 238 client hello, the server MAY substitute the cached data with a 239 matching digest value received from the client by expanding the 240 CertificateRequest handshake message as follows. 242 Original handshake message syntax defined in RFC 5246 [RFC5246]: 244 opaque DistinguishedName<1..2^16-1>; 246 struct { 247 ClientCertificateType certificate_types<1..2^8-1>; 248 SignatureAndHashAlgorithm 249 supported_signature_algorithms<2^16-1>; 250 DistinguishedName certificate_authorities<0..2^16-1>; 251 } CertificateRequest 253 The substitution syntax is defined by expanding the definition of the 254 opaque DistinguishedName structure: 256 DigestInfo DistinguishedName<1..2^16-1>; 258 struct { 259 opaque digest_value<0..8>; 260 } DigestInfo; 262 6. Security Considerations 264 The digest algorithm used in this specification is required to have 265 reasonable random properties in order to provide reasonably unique 266 identifiers. There is no requirement that this digest algorithm must 267 have strong collision resistance. A non unique digest may at most 268 lead to a failed TLS handshake followed by a new attempt without the 269 cached information extension. There are no identified security 270 threats that require the selected digest algorithm to have strong 271 collision resistance. 273 7. IANA Considerations 275 1) Create an entry, cached_information(TBD), in the existing registry 276 for ExtensionType (defined in RFC 5246 [RFC5246]). 278 2) Establish a registry for TLS CachedInformationType values. The 279 first entries in the registry are certificate_chain(1) and 280 trusted_cas(2). TLS CachedInformationType values in the inclusive 281 range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards 282 Action. Values from the inclusive range 64-223 (decimal) are 283 assigned via RFC 5226 Specification Required. Values from the 284 inclusive range 224-255 (decimal) are reserved for RFC 5226 285 Private Use. 287 8. Normative References 289 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997 292 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 293 Considerations Section in RFCs", RFC 5226, May 2008 295 [RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security 296 (TLS) Protocol Version 1.2", RFC 5246, August 2008 298 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 299 Wright, "Transport Layer Security (TLS) Extensions", RFC 300 4366, April 2006 302 NOTE: RFC 4366 will be updated by RFC4366bis, currently in IESG 303 process. 305 Annex A - 64 bit FNV-1 Digest 307 FNV-1 digest algorithm is a non-cryptographic hash function created 308 by Glenn Fowler, Landon Curt Noll, and Phong Vo. The FNV digest 309 algorithms and sample FNV source code have been released into the 310 public domain. 312 The FNV-1 digest is generated as follows: 314 digest = FNV_offset_basis 315 for each octet_of_data to be digested 316 digest = digest * FNV_prime 317 digest = digest XOR octet_of_data 318 return digest 320 In the above pseudocode, all variables are unsigned integers. All 321 variables, except for octet_of_data, have the same number of bits as 322 the FNV digest (64 Bits). The variable, octet_of_data, is an 8 bit 323 unsigned integer. Specifically for a 64 bit FNV-1 digest the 324 following applies: 326 o All variables, except for octet_of_data, are 64-bit unsigned 327 integers. 329 o The variable, octet_of_data, is an 8 bit unsigned integer. 331 o The FNV_offset_basis is the 64-bit FNV offset basis value: 332 14695981039346656037. 334 o The FNV_prime is the 64-bit FNV prime value: 1099511628211. 336 o The multiply function (indicated by the '*' symbol) returns the 337 lower 64-bits of the product. 339 o The XOR is an 8-bit operation that modifies only the lower 8-bits 340 of the digest value. 342 o The digest value returned is an 64-bit unsigned integer. 344 Authors' Addresses 346 Stefan Santesson 348 3xA Security AB 349 Bjornstorp 744 350 247 98 Genarp 351 Sweden 353 EMail: sts@aaa-sec.com