idnits 2.17.1 draft-ietf-tls-cached-info-19.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 (March 23, 2015) is 3316 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 321 -- Looks like a reference, but probably isn't: '2' on line 340 -- Looks like a reference, but probably isn't: '3' on line 342 -- Looks like a reference, but probably isn't: '4' on line 343 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 352, but not defined ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** 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 (~~), 3 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: September 24, 2015 ARM Ltd. 6 March 23, 2015 8 Transport Layer Security (TLS) Cached Information Extension 9 draft-ietf-tls-cached-info-19.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 September 24, 2015. 41 Copyright Notice 43 Copyright (c) 2015 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 4. Exchange Specification . . . . . . . . . . . . . . . . . . . 4 62 4.1. Server Certificate Message . . . . . . . . . . . . . . . 5 63 4.2. CertificateRequest Message . . . . . . . . . . . . . . . 6 64 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 9 68 7.2. New Registry for CachedInformationType . . . . . . . . . 9 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Reducing the amount of information exchanged during a Transport Layer 78 Security handshake to a minimum helps to improve performance in 79 environments where devices are connected to a network with a low 80 bandwidth, and lossy radio technology. With Internet of Things such 81 environments exist, for example, when devices use IEEE 802.15.4 or 82 Bluetooth Smart. For more information about the challenges with 83 smart object deployments please see [RFC6574]. 85 This specification defines a TLS extension that allows a client and a 86 server to exclude transmission information cached in an earlier TLS 87 handshake. 89 A typical example exchange may therefore look as follows. First, the 90 client and the server executes the full TLS handshake. The client 91 then caches the certificate provided by the server. When the TLS 92 client connects to the TLS server some time in the future, without 93 using session resumption, it then attaches the cached_info extension 94 defined in this document to the client hello message to indicate that 95 it had cached the certificate, and it provides the fingerprint of it. 96 If the server's certificate has not changed then the TLS server does 97 not need to send its' certificate and the corresponding certificate 98 chain again. In case information has changed, which can be seen from 99 the fingerprint provided by the client, the certificate payload is 100 transmitted to the client to allow the client to update the cache. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 This document refers to the TLS protocol but the description is 109 equally applicable to DTLS as well. 111 3. Cached Information Extension 113 This document defines a new extension type (cached_info(TBD)), which 114 is used in client hello and server hello messages. The extension 115 type is specified as follows. 117 enum { 118 cached_info(TBD), (65535) 119 } ExtensionType; 121 The extension_data field of this extension, when included in the 122 client hello, MUST contain the CachedInformation structure. The 123 client MAY send multiple CachedObjects of the same 124 CachedInformationType. This may, for example, be the case when the 125 client has cached multiple certificates from a server. 127 enum { 128 cert(1), cert_req(2) (255) 129 } CachedInformationType; 131 struct { 132 select (type) { 133 case client: 134 CachedInformationType type; 135 opaque hash_value<1..255>; 136 case server: 137 CachedInformationType type; 138 } body; 139 } CachedObject; 141 struct { 142 CachedObject cached_info<1..2^16-1>; 143 } CachedInformation; 145 This document defines the following types: 147 Omitting the Server Certificate Message: 149 With the type field set to 'cert', the client MUST include the 150 message digest of the Certificate message in the hash_value field. 151 For this type the message digest MUST be calculated using SHA-256 152 [RFC4634]. 154 Omitting the CertificateRequest Message 156 With the type set to 'cert_req', the client MUST include the 157 message digest of the CertificateRequest message in the hash_value 158 field. For this type the message digest MUST be calculated using 159 SHA-256 [RFC4634]. 161 New types can be added following the policy described in the IANA 162 considerations section, see Section 7. Different message digest 163 algorithms for use with these types can also be added by registering 164 a new type that makes use of this updated message digest algorithm. 166 4. Exchange Specification 168 Clients supporting this extension MAY include the "cached_info" 169 extension in the (extended) client hello. If the client includes the 170 extension then it MUST contain one or more CachedObject attributes. 172 A server supporting this extension MAY include the "cached_info" 173 extension in the (extended) server hello. By returning the 174 "cached_info" extension the server indicates that it supports the 175 cached info types. For each indicated cached info type the server 176 MUST alter the transmission of respective payloads, according to the 177 rules outlined with each type. If the server includes the extension 178 it MUST only include CachedObjects of a type also supported by the 179 client (as expressed in the client hello). For example, if a client 180 indicates support for 'cert' and 'cert_req' then the server cannot 181 respond with a "cached_info" attribute containing support for 182 'cert_status'. 184 Since the client includes a fingerprint of information it cached (for 185 each indicated type) the server is able to determine whether cached 186 information is stale. If the server supports this specification and 187 notices a mismatch between the data cached by the client and its own 188 information then the server MUST include the information in full and 189 MUST NOT list the respective type in the "cached_info" extension. 191 Note: If a server is part of a hosting environment then the client 192 may have cached multiple data items for a single server. To allow 193 the client to select the appropriate information from the cache it is 194 RECOMMENDED that the client utilizes the Server Name Indication 195 extension [RFC6066]. 197 Following a successful exchange of the "cached_info" extension in the 198 client and server hello, the server alters sending the corresponding 199 handshake message. How information is altered from the handshake 200 messages is defined in Section 4.1, and in Section 4.2 for the types 201 defined in this specification. 203 4.1. Server Certificate Message 205 When a ClientHello message contains the "cached_info" extension with 206 a type set to 'cert' then the server MAY send the Certificate message 207 shown in Figure 2 under the following conditions: 209 The server software implements the "cached_info" extension defined 210 in this specification. 212 The 'cert' cached info extension is enabled (for example, a policy 213 allows the use of this extension). 215 The server compared the value in the hash_value field of the 216 client-provided "cached_info" extension with the fingerprint of 217 the Certificate message it normally sends to clients. This check 218 ensures that the information cached by the client is current. 220 The original Certificate handshake message syntax is defined in RFC 221 5246 [RFC5246] and has the structure shown in Figure 1. 223 opaque ASN.1Cert<1..2^24-1>; 225 struct { 226 ASN.1Cert certificate_list<0..2^24-1>; 227 } Certificate; 229 Figure 1: Certificate Message as defined in RFC 5246. 231 The new structure of the CertificateRequest message is shown in 232 Figure 2. 234 struct { 235 opaque hash_value<1..255>; 236 } CertificateRequest; 238 Figure 2: Cached Info Certificate Message. 240 The fingerprint MUST be computed as follows: hash_value:=SHA- 241 256(Certificate) 243 Note that RFC 7250 [RFC7250] allows the certificate payload to 244 contain only the SubjectPublicKeyInfo instead of the full information 245 typically found in a certificate. Hence, when this specification is 246 used in combination with [RFC7250] and the negotiated certificate 247 type is a raw public key then the TLS server omits sending a 248 Certificate payload that contains an ASN.1 Certificate structure with 249 the included SubjectPublicKeyInfo rather than the full certificate. 250 As such, this extension is compatible with the raw public key 251 extension defined in RFC 7250. 253 4.2. CertificateRequest Message 255 When a fingerprint for an object of type 'cert_req' is provided in 256 the client hello, the server MAY omit the CertificateRequest message 257 under the following conditions: 259 The server software implements the "cached_info" extension defined 260 in this specification. 262 The 'cert_req' cached info extension is enabled (for example, a 263 policy allows the use of this extension). 265 The server compared the value in the hash_value field of the 266 client-provided "cached_info" extension with the fingerprint of 267 the CertificateRequest message it normally sends to clients. This 268 check ensures that the information cached by the client is 269 current. 271 The server wants to request a certificate from the client. 273 The original CertificateRequest handshake message syntax is defined 274 in RFC 5246 [RFC5246] and has the following structure: 276 opaque DistinguishedName<1..2^16-1>; 278 struct { 279 ClientCertificateType certificate_types<1..2^8-1>; 280 SignatureAndHashAlgorithm 281 supported_signature_algorithms<2^16-1>; 282 DistinguishedName certificate_authorities<0..2^16-1>; 283 } CertificateRequest; 285 Figure 3: CertificateRequest Message as defined in RFC 5246. 287 The new structure of the CertificateRequest message is shown in 288 Figure 4. 290 struct { 291 opaque hash_value<1..255>; 292 } CertificateRequest; 294 Figure 4: Cached Info CertificateRequest Message. 296 The fingerprint MUST be computed as follows: hash_value:=SHA- 297 256(CertificateRequest) 299 5. Example 301 Figure 5 illustrates an example exchange using the TLS cached info 302 extension. In the normal TLS handshake exchange shown in flow (A) 303 the TLS server provides its certificate in the Certificate payload to 304 the client, see step [1]. This allows the client to store the 305 certificate for future use. After some time the TLS client again 306 interacts with the same TLS server and makes use of the TLS cached 307 info extension, as shown in flow (B). The TLS client indicates 308 support for this specification via the "cached_info" extension, see 309 [2], and indicates that it has stored the certificate from the 310 earlier exchange (by indicating the 'cert' type). With [3] the TLS 311 server acknowledges the supports of the 'cert' type and by including 312 the value in the server hello informs the client that the content of 313 the certificate payload contains the fingerprint of the certificate 314 instead of the RFC 5246-defined payload of the certificate message in 315 message [4]. 317 (A) Initial (full) Exchange 319 ClientHello -> 320 <- ServerHello 321 Certificate* // [1] 322 ServerKeyExchange* 323 CertificateRequest* 324 ServerHelloDone 326 Certificate* 327 ClientKeyExchange 328 CertificateVerify* 329 [ChangeCipherSpec] 330 Finished -> 332 <- [ChangeCipherSpec] 333 Finished 335 Application Data <-------> Application Data 337 (B) TLS Cached Extension Usage 339 ClientHello 340 cached_info=(cert) -> // [2] 341 <- ServerHello 342 cached_info=(cert) [3] 343 Certificate [4] 344 ServerKeyExchange* 345 ServerHelloDone 347 ClientKeyExchange 348 CertificateVerify* 349 [ChangeCipherSpec] 350 Finished -> 352 <- [ChangeCipherSpec] 353 Finished 355 Application Data <-------> Application Data 357 Figure 5: Example Message Exchange 359 6. Security Considerations 361 This specification defines a mechanism to reference stored state 362 using a fingerprint. Sending a fingerprint of cached information in 363 an unencrypted handshake, as the client and server hello is, may 364 allow an attacker or observer to correlate independent TLS exchanges. 365 While some information elements used in this specification, such as 366 server certificates, are public objects and usually do not contain 367 sensitive information, other (not yet defined cached info types) may. 368 Those who implement and deploy this specification should therefore 369 make an informed decision whether the cached information is inline 370 with their security and privacy goals. In case of concerns, it is 371 advised to avoid sending the fingerprint of the data objects in 372 clear. 374 The use of the cached info extension allows the server to obmit 375 sending certain TLS messages. Consequently, these omitted messages 376 are not included in the transcript of the handshake in the TLS Finish 377 message per value. However, since the client communicates the hash 378 values of the cached values in the initial handshake message the 379 fingerprints are included in the TLS Finish message. 381 Clients MUST ensure that they only cache information from legitimate 382 sources. For example, when the client populates the cache from a TLS 383 exchange then it must only cache information after the successful 384 completion of a TLS exchange to ensure that an attacker does not 385 inject incorrect information into the cache. Failure to do so allows 386 for man-in-the-middle attacks. 388 7. IANA Considerations 390 7.1. New Entry to the TLS ExtensionType Registry 392 IANA is requested to add an entry to the existing TLS ExtensionType 393 registry, defined in RFC 5246 [RFC5246], for cached_info(TBD) defined 394 in this document. 396 7.2. New Registry for CachedInformationType 398 IANA is requested to establish a registry for TLS 399 CachedInformationType values. The first entries in the registry are 401 o cert(1) 403 o cert_req(2) 405 The policy for adding new values to this registry, following the 406 terminology defined in RFC 5226 [RFC5226], is as follows: 408 o 0-63 (decimal): Standards Action 410 o 64-223 (decimal): Specification Required 411 o 224-255 (decimal): reserved for Private Use 413 8. Acknowledgments 415 We would like to thank the following persons for your detailed 416 document reviews: 418 o Paul Wouters and Nikos Mavrogiannopoulos (December 2011) 420 o Rob Stradling (February 2012) 422 o Ondrej Mikle (in March 2012) 424 o Ilari Liusvaara, Adam Langley, and Eric Rescorla (in July 2014) 426 o Sean Turner (in August 2014) 428 Additionally, we would like to thank the TLS working group chairs, 429 Sean Turner and Joe Salowey, as well as the responsible security area 430 director, Stephen Farrell, for their support. 432 9. References 434 9.1. Normative References 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, March 1997. 439 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 440 (SHA and HMAC-SHA)", RFC 4634, July 2006. 442 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 443 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 445 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 446 Extension Definitions", RFC 6066, January 2011. 448 9.2. Informative References 450 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 451 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 452 May 2008. 454 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 455 Workshop", RFC 6574, April 2012. 457 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 458 T. Kivinen, "Using Raw Public Keys in Transport Layer 459 Security (TLS) and Datagram Transport Layer Security 460 (DTLS)", RFC 7250, June 2014. 462 Authors' Addresses 464 Stefan Santesson 465 3xA Security AB 466 Scheelev. 17 467 Lund 223 70 468 Sweden 470 Email: sts@aaa-sec.com 472 Hannes Tschofenig 473 ARM Ltd. 474 Hall in Tirol 6060 475 Austria 477 Email: Hannes.tschofenig@gmx.net 478 URI: http://www.tschofenig.priv.at