idnits 2.17.1 draft-ietf-tls-cached-info-17.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 13, 2014) is 3452 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) -- Looks like a reference, but probably isn't: '1' on line 282 -- Looks like a reference, but probably isn't: '2' on line 301 -- Looks like a reference, but probably isn't: '3' on line 304 -- Looks like a reference, but probably isn't: '4' on line 305 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 316, but not defined == Unused Reference: 'RFC3874' is defined on line 390, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3874 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS S. Santesson 3 Internet-Draft 3xA Security AB 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 17, 2015 ARM Ltd. 6 November 13, 2014 8 Transport Layer Security (TLS) Cached Information Extension 9 draft-ietf-tls-cached-info-17.txt 11 Abstract 13 Transport Layer Security (TLS) handshakes often include fairly static 14 information, such as the server certificate and a list of trusted 15 Certification Authorities (CAs). This information can be of 16 considerable size, particularly if the server certificate is bundled 17 with a complete certificate chain (i.e., the certificates of 18 intermediate CAs up to the root CA). 20 This document defines an extension that allows a TLS client to inform 21 a server of cached information, allowing the server to omit already 22 available information. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 17, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Cached Information Extension . . . . . . . . . . . . . . . . 3 61 3.1. Certificate_list Fingerprint . . . . . . . . . . . . . . 4 62 3.2. Certificate_authorities Fingerprint . . . . . . . . . . . 4 63 3.3. Fingerprint Hash Algorithm . . . . . . . . . . . . . . . 4 64 4. Exchange Specification . . . . . . . . . . . . . . . . . . . 5 65 4.1. Omitting the Certificate List . . . . . . . . . . . . . . 5 66 4.2. Omitting the Trusted Certificate Authorities . . . . . . 6 67 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 9 71 7.2. New Registry for CachedInformationType . . . . . . . . . 9 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 9.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Reducing the amount of information exchanged during a Transport Layer 81 Security handshake to a minimum helps to improve performance in 82 environments where devices are connected to a network with a low 83 bandwidth, and lossy radio technology. With Internet of Things such 84 environments exist, for example, when smart objects are connected 85 using a low power IEEE 802.15.4 radio or via Bluetooth Smart. For 86 more information about the challenges with smart object deployments 87 please see [RFC6574]. 89 This specification defines a TLS extension that allows a client and a 90 server to exclude transmission information cached in an earlier TLS 91 handshake. 93 A typical example exchange may therefore look as follows. First, the 94 client and the server executes the usual TLS handshake. The client 95 may, for example, decide to cache the certificate provided by the 96 server. When the TLS client connects to the TLS server some time in 97 the future, without using session resumption, it then attaches the 98 cached_info extension defined in this document to the client hello 99 message to indicate that it had cached the certificate, and it 100 provides the fingerprint of it. If the server's certificate has not 101 changed then the TLS server does not need to send its' certificate 102 and the corresponding certificate list again. In case information 103 has changed, which can be seen from the fingerprint provided by the 104 client, the certificate payload is transmitted to the client to allow 105 the client to update the cache. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 This document refers to the TLS protocol but the description is 114 equally applicable to DTLS as well. 116 3. Cached Information Extension 118 This document defines a new extension type (cached_info(TBD)), which 119 is used in client hello and server hello messages. The extension 120 type is specified as follows. 122 enum { 123 cached_info(TBD), (65535) 124 } ExtensionType; 126 The extension_data field of this extension, when included in the 127 client hello, MUST contain the CachedInformation structure. The 128 client MUST NOT send multiple CachedObjects with the same 129 CachedInformationType. 131 enum { 132 certificate_list(1), certificate_authorities(2) (255) 133 } CachedInformationType; 135 struct { 136 select (type) { 137 case client: 138 CachedInformationType type; 139 HashAlgorithm hash; 140 opaque hash_value<1..255>; 141 case server: 142 CachedInformationType type; 143 } body; 144 } CachedObject; 146 struct { 147 CachedObject cached_info<1..2^16-1>; 148 } CachedInformation; 150 This document establishes a registry for CachedInformationType types; 151 additional values can be added following the policy described in 152 Section 7. 154 3.1. Certificate_list Fingerprint 156 When the CachedInformationType identifies a certificate_list, then 157 the hash_value field MUST include the hash calculated over the 158 certificate_list element of the Certificate payload provided by the 159 TLS server in an earlier exchange, excluding the three length bytes 160 of the certificate_list vector. 162 3.2. Certificate_authorities Fingerprint 164 When the CachedInformationType identifies a certificate_authorities, 165 then the hash_value MUST include a hash calculated over 166 CertificateRequest payload provided by the TLS server in an earlier 167 exchange, excluding the msg_type and length field. 169 3.3. Fingerprint Hash Algorithm 171 The hash algorithm used to calculate hash values is conveyed in the 172 'hash' field of the CachedObject element. The list of registered 173 hash algorithms can be found in the TLS HashAlgorithm Registry, which 174 was created by RFC 5246 [RFC5246]. The value zero (0) for 'none' and 175 one (1) for 'md5' is not an allowed choice for a hash algorithm and 176 MUST NOT be used. 178 4. Exchange Specification 180 Clients supporting this extension MAY include the "cached_info" 181 extension in the (extended) client hello. If the client includes the 182 extension then it MUST contain one or more CachedObject attributes. 183 Clients and servers MUST NOT include more than one CachedObject 184 attribute per info type. 186 A server supporting this extension MAY include the "cached_info" 187 extension in the (extended) server hello. By returning the 188 "cached_info" extension the server indicates that it supports the 189 cached info types. For each indicated cached info type the server 190 MUST alters the transmission of respective payloads, as specified for 191 each type. If the server includes the extension it MUST only include 192 CachedObjects of a type also supported by the client (as expressed in 193 the client hello). 195 Note that the client includes a fingerprint of the cached information 196 to give the server enough information to determine whether cached 197 information is stale. If the server supports this specification and 198 notices a mismatch between the data cached by the client and its own 199 information then the server MUST include the information in full and 200 MUST NOT list the respective item in the "cached_info" extension. 202 Note: Clients may cache multiple data items for a single server if 203 those servers are part of a hosting environment. To allow the client 204 to select the appropriate information from the cached it is 205 RECOMMENDED that the client uses information from the Server Name 206 Indication [RFC6066]. 208 Following a successful exchange of the "cached_info" extensions in 209 the client and server hello, the server alters sending the 210 corresponding handshake message. How information is altered from the 211 handshake messages is defined per cached info type. Section 4.1 and 212 Section 4.2 defines the syntax of the fingerprinted information. 214 The handshake protocol MUST proceed using the information as if it 215 was provided in the handshake protocol. Since the Finished message 216 is calculated over the exchanged data it will also include the hash 217 of the cached data. 219 4.1. Omitting the Certificate List 221 When an object of type 'certificate_list' is provided in the client 222 hello, the server MAY replace the list of certificates with an empty 223 sequence with an actual length field of zero (=empty vector). 225 The original handshake message syntax is defined in RFC 5246 226 [RFC5246] and has the following structure: 228 opaque ASN.1Cert<1..2^24-1>; 230 struct { 231 ASN.1Cert certificate_list<0..2^24-1>; 232 } Certificate; 234 Note that [RFC7250] allows the certificate payload to contain only 235 the SubjectPublicKeyInfo instead of the full information typically 236 found in a certificate. Hence, when this specification is used in 237 combination with [RFC7250] and the negotiated certificate type is a 238 raw public key then the TLS server omits sending a Certificate 239 payload that contains an ASN.1Cert structure of the 240 SubjectPublicKeyInfo. 242 4.2. Omitting the Trusted Certificate Authorities 244 When a fingerprint for an object of type 'certificate_authorities' is 245 provided in the client hello, the server MAY replace the 246 CertificateRequest message with an empty sequence with an actual 247 length field of zero. 249 The original handshake message syntax is defined in RFC 5246 250 [RFC5246] and has the following structure: 252 opaque DistinguishedName<1..2^16-1>; 254 struct { 255 ClientCertificateType certificate_types<1..2^8-1>; 256 SignatureAndHashAlgorithm 257 supported_signature_algorithms<2^16-1>; 258 DistinguishedName certificate_authorities<0..2^16-1>; 259 } CertificateRequest; 261 5. Example 263 Figure 1 illustrates an example exchange using the TLS cached info 264 extension. In the normal TLS handshake exchange shown in flow (A) 265 the TLS server provides its certificate in the Certificate payload to 266 the client, see step [1]. This allows the client to store the 267 certificate for future use. After some time the TLS client again 268 interacts with the same TLS server and makes use of the TLS cached 269 info extension, as shown in flow (B). The TLS client indicates 270 support for this specification via the "cached_info" extension, see 272 [2], and indicates that it has stored the 'certificate_list' from the 273 earlier exchange. With [3] the TLS server acknowledges the supports 274 of this specification and informs the client that it alterned the 275 content of the certificate payload (see [4], as described in 276 Section 4.1). 278 (A) Initial (full) Exchange 280 ClientHello -> 281 <- ServerHello 282 Certificate* // [1] 283 ServerKeyExchange* 284 CertificateRequest* 285 ServerHelloDone 287 Certificate* 288 ClientKeyExchange 289 CertificateVerify* 290 [ChangeCipherSpec] 291 Finished -> 293 <- [ChangeCipherSpec] 294 Finished 296 Application Data <-------> Application Data 298 (B) TLS Cached Extension Usage 300 ClientHello 301 cached_info=(certificate_list) -> // [2] 302 <- ServerHello 303 cached_info= 304 (certificate_list) // [3] 305 Certificate* // [4] 306 ServerKeyExchange* 307 CertificateRequest* 308 ServerHelloDone 310 Certificate* 311 ClientKeyExchange 312 CertificateVerify* 313 [ChangeCipherSpec] 314 Finished -> 316 <- [ChangeCipherSpec] 317 Finished 319 Application Data <-------> Application Data 321 Figure 1: Example Message Exchange 323 6. Security Considerations 325 This specification defines a mechanism to reference stored state 326 using a fingerprint. Sending a fingerprint of cached information in 327 an unencrypted handshake, as the client and server hello is, may 328 allow an attacker or observer to correlate independent TLS exchanges. 329 While some information elements used in this specification, such as 330 server certificates, are public objects and usually not sensitive in 331 this regard, others may be. Those who implement and deploy this 332 specification should therefore make an informed decision whether the 333 cached information is inline with their security and privacy goals. 334 In case of concerns, it is advised to avoid sending the fingerprint 335 of the data objects in clear. 337 The hash algorithm used in this specification is required to have 338 have strong collision resistance. 340 7. IANA Considerations 342 7.1. New Entry to the TLS ExtensionType Registry 344 IANA is requested to add an entry to the existing TLS ExtensionType 345 registry, defined in RFC 5246 [RFC5246], for cached_info(TBD) defined 346 in this document. 348 7.2. New Registry for CachedInformationType 350 IANA is requested to establish a registry for TLS 351 CachedInformationType values. The first entries in the registry are 353 o certificate_list(1) 355 o certificate_authorities(2) 357 The policy for adding new values to this registry, following the 358 terminology defined in RFC 5226 [RFC5226], is as follows: 360 o 0-63 (decimal): Standards Action 362 o 64-223 (decimal): Specification Required 364 o 224-255 (decimal): reserved for Private Use 366 8. Acknowledgments 368 We would like to thank the following persons for your detailed 369 document reviews: 371 o Paul Wouters and Nikos Mavrogiannopoulos (December 2011) 373 o Rob Stradling (February 2012) 375 o Ondrej Mikle (in March 2012) 377 o Ilari Liusvaara, Adam Langley, and Eric Rescorla (in July 2014) 379 Additionally, we would like to thank the TLS working group chairs, 380 Sean Turner and Joe Salowey, as well as the responsible security area 381 director, Stephen Farrell, for his support. 383 9. References 385 9.1. Normative References 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, March 1997. 390 [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", 391 RFC 3874, September 2004. 393 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 394 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 396 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 397 Extension Definitions", RFC 6066, January 2011. 399 9.2. Informative References 401 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 402 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 403 May 2008. 405 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 406 Workshop", RFC 6574, April 2012. 408 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 409 T. Kivinen, "Using Raw Public Keys in Transport Layer 410 Security (TLS) and Datagram Transport Layer Security 411 (DTLS)", RFC 7250, June 2014. 413 Authors' Addresses 414 Stefan Santesson 415 3xA Security AB 416 Scheelev. 17 417 Lund 223 70 418 Sweden 420 Email: sts@aaa-sec.com 422 Hannes Tschofenig 423 ARM Ltd. 424 Hall in Tirol 6060 425 Austria 427 Email: Hannes.tschofenig@gmx.net 428 URI: http://www.tschofenig.priv.at