idnits 2.17.00 (12 Aug 2021) /tmp/idnits45144/draft-ietf-tls-cached-info-18.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 8, 2015) is 2631 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 353 -- Looks like a reference, but probably isn't: '2' on line 372 -- Looks like a reference, but probably isn't: '3' on line 374 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 383, but not defined == Unused Reference: 'RFC3874' is defined on line 473, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3874 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 9, 2015 ARM Ltd. 6 March 8, 2015 8 Transport Layer Security (TLS) Cached Information Extension 9 draft-ietf-tls-cached-info-18.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 9, 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 . . . . . . . . . . . . . . . . . . . 5 62 4.1. Omitting the Server Certificate Message . . . . . . . . . 5 63 4.2. Omitting the CertificateRequest Message . . . . . . . . . 6 64 4.3. Omitting the Certificate Status Information (OCSP 65 Stapling and Multi OCSP Stapling) . . . . . . . . . . . . 7 66 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 10 70 7.2. New Registry for CachedInformationType . . . . . . . . . 10 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 9.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 devices use IEEE 802.15.4 or 85 Bluetooth Smart. For more information about the challenges with 86 smart object deployments please see [RFC6574]. 88 This specification defines a TLS extension that allows a client and a 89 server to exclude transmission information cached in an earlier TLS 90 handshake. 92 A typical example exchange may therefore look as follows. First, the 93 client and the server executes the usual TLS handshake. The client 94 may, for example, decide to cache the certificate provided by the 95 server. When the TLS client connects to the TLS server some time in 96 the future, without using session resumption, it then attaches the 97 cached_info extension defined in this document to the client hello 98 message to indicate that it had cached the certificate, and it 99 provides the fingerprint of it. If the server's certificate has not 100 changed then the TLS server does not need to send its' certificate 101 and the corresponding certificate list again. In case information 102 has changed, which can be seen from the fingerprint provided by the 103 client, the certificate payload is transmitted to the client to allow 104 the client to update the cache. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 This document refers to the TLS protocol but the description is 113 equally applicable to DTLS as well. 115 3. Cached Information Extension 117 This document defines a new extension type (cached_info(TBD)), which 118 is used in client hello and server hello messages. The extension 119 type is specified as follows. 121 enum { 122 cached_info(TBD), (65535) 123 } ExtensionType; 125 The extension_data field of this extension, when included in the 126 client hello, MUST contain the CachedInformation structure. The 127 client MUST NOT send multiple CachedObjects of the same 128 CachedInformationType. 130 enum { 131 cert(1), cert_req(2) (255) 132 } CachedInformationType; 134 struct { 135 select (type) { 136 case client: 137 CachedInformationType type; 138 opaque hash_value<1..255>; 139 case server: 140 CachedInformationType type; 141 } body; 142 } CachedObject; 144 struct { 145 CachedObject cached_info<1..2^16-1>; 146 } CachedInformation; 148 This document defines the following types: 150 Omitting the Server Certificate Message: 152 With the type field set to 'cert', the client MUST include the 153 message digest of the Certificate message in the hash_value field. 154 For this type the message digest MUST be calculated using SHA-256 155 [RFC4634]. 157 Omitting the CertificateRequest Message 159 With the type set to 'cert_req', the client MUST include the 160 message digest of the CertificateRequest message in the hash_value 161 field. For this type the message digest MUST be calculated using 162 SHA-256 [RFC4634]. 164 Omitting the Certificate Status Information (OCSP Stapling and 165 Multiple OCSP Stapling) Message 167 With the type set to 'cert_status', the client MUST include the 168 message digest of the CertificateStatus message in the hash_value 169 field. For this type the message digest MUST be calculated using 170 SHA-256 [RFC4634]. 172 New types can be added following the policy described in the IANA 173 considerations section, see Section 7. Different message digest 174 algorithms for use with these types can also be added by registering 175 a new type that makes use of this updated message digest algorithm. 177 4. Exchange Specification 179 Clients supporting this extension MAY include the "cached_info" 180 extension in the (extended) client hello. If the client includes the 181 extension then it MUST contain one or more CachedObject attributes. 183 A server supporting this extension MAY include the "cached_info" 184 extension in the (extended) server hello. By returning the 185 "cached_info" extension the server indicates that it supports the 186 cached info types. For each indicated cached info type the server 187 MUST alter the transmission of respective payloads, according to the 188 rules outlined with each type. If the server includes the extension 189 it MUST only include CachedObjects of a type also supported by the 190 client (as expressed in the client hello). For example, if a client 191 indicates support for 'cert' and 'cert_req' then the server cannot 192 respond with a "cached_info" attribute containing support for 193 'cert_status'. 195 Since the client includes a fingerprint of information it cached (for 196 each indicated type) the server is able 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 type in the "cached_info" extension. 202 Note: If a server is part of a hosting environment then the client 203 may have cached multiple data items for a single server. To allow 204 the client to select the appropriate information from the cache it is 205 RECOMMENDED that the client utilizes the Server Name Indication 206 extension [RFC6066]. 208 Following a successful exchange of the "cached_info" extension in the 209 client and server hello, the server alters sending the corresponding 210 handshake message. How information is altered from the handshake 211 messages is defined in Section 4.1, Section 4.2 and Section 4.3 for 212 the types defined in this specification. 214 4.1. Omitting the Server Certificate Message 216 When a ClientHello message contains the "cached_info" extension with 217 a type set to 'cert' then the server MAY omit the Certificate message 218 under the following conditions: 220 The server software implements the "cached_info" extension defined 221 in this specification. 223 The 'cert' cached info extension is enabled (for example, a policy 224 allows the use of this extension). 226 The server compared the value in the hash_value field of the 227 client-provided "cached_info" extension with the fingerprint of 228 the Certificate message it normally sends to clients. This check 229 ensures that the information cached by the client is current. 231 The original Certificate handshake message syntax is defined in RFC 232 5246 [RFC5246] and has the following structure: 234 opaque ASN.1Cert<1..2^24-1>; 236 struct { 237 ASN.1Cert certificate_list<0..2^24-1>; 238 } Certificate; 240 Certificate Message as defined in RFC 5246. 242 The fingerprint MUST be computed as follows: hash_value:=SHA- 243 256(Certificate) 245 Note that RFC 7250 [RFC7250] allows the certificate payload to 246 contain only the SubjectPublicKeyInfo instead of the full information 247 typically found in a certificate. Hence, when this specification is 248 used in combination with [RFC7250] and the negotiated certificate 249 type is a raw public key then the TLS server omits sending a 250 Certificate payload that contains an ASN.1 Certificate structure with 251 the included SubjectPublicKeyInfo rather than the full certificate. 252 As such, this extension is compatible with the raw public key 253 extension defined in RFC 7250. 255 4.2. Omitting the CertificateRequest Message 257 When a fingerprint for an object of type 'cert_req' is provided in 258 the client hello, the server MAY omit the CertificateRequest message 259 under the following conditions: 261 The server software implements the "cached_info" extension defined 262 in this specification. 264 The 'cert_req' cached info extension is enabled (for example, a 265 policy allows the use of this extension). 267 The server compared the value in the hash_value field of the 268 client-provided "cached_info" extension with the fingerprint of 269 the CertificateRequest message it normally sends to clients. This 270 check ensures that the information cached by the client is 271 current. 273 The server wants to request a certificate from the client. 275 The original CertificateRequest handshake message syntax is defined 276 in RFC 5246 [RFC5246] and has the following structure: 278 opaque DistinguishedName<1..2^16-1>; 280 struct { 281 ClientCertificateType certificate_types<1..2^8-1>; 282 SignatureAndHashAlgorithm 283 supported_signature_algorithms<2^16-1>; 284 DistinguishedName certificate_authorities<0..2^16-1>; 285 } CertificateRequest; 287 The fingerprint MUST be computed as follows: hash_value:=SHA- 288 256(CertificateRequest) 290 4.3. Omitting the Certificate Status Information (OCSP Stapling and 291 Multi OCSP Stapling) 293 When a fingerprint for an object of type 'cert_status' is provided in 294 the client hello, the server MAY omit the CertificateStatus message 295 under the following conditions: 297 The server software implements the "cert_status" extension defined 298 in this specification. 300 The 'cert_status' cached info extension is enabled (for example, a 301 policy allows the use of this extension). 303 The server compared the value in the hash_value field of the 304 client-provided "cached_info" extension with the fingerprint of 305 the CertificateStatus message it normally sends to clients. This 306 check ensures that the information cached by the client is 307 current. 309 Both client and server support the use of OCSP Stapling and/or 310 Multiple OCSP Stapling, as defined in RFC 6066 [RFC6066] and in 311 [RFC6961]. 313 The CertificateStatus message syntax, defined in [RFC6961], has the 314 following structure: 316 struct { 317 CertificateStatusType status_type; 318 select (status_type) { 319 case ocsp: OCSPResponse; 320 case ocsp_multi: OCSPResponseList; 321 } response; 322 } CertificateStatus; 324 opaque OCSPResponse<0..2^24-1>; 326 struct { 327 OCSPResponse ocsp_response_list<1..2^24-1>; 328 } OCSPResponseList; 330 The fingerprint MUST be computed as follows: hash_value:=SHA- 331 256(CertificateStatus) 333 5. Example 335 Figure 1 illustrates an example exchange using the TLS cached info 336 extension. In the normal TLS handshake exchange shown in flow (A) 337 the TLS server provides its certificate in the Certificate payload to 338 the client, see step [1]. This allows the client to store the 339 certificate for future use. After some time the TLS client again 340 interacts with the same TLS server and makes use of the TLS cached 341 info extension, as shown in flow (B). The TLS client indicates 342 support for this specification via the "cached_info" extension, see 343 [2], and indicates that it has stored the certificate from the 344 earlier exchange (by indicating the 'cert' type). With [3] the TLS 345 server acknowledges the supports of the 'cert' type and by including 346 the value in the server hello informs the client that the certificate 347 payload has been omitted. 349 (A) Initial (full) Exchange 351 ClientHello -> 352 <- ServerHello 353 Certificate* // [1] 354 ServerKeyExchange* 355 CertificateRequest* 356 ServerHelloDone 358 Certificate* 359 ClientKeyExchange 360 CertificateVerify* 361 [ChangeCipherSpec] 362 Finished -> 364 <- [ChangeCipherSpec] 365 Finished 367 Application Data <-------> Application Data 369 (B) TLS Cached Extension Usage 371 ClientHello 372 cached_info=(cert) -> // [2] 373 <- ServerHello 374 cached_info=(cert) [3] 375 ServerKeyExchange* 376 ServerHelloDone 378 ClientKeyExchange 379 CertificateVerify* 380 [ChangeCipherSpec] 381 Finished -> 383 <- [ChangeCipherSpec] 384 Finished 386 Application Data <-------> Application Data 388 Figure 1: Example Message Exchange 390 6. Security Considerations 392 This specification defines a mechanism to reference stored state 393 using a fingerprint. Sending a fingerprint of cached information in 394 an unencrypted handshake, as the client and server hello is, may 395 allow an attacker or observer to correlate independent TLS exchanges. 397 While some information elements used in this specification, such as 398 server certificates, are public objects and usually do not contain 399 sensitive information, other (not yet defined cached info types) may. 400 Those who implement and deploy this specification should therefore 401 make an informed decision whether the cached information is inline 402 with their security and privacy goals. In case of concerns, it is 403 advised to avoid sending the fingerprint of the data objects in 404 clear. 406 The use of the cached info extension allows the server to obmit 407 sending certain TLS messages. Consequently, these omitted messages 408 are not included in the transcript of the handshake in the TLS Finish 409 message per value. However, since the client communicates the hash 410 values of the cached values in the initial handshake message the 411 fingerprints are included in the TLS Finish message. 413 Clients MUST ensure that they only cache information from legitimate 414 sources. For example, when the client populates the cache from a TLS 415 exchange then it must only cache information after the successful 416 completion of a TLS exchange to ensure that an attacker does not 417 inject incorrect information into the cache. Failure to do so allows 418 for man-in-the-middle attacks. 420 7. IANA Considerations 422 7.1. New Entry to the TLS ExtensionType Registry 424 IANA is requested to add an entry to the existing TLS ExtensionType 425 registry, defined in RFC 5246 [RFC5246], for cached_info(TBD) defined 426 in this document. 428 7.2. New Registry for CachedInformationType 430 IANA is requested to establish a registry for TLS 431 CachedInformationType values. The first entries in the registry are 433 o cert(1) 435 o cert_req(2) 437 o cert_status(3) 439 The policy for adding new values to this registry, following the 440 terminology defined in RFC 5226 [RFC5226], is as follows: 442 o 0-63 (decimal): Standards Action 444 o 64-223 (decimal): Specification Required 445 o 224-255 (decimal): reserved for Private Use 447 8. Acknowledgments 449 We would like to thank the following persons for your detailed 450 document reviews: 452 o Paul Wouters and Nikos Mavrogiannopoulos (December 2011) 454 o Rob Stradling (February 2012) 456 o Ondrej Mikle (in March 2012) 458 o Ilari Liusvaara, Adam Langley, and Eric Rescorla (in July 2014) 460 o Sean Turner (in August 2014) 462 Additionally, we would like to thank the TLS working group chairs, 463 Sean Turner and Joe Salowey, as well as the responsible security area 464 director, Stephen Farrell, for their support. 466 9. References 468 9.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", 474 RFC 3874, September 2004. 476 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 477 (SHA and HMAC-SHA)", RFC 4634, July 2006. 479 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 480 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 482 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 483 Extension Definitions", RFC 6066, January 2011. 485 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 486 Multiple Certificate Status Request Extension", RFC 6961, 487 June 2013. 489 9.2. Informative References 491 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 492 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 493 May 2008. 495 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 496 Workshop", RFC 6574, April 2012. 498 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 499 T. Kivinen, "Using Raw Public Keys in Transport Layer 500 Security (TLS) and Datagram Transport Layer Security 501 (DTLS)", RFC 7250, June 2014. 503 Appendix A. Example 505 The Wireshark trace of an example TLS exchange shown in Figure 2 506 illustrates the use of an ECC-based ciphersuite with a 256 bit key. 507 ECC allows for a small certificate size compared to RSA with 508 equivalent security strength. The Certificate message provided by 509 the server is with 557 bytes (including the record layer header) one 510 of the largest message even though it only contains a single 511 certificate (i.e., no intermediate CA certificates). The client- 512 provided Certificate message has a length of 570 bytes (also 513 including the record layer header). 515 Client --> Server: 517 TLSv1.2 Record Layer: Handshake Protocol: Client Hello 518 Content Type: Handshake (22) 519 Version: TLS 1.2 (0x0303) 520 Length: 121 521 Handshake Protocol: Client Hello 522 Handshake Type: Client Hello (1) 523 Length: 117 524 Version: TLS 1.2 (0x0303) 525 Random 526 gmt_unix_time: Jan 14, 2015 12:43:58.000000000 CET 527 random_bytes: c61b966bba2781c50b07c3278c43f5892b3d... 528 Session ID Length: 0 529 Cipher Suites Length: 10 530 Cipher Suites (5 suites) 531 Compression Methods Length: 1 532 Compression Methods (1 method) 533 Extensions Length: 66 534 Extension: server_name 535 Extension: signature_algorithms 536 Extension: elliptic_curves 537 Extension: ec_point_formats 539 Client <-- Server: 541 TLSv1.2 Record Layer: Handshake Protocol: Server Hello 542 Content Type: Handshake (22) 543 Version: TLS 1.2 (0x0303) 544 Length: 87 545 Handshake Protocol: Server Hello 546 Handshake Type: Server Hello (2) 547 Length: 83 548 Version: TLS 1.2 (0x0303) 549 Random 550 gmt_unix_time: Jan 14, 2015 12:43:58.000000000 CET 551 random_bytes: 82d3d09b44149d738b7002da4ff5a986fe11... 552 Session ID Length: 32 553 Session ID: d069a74661088676b98db8346070278a7475b617a0... 554 Cipher Suite: Unknown (0xc0ad) 555 Compression Method: null (0) 556 Extensions Length: 11 557 Extension: renegotiation_info 558 Extension: ec_point_formats 560 TLSv1.2 Record Layer: Handshake Protocol: Certificate 561 Content Type: Handshake (22) 562 Version: TLS 1.2 (0x0303) 563 Length: 557 564 Handshake Protocol: Certificate 565 Handshake Type: Certificate (11) 566 Length: 553 567 Certificates Length: 550 568 Certificates (550 bytes) 569 Certificate Length: 547 570 Certificate (id-at-commonName=localhost, 571 id-at-organizationName=PolarSSL,id-at-countryName=NL) 572 signedCertificate 573 algorithmIdentifier (iso.2.840.10045.4.3.2) 574 Padding: 0 575 encrypted: 30650231009a2c5cd7a6dba2e5640df0b94ed... 577 TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange 578 Content Type: Handshake (22) 579 Version: TLS 1.2 (0x0303) 580 Length: 215 581 Handshake Protocol: Server Key Exchange 582 Handshake Type: Server Key Exchange (12) 583 Length: 211 585 TLSv1.2 Record Layer: Handshake Protocol: Certificate Request 586 Content Type: Handshake (22) 587 Version: TLS 1.2 (0x0303) 588 Length: 78 589 Handshake Protocol: Certificate Request 590 Handshake Type: Certificate Request (13) 591 Length: 74 592 Certificate types count: 1 593 Certificate types (1 type) 594 Signature Hash Algorithms Length: 2 595 Signature Hash Algorithms (1 algorithm) 596 Distinguished Names Length: 66 597 Distinguished Names (66 bytes) 599 TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done 600 Content Type: Handshake (22) 601 Version: TLS 1.2 (0x0303) 602 Length: 4 603 Handshake Protocol: Server Hello Done 604 Handshake Type: Server Hello Done (14) 605 Length: 0 607 Client --> Server: 609 TLSv1.2 Record Layer: Handshake Protocol: Certificate 610 Content Type: Handshake (22) 611 Version: TLS 1.2 (0x0303) 612 Length: 570 613 Handshake Protocol: Certificate 614 Handshake Type: Certificate (11) 615 Length: 566 616 Certificates Length: 563 617 Certificates (563 bytes) 618 Certificate Length: 560 619 Certificate (id-at-commonName=PolarSSL Test Client 2, 620 id-at-organizationName=PolarSSL,id-at-countryName=NL) 621 signedCertificate 622 algorithmIdentifier (iso.2.840.10045.4.3.2) 623 Padding: 0 624 encrypted: 306502304a650d7b2083a299b9a80ffc8dee8... 626 TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange 627 Content Type: Handshake (22) 628 Version: TLS 1.2 (0x0303) 629 Length: 138 630 Handshake Protocol: Client Key Exchange 631 Handshake Type: Client Key Exchange (16) 632 Length: 134 634 TLSv1.2 Record Layer: Handshake Protocol: Certificate Verify 635 Content Type: Handshake (22) 636 Version: TLS 1.2 (0x0303) 637 Length: 80 638 Handshake Protocol: Certificate Verify 639 Handshake Type: Certificate Verify (15) 640 Length: 76 642 TLSv1.2 Record Layer: Change Cipher Spec Protocol 643 Content Type: Change Cipher Spec (20) 644 Version: TLS 1.2 (0x0303) 645 Length: 1 646 Change Cipher Spec Message 648 TLSv1.2 Record Layer: Handshake Protocol: 649 Encrypted Handshake Message (TLS Finished) 650 Content Type: Handshake (22) 651 Version: TLS 1.2 (0x0303) 652 Length: 40 653 Handshake Protocol: Encrypted Handshake Message 655 Client <-- Server: 657 TLSv1.2 Record Layer: Change Cipher Spec Protocol 658 Content Type: Change Cipher Spec (20) 659 Version: TLS 1.2 (0x0303) 660 Length: 1 661 Change Cipher Spec Message 663 TLSv1.2 Record Layer: Handshake Protocol 664 Encrypted Handshake Message (TLS Finished) 665 Content Type: Handshake (22) 666 Version: TLS 1.2 (0x0303) 667 Length: 40 668 Handshake Protocol: Encrypted Handshake Message 670 Figure 2: Example TLS Exchange (without Cached Info Extension). 672 The total size of the TLS exchange shown in Figure 2 is 1932 bytes 673 whereas the exchange shown in Figure 3 reduces the size to 1323 bytes 674 by omitting the Certificate and the CertificateRequest messages. As 675 it can be seen, the use of the cached info extension leads to an on- 676 the-wire improvement of more than 600 bytes. 678 Client --> Server: 680 TLSv1.2 Record Layer: Handshake Protocol: Client Hello 681 Content Type: Handshake (22) 682 Version: TLS 1.2 (0x0303) 683 Length: 121 + 21 684 Handshake Protocol: Client Hello 685 Handshake Type: Client Hello (1) 686 Length: 117 + 21 687 Version: TLS 1.2 (0x0303) 688 Random 689 gmt_unix_time: Jan 14, 2015 12:43:58.000000000 CET 690 random_bytes: c61b966bba2781c50b07c3278c43f5892b3d... 691 Session ID Length: 0 692 Cipher Suites Length: 10 693 Cipher Suites (5 suites) 694 Compression Methods Length: 1 695 Compression Methods (1 method) 696 Extensions Length: 66 697 Extension: server_name 698 Extension: signature_algorithms 699 Extension: elliptic_curves 700 Extension: ec_point_formats 701 Extension: cached_info 703 Client <-- Server: 705 TLSv1.2 Record Layer: Handshake Protocol: Server Hello 706 Content Type: Handshake (22) 707 Version: TLS 1.2 (0x0303) 708 Length: 87 + 5 709 Handshake Protocol: Server Hello 710 Handshake Type: Server Hello (2) 711 Length: 83 + 5 712 Version: TLS 1.2 (0x0303) 713 Random 714 gmt_unix_time: Jan 14, 2015 12:43:58.000000000 CET 715 random_bytes: 82d3d09b44149d738b7002da4ff5a986fe11... 716 Session ID Length: 32 717 Session ID: d069a74661088676b98db8346070278a7475b617a0... 718 Cipher Suite: Unknown (0xc0ad) 719 Compression Method: null (0) 720 Extensions Length: 11 + 5 721 Extension: renegotiation_info 722 Extension: ec_point_formats 723 Extension: cached_info 725 TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange 726 Content Type: Handshake (22) 727 Version: TLS 1.2 (0x0303) 728 Length: 215 729 Handshake Protocol: Server Key Exchange 730 Handshake Type: Server Key Exchange (12) 731 Length: 211 733 TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done 734 Content Type: Handshake (22) 735 Version: TLS 1.2 (0x0303) 736 Length: 4 737 Handshake Protocol: Server Hello Done 738 Handshake Type: Server Hello Done (14) 739 Length: 0 741 Client --> Server: 743 TLSv1.2 Record Layer: Handshake Protocol: Certificate 744 Content Type: Handshake (22) 745 Version: TLS 1.2 (0x0303) 746 Length: 570 747 Handshake Protocol: Certificate 748 Handshake Type: Certificate (11) 749 Length: 566 750 Certificates Length: 563 751 Certificates (563 bytes) 752 Certificate Length: 560 753 Certificate (id-at-commonName=PolarSSL Test Client 2, 754 id-at-organizationName=PolarSSL,id-at-countryName=NL) 755 signedCertificate 756 algorithmIdentifier (iso.2.840.10045.4.3.2) 757 Padding: 0 758 encrypted: 306502304a650d7b2083a299b9a80ffc8dee8... 760 TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange 761 Content Type: Handshake (22) 762 Version: TLS 1.2 (0x0303) 763 Length: 138 764 Handshake Protocol: Client Key Exchange 765 Handshake Type: Client Key Exchange (16) 766 Length: 134 768 TLSv1.2 Record Layer: Handshake Protocol: Certificate Verify 769 Content Type: Handshake (22) 770 Version: TLS 1.2 (0x0303) 771 Length: 80 772 Handshake Protocol: Certificate Verify 773 Handshake Type: Certificate Verify (15) 774 Length: 76 776 TLSv1.2 Record Layer: Change Cipher Spec Protocol 777 Content Type: Change Cipher Spec (20) 778 Version: TLS 1.2 (0x0303) 779 Length: 1 780 Change Cipher Spec Message 782 TLSv1.2 Record Layer: Handshake Protocol: 783 Encrypted Handshake Message (TLS Finished) 784 Content Type: Handshake (22) 785 Version: TLS 1.2 (0x0303) 786 Length: 40 787 Handshake Protocol: Encrypted Handshake Message 789 Client <-- Server: 791 TLSv1.2 Record Layer: Change Cipher Spec Protocol 792 Content Type: Change Cipher Spec (20) 793 Version: TLS 1.2 (0x0303) 794 Length: 1 795 Change Cipher Spec Message 797 TLSv1.2 Record Layer: Handshake Protocol 798 Encrypted Handshake Message (TLS Finished) 799 Content Type: Handshake (22) 800 Version: TLS 1.2 (0x0303) 801 Length: 40 802 Handshake Protocol: Encrypted Handshake Message 804 Figure 3: Example TLS Exchange (with Cached Info Extension). 806 Note: To accomplish further on-the-wire handshake size message 807 reductions the Certificate message sent by the client can be reduced 808 in size by using the Client Certificate URL extension. 810 Authors' Addresses 812 Stefan Santesson 813 3xA Security AB 814 Scheelev. 17 815 Lund 223 70 816 Sweden 818 Email: sts@aaa-sec.com 819 Hannes Tschofenig 820 ARM Ltd. 821 Hall in Tirol 6060 822 Austria 824 Email: Hannes.tschofenig@gmx.net 825 URI: http://www.tschofenig.priv.at