idnits 2.17.1 draft-ietf-tls-cached-info-09.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 (July 12, 2010) is 5035 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: 3 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: January 13, 2011 July 12, 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 handshakes, allowing 14 the server to omit sending cached static information to the client 15 during 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. Cached Information . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Cached Information Substitution . . . . . . . . . . . . . . . . 6 62 4.1. Substitution Syntax for certificate_chain . . . . . . . . 6 63 4.2. Substitution Syntax for trusted_cas . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 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 cached information 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 HashAlgorithm hash; 116 opaque hash_value<1..255>; 117 } CachedObject; 119 struct { 120 CachedObject cached_info<1..2^16-1>; 121 } CachedInformation; 123 When CachedInformationType identifies certificate_chain, then 124 hash_value MUST include a hash calculated over the certificate_list 125 element of a server side Certificate message, excluding the three 126 length bytes of the certificate_list vector. 128 When CachedInformationType identifies trusted_cas, then hash_value 129 MUST include a hash calculated over the certificate_authorities 130 element of a server side CertificateRequest message, excluding the 131 two length bytes of the certificate_authorities vector. 133 The hash algorithm used to calculate hash values SHALL be the hash 134 algorithm that was used to generate the Finished message in the 135 handshake exchange from which the hashed information was cached. Hash 136 algorithm identifiers are defined in the RFC 5246 [RFC5246] 137 HashAlgorithm registry. 139 Other specifications MAY define more CachedInformationType types. 141 3. Extension Exchange 143 3.1. Cached Information 145 Clients MAY include a "cached_information" extension in the 146 (extended) client hello, which MAY contain zero or more cached 147 objects (CachedObject). 149 Servers that receive an extended client hello containing a 150 "cached_information" extension MAY indicate that they support cached 151 information objects by including a cached_information extension in 152 their (extended) server hello. 154 A cached_information extension provided in the server hello has the 155 following semantics: 157 o An empty cached_information extension indicates that the server 158 supports information caching but provides no information about 159 what information types it supports. 161 o A non-empty cached information extension indicates that the 162 server supports caching of each present CachedObject that matches 163 the specified hash value. The server MAY support other cached 164 objects that are not present in the extension. 166 Note: Clients may need the ability to cache different values 167 depending on other information in the Client Hello that modify what 168 values the server uses, in particular the Server Name Indication 169 [RFC4366] value. 171 3.2. Reconnaissance 173 A client MAY include an empty cached_information extension (with 174 empty extension_data field) in its (extended) client hello to query 175 whether the server supports cached information. 177 Upon receiving an empty cached_information extension, a server MAY 178 indicate that it supports cached information in handshakes by 179 including a cached_information extension in its (extended) server 180 hello according to any of the available options in section 3.1. 182 4. Cached Information Substitution 184 Following a successful exchange of "cached_information" extensions, 185 the server MAY substitute cached information in the handshake 186 exchange with a matching CachedObject from the client hello 187 "cached_information" extension. 189 A substitution syntax that defines how the CachedObject structure is 190 carried in the handshake message MUST be defined for each 191 CachedInformationType in a way that does not violate the syntax of 192 the handshake message. The substitution syntax for 193 certificate_chain(1) and trusted_cas(2) is provided below. 195 The handshake protocol SHALL proceed using the cached information as 196 if it was provided in the handshake protocol. The Finished message 197 SHALL be calculated over the actual data exchanged in the handshake 198 protocol. That is, the Finished message will be calculated over the 199 hash values of cached information objects and not over the cached 200 information that were omitted from transmission. 202 The server MUST NOT include more than one CachedObject as 203 substitution for the cached information. 205 4.1. Substitution Syntax for certificate_chain 207 When an object of type certificate_chain is provided in the client 208 hello, the server MAY substitute the cached information with a 209 matching hash value received from the client by expanding the 210 Certificate handshake message as follows. 212 Original handshake message syntax defined in RFC 5246 [RFC5246]: 214 opaque ASN.1Cert<1..2^24-1>; 216 struct { 217 ASN.1Cert certificate_list<0..2^24-1>; 218 } Certificate; 220 Substitution syntax is defined by expanding the syntax of the opaque 221 ASN.1Cert structure: 223 CachedObject ASN.1Cert<1..2^24-1>; 225 4.2. Substitution Syntax for trusted_cas 227 When a hash for an object of type trusted_cas is provided in the 228 client hello, the server MAY substitute the cached information with a 229 matching hash value received from the client by expanding the 230 CertificateRequest handshake message as follows. 232 Original handshake message syntax defined in RFC 5246 [RFC5246]: 234 opaque DistinguishedName<1..2^16-1>; 236 struct { 237 ClientCertificateType certificate_types<1..2^8-1>; 238 SignatureAndHashAlgorithm 239 supported_signature_algorithms<2^16-1>; 240 DistinguishedName certificate_authorities<0..2^16-1>; 241 } CertificateRequest 243 The substitution syntax is defined by expanding the syntax of the 244 opaque DistinguishedName structure: 246 CachedObject DistinguishedName<1..2^16-1>; 248 5. Security Considerations 250 The hash algorithm used in this specification is required to have 251 reasonable random properties in order to provide reasonably unique 252 identifiers. There is no clearly identified requirement that this 253 hash algorithm must have strong collision resistance. However since 254 the hash algorithm is used to represent data in the finished 255 calculation, the security properties of the finished calculation will 256 change if a weaker hash algorithm is used to represent cached 257 information compared with the hash algorithm used to calculate the 258 finished message. 260 Caching information in an encrypted handshake (such as a renegotiated 261 handshake) and sending a hash of that cached information in an 262 unencrypted handshake might introduce integrity or data disclosure 263 issues as it enables an attacker to identify if a known object (such 264 as a known server certificate) has been used in previous encrypted 265 handshakes. Information object types defined in this specification, 266 such as server certificates, are public objects and usually not 267 sensitive in this regard, but implementers should be aware if any 268 cached information are subject to such security concerns and in such 269 case SHOULD NOT send a hash over encrypted data in en unencrypted 270 handshake. 272 6. IANA Considerations 274 1) Create an entry, cached_information(TBD), in the existing registry 275 for ExtensionType (defined in RFC 5246 [RFC5246]). 277 2) Establish a registry for TLS CachedInformationType values. The 278 first entries in the registry are certificate_chain(1) and 279 trusted_cas(2). TLS CachedInformationType values in the inclusive 280 range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards 281 Action. Values from the inclusive range 64-223 (decimal) are 282 assigned via RFC 5226 Specification Required. Values from the 283 inclusive range 224-255 (decimal) are reserved for RFC 5226 284 Private Use. 286 7. Acknowledgements 288 The author acknowledges input from many members of the TLS working 289 group. 291 8. Normative References 293 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997 296 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 297 Considerations Section in RFCs", RFC 5226, May 2008 299 [RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security 300 (TLS) Protocol Version 1.2", RFC 5246, August 2008 302 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 303 Wright, "Transport Layer Security (TLS) Extensions", RFC 304 4366, April 2006 306 NOTE: RFC 4366 will be updated by RFC4366bis, currently in IESG 307 process. 309 Authors' Addresses 311 Stefan Santesson 313 3xA Security AB 314 Scheelev. 17 315 223 70 Sweden 317 EMail: sts@aaa-sec.com