idnits 2.17.1 draft-rescorla-tls-ctls-03.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 (November 04, 2019) is 1634 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RandomLength' is mentioned on line 244, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group E. Rescorla 3 Internet-Draft Mozilla 4 Intended status: Informational R. Barnes 5 Expires: May 7, 2020 Cisco 6 H. Tschofenig 7 Arm Limited 8 November 04, 2019 10 Compact TLS 1.3 11 draft-rescorla-tls-ctls-03 13 Abstract 15 This document specifies a "compact" version of TLS 1.3. It is 16 isomorphic to TLS 1.3 but saves space by trimming obsolete material, 17 tighter encoding, and a template-based specialization technique. cTLS 18 is not directly interoperable with TLS 1.3, but it should eventually 19 be possible for a cTLS/TLS 1.3 server to exist and successfully 20 interoperate. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 7, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 58 3. Common Primitives . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 4 61 3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1.1. KeyShare, SupportedGroups, and SignatureAlgorithms . 6 66 4.1.2. PreSharedKeys . . . . . . . . . . . . . . . . . . . . 6 67 4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.3. EncryptedExtensions . . . . . . . . . . . . . . . . . . . 7 69 4.4. CertificateRequest . . . . . . . . . . . . . . . . . . . 7 70 4.5. Certificate . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.6. CertificateVerify . . . . . . . . . . . . . . . . . . . . 8 72 4.7. Finished . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.8. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 8 74 5. Template-Based Specialization . . . . . . . . . . . . . . . . 9 75 5.1. Specifying a Specialization . . . . . . . . . . . . . . . 9 76 5.1.1. Requirements on the TLS Implementation . . . . . . . 11 77 5.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 12 78 5.1.3. Known Certificates . . . . . . . . . . . . . . . . . 13 79 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 83 Appendix A. Sample Transcripts . . . . . . . . . . . . . . . . . 15 84 A.1. ECDHE and Mutual Certificate-based Authentication . . . . 15 85 A.2. PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet 92 seen significant security analysis, so could contain major errors. 93 It should not be used as a basis for building production systems. 95 This document specifies a "compact" version of TLS 1.3 [RFC8446]. It 96 is isomorphic to TLS 1.3 but designed to take up minimal bandwidth. 97 The space reduction is achieved by four basic techniques: 99 o Omitting unnecessary values that are a holdover from previous 100 versions of TLS. 102 o Omitting the fields and handshake messages required for preserving 103 backwards-compatibility with earlier TLS versions. 105 o More compact encodings, omitting unnecessary values. 107 o A template-based specialization mechanism that allows for the 108 creation of application specific versions of TLS that omit 109 unnecessary valuses. 111 For the common (EC)DHE handshake with pre-established certificates, 112 cTLS achieves an overhead of 45 bytes over the minimum required by 113 the cryptovariables. For a PSK handshake, the overhead is 21 bytes. 114 Annotated handsdhake transcripts for these cases can be found in 115 Appendix A. 117 Because cTLS is semantically equivalent to TLS, it can be viewed 118 either as a related protocol or as a compression mechanism. 119 Specifically, it can be implemented by a layer between the TLS 120 handshake state machine and the record layer. 122 2. Conventions and Definitions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 Structure definitions listed below override TLS 1.3 definitions; any 131 PDU not internally defined is taken from TLS 1.3 except for replacing 132 integers with varints. 134 3. Common Primitives 136 3.1. Varints 138 cTLS makes use of variable-length integers in order to allow a wide 139 integer range while still providing for a minimal encoding. The 140 width of the integer is encoded in the first two bits of the field as 141 follows, with xs indicating bits that form part of the integer. 143 +----------------------------+----------------+ 144 | Bit pattern | Length (bytes) | 145 +----------------------------+----------------+ 146 | 0xxxxxxx | 1 | 147 | | | 148 | | | 149 | | | 150 | 10xxxxxx xxxxxxxx | 2 | 151 | | | 152 | | | 153 | | | 154 | 11xxxxxx xxxxxxxx xxxxxxxx | 3 | 155 +----------------------------+----------------+ 157 Thus, one byte can be used to carry values up to 127. 159 In the TLS syntax variable integers are denoted as "varint" and a 160 vector with a top range of a varint is denoted as: 162 opaque foo<1..V>; 164 With a few exceptions, cTLS replaces every integer in TLS with a 165 varint. 167 3.2. Record Layer 169 The cTLS Record Layer assumes that records are externally framed 170 (i.e., that the length is already known because it is carried in a 171 UDP datagram or the like). Depending on how this was carried, you 172 might need another byte or two for that framing. Thus, only the type 173 byte need be carried and TLSPlaintext becomes: 175 struct { 176 ContentType type; 177 opaque fragment[TLSPlaintext.length]; 178 } TLSPlaintext; 180 In addition, because the epoch is known in advance, the dummy content 181 type is not needed for the ciphertext, so TLSCiphertext becomes: 183 struct { 184 opaque content[TLSPlaintext.length]; 185 ContentType type; 186 uint8 zeros[length_of_padding]; 187 } TLSInnerPlaintext; 189 struct { 190 opaque encrypted_record[TLSCiphertext.length]; 191 } TLSCiphertext; 193 Note: The user is responsible for ensuring that the sequence numbers/ 194 nonces are handled in the usual fashion. 196 3.3. Handshake Layer 198 The cTLS handshake framing is same as the TLS 1.3 handshake framing, 199 except for two changes: 201 1. The length field is omitted 203 2. The HelloRetryRequest message is a true handshake message instead 204 of a specialization of ServerHello. 206 struct { 207 HandshakeType msg_type; /* handshake type */ 208 select (Handshake.msg_type) { 209 case client_hello: ClientHello; 210 case server_hello: ServerHello; 211 case hello_retry_request: HelloRetryRequest; 212 case end_of_early_data: EndOfEarlyData; 213 case encrypted_extensions: EncryptedExtensions; 214 case certificate_request: CertificateRequest; 215 case certificate: Certificate; 216 case certificate_verify: CertificateVerify; 217 case finished: Finished; 218 case new_session_ticket: NewSessionTicket; 219 case key_update: KeyUpdate; 220 }; 221 } Handshake; 223 3.4. Extensions 225 cTLS Extensions are the same as TLS 1.3 extensions, except varint 226 length coded: 228 struct { 229 varint extension_type; 230 opaque extension_data<0..V>; 231 } Extension; 233 4. Handshake Messages 235 In general, we retain the basic structure of each individual TLS 236 handshake message. However, the following handshake messages have 237 been modified for space reduction and cleaned up to remove pre TLS 238 1.3 baggage. 240 4.1. ClientHello 242 The cTLS ClientHello is as follows. 244 opaque Random[RandomLength]; // variable length 246 struct { 247 Random random; 248 CipherSuite cipher_suites<1..V>; 249 Extension extensions<1..V>; 250 } ClientHello; 252 4.1.1. KeyShare, SupportedGroups, and SignatureAlgorithms 254 KeyShare, SupportedGroups, and SignatureAlgorithms are identical to 255 in TLS 1.3, except for the use of varints instead of integers. Note 256 that because all of the EC DH groups are below 0x80, they will fit 257 into a single byte. This is not true for signature algorithms. 259 [[OPEN ISSUE: Should we map signature algorithms into a smaller 260 space?]] 262 4.1.2. PreSharedKeys 264 PreSharedKeys is the same as in TLS 1.3, except for the use of 265 varints instead of integers. 267 [[OPEN ISSUE: Limiting this to one value would potentially save some 268 bytes here, at the cost of generality.]] 270 4.2. ServerHello 272 We redefine ServerHello in a similar way: 274 struct { 275 Random random; 276 CipherSuite cipher_suite; 277 Extension extensions<1..V>; 278 } ServerHello; 280 4.3. EncryptedExtensions 282 Likewise, EncryptedExtensions now uses a varint length field. 284 struct { 285 Extension extensions<0..V>; 286 } EncryptedExtensions; 288 [[OPEN ISSUE: We could save 2 bytes in handshake header by omitting 289 this value when it's unneeded.]] 291 4.4. CertificateRequest 293 This message uses varint lengths and re-encodes the extensions. 295 struct { 296 opaque certificate_request_context<0..V> 297 Extension extensions<1..V>; 298 } CertificateRequest; 300 4.5. Certificate 302 We can slim down the Certficate message somewhat. 304 enum { 305 X509(0), 306 RawPublicKey(2), 307 (255) 308 } CertificateType; 310 struct { 311 select (certificate_type) { 312 case RawPublicKey: 313 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 314 opaque ASN1_subjectPublicKeyInfo<1..V>; 316 case X509: 317 opaque cert_data<1..V>; 318 }; 319 Extension extensions<0..V>; 320 } CertificateEntry; 322 struct { 323 opaque certificate_request_context<0..V> 324 CertificateEntry certificate_list<1..V>; 325 } Certificate; 327 4.6. CertificateVerify 329 This just removes the length field. ~~~~ struct { SignatureScheme 330 algorithm; // TODO - define one byte schemes? opaque signature<1..V>; 331 } CertificateVerify; ~~~~ 333 4.7. Finished 335 Unchanged. 337 4.8. HelloRetryRequest 339 The HelloRetryRequest has the following format: 341 struct { 342 CipherSuite cipher_suite; 343 Extension extensions<2..V>; 344 } HelloRetryRequest; 346 It is the same as the ServerHello above but without the unnecessary 347 sentinel Random value. 349 5. Template-Based Specialization 351 The protocol in the previous section is fully general and isomorphic 352 to TLS 1.3; effectively it's just a small cleanup of the wire 353 encoding to match what we might have done starting from scratch. It 354 achieves some compaction, but only a modest amount. cTLS also 355 includes a mechanism for achieving very high compaction using 356 template-based specialization. 358 The basic idea is that we start with the basic TLS 1.3 handshake, 359 which is fully general and then remove degrees of freedom, eliding 360 parts of the handshake which are used to express those degrees of 361 freedom. For example, if we only support one version of TLS, then it 362 is not necessary to have version negotiation and the 363 supported_versions extension can be omitted. 365 Importantly, this process is performed only for the wire encoding but 366 not for the handshake transcript. The result is that the transcript 367 for a specialized cTLS handshake is the same as the transcript for a 368 TLS 1.3 handshake with the same features used. 370 One way of thinking of this is as if specialization is a stateful 371 compression layer between the handshake and the record layer: 373 +---------------+---------------+---------------+ 374 | Handshake | Application | Alert | 375 +---------------+---------------+---------------+ +---------+ 376 | cTLS Compression Layer |<---| Profile | 377 +---------------+---------------+---------------+ +---------+ 378 | cTLS Record Layer / Application | 379 +---------------+---------------+---------------+ 381 Specializations are defined by a "compression profile" that specifies 382 what features are to be optimized out of the handshake. In the 383 following subsections, we define the structure of these profiles, and 384 how they are used in compressing and decompressing handshake 385 messages. 387 [[OPEN ISSUE: Do we want to have an explicit cTLS extension 388 indicating that cTLS is in use and which specialization is in use? 389 This goes back to whether we want the use of cTLS to be explicit.]] 391 5.1. Specifying a Specialization 393 A compression profile defining of a specialized version of TLS is 394 defined using a JSON dictionary. Each axis of specialization is a 395 key in the dictionary. [[OPEN ISSUE: If we ever want to serialize 396 this, we'll want to use a list instead.]]. 398 For example, the following specialization describes a protocol with a 399 single fixed version (TLS 1.3) and a single fixed cipher suite 400 (TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites, 401 ServerHello.cipher_suites, and the supported_versions extensions in 402 the ClientHello and ServerHello would be omitted. 404 { 405 "version" : 772, 406 "cipherSuite" : "TLS_AES_128_GCM_SHA256" 407 } 409 cTLS allows specialization along the following axes: 411 version (integer): indicates that both sides agree to the single TLS 412 version specified by the given integer value (772 == 0x0304 for 413 TLS 1.3). The supported_versions extension is omitted from 414 ClientHello.extensions and reconstructed in the transcript as a 415 single-valued list with the specified value. The 416 supported_versions extension is omitted from 417 ClientHello.extensions and reconstructed in the transcript with 418 the specified value. 420 cipherSuite (string): indicates that both sides agree to the single 421 named cipher suite, using the "TLS_AEAD_HASH" syntax defined in 422 [RFC8446], Section 8.4. The ClientHello.cipher_suites field is 423 omitted and reconstructed in the transcript as a single-valued 424 list with the specified value. The server_hello.cipher_suite 425 field is omitted and reconstructed in the transcript as the 426 specified value. 428 dhGroup (string): specifies a single DH group to use for key 429 establishment. The group is listed by the code point name in 430 [RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal 431 "supported_groups" extension consisting solely of this group. 433 signatureAlgorithm (string): specifies a single signature scheme to 434 use for authentication. The group is listed by the code point 435 name in [RFC8446], Section 4.2.7. (e.g., ed25519). This implies 436 a literal "signature_algorithms" extension consisting solely of 437 this group. 439 randomSize (integer): indicates that the ClientHello.Random and 440 ServerHello.Random values are truncated to the given values. When 441 the transcript is reconstructed, the Random is padded to the right 442 with 0s and the anti-downgrade mechanism in {{RFC8446)}, 443 Section 4.1.3 is disabled. IMPORTANT: Using short Random values 444 can lead to potential attacks. When Random values are shorter 445 than 8 bytes, PSK-only modes MUST NOT be used, and each side MUST 446 use fresh DH ephemerals. The Random length MUST be less than or 447 equal to 32 bytes. 449 clientHelloExtensions (predefined extensions): Predefined 450 ClientHello extensions, see {predefined-extensions} 452 serverHelloExtensions (predefined extensions): Predefined 453 ServerHello extensions, see {predefined-extensions} 455 encryptedExtensions (predefined extensions): Predefined 456 EncryptedExtensions extensions, see {predefined-extensions} 458 certRequestExtensions (predefined extensions): Predefined 459 CertificateRequest extensions, see {predefined-extensions} 461 knownCertificates (known certificates): A compression dictionary for 462 the Certificate message, see {known-certs} 464 finishedSize (integer): indicates that the Finished value is to be 465 truncated to the given length. When the transcript is 466 reconstructed, the remainder of the Finished value is filled in by 467 the receiving side. [[OPEN ISSUE: How short should we allow this 468 to be? TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes. 469 More analysis is needed to know the minimum safe Finished size. 470 See [RFC8446]; Section E.1 for more on this, as well as 471 https://mailarchive.ietf.org/arch/msg/tls/ 472 TugB5ddJu3nYg7chcyeIyUqWSbA.]] 474 5.1.1. Requirements on the TLS Implementation 476 To be compatible with the specializations described in this section, 477 a TLS stack needs to provide two key features: 479 If specialization of extensions is to be used, then the TLS stack 480 MUST order each vector of Extension values in ascending order 481 according to the ExtensionType. This allows for a deterministic 482 reconstruction of the extension list. 484 If truncated Random values are to be used, then the TLS stack MUST be 485 configurable to set the remaining bytes of the random values to zero. 486 This ensures that the reconstructed, padded random value matches the 487 original. 489 If truncated Finished values are to be used, then the TLS stack MUST 490 be configurable so that only the provided bytes of the Finished are 491 verified, or so that the expected remaining values can be computed. 493 5.1.2. Predefined Extensions 495 Extensions used in the ClientHello, ServerHello, EncryptedExtensions, 496 and CertificateRequest messages can be "predefined" in a compression 497 profile, so that they do not have to be sent on the wire. A 498 predefined extensions object is a dictionary whose keys are extension 499 names specified in the TLS ExtensionTypeRegistry specified in 500 [RFC8446]. The corresponding value is a hex-encoded value for the 501 ExtensionData field of the extension. 503 When compressing a handshake message, the sender compares the 504 extensions in the message being compressed to the predefined 505 extensions object, applying the following rules: 507 o If the extensions list in the message is not sorted in ascending 508 order by extension type, it is an error, because the decompressed 509 message will not match. 511 o If there is no entry in the predefined extensions object for the 512 type of the extension, then the extension is included in the 513 compressed message 515 o If there is an entry: 517 * If the ExtensionData of the extension does not match the value 518 in the dictionary, it is an error, because decompression will 519 not produce the correct result. 521 * If the ExtensionData matches, then the extension is removed, 522 and not included in the compressed message. 524 When decompressing a handshake message the receiver reconstitutes the 525 original extensions list using the predefined extensions: 527 o If there is an extension in the compressed message with a type 528 that exists in the predefined extensions object, it is an error, 529 because such an extension would not have been sent by a sender 530 with a compatible compression profile. 532 o For each entry in the predefined extensions dictionary, an 533 extension is added to the decompressed message with the specified 534 type and value. 536 o The resulting vector of extensions MUST be sorted in ascending 537 order by extension type. 539 Note that the "version", "dhGroup", and "signatureAlgorithm" fields 540 in the compression profile are specific instances of this algorithm 541 for the corresponding extensions. 543 [[OPEN ISSUE: Are there other extensions that would benefit from 544 special treatment, as opposed to hex values.]] 546 5.1.3. Known Certificates 548 Certificates are a major contributor to the size of a TLS handshake. 549 In order to avoid this overhead when the parties to a handshake have 550 already exchanged certificates, a compression profile can specify a 551 dictionary of "known certificates" that effectively acts as a 552 compression dictionary on certificates. 554 A known certicates object is a JSON dictionary whose keys are strings 555 containing hex-encoded compressed values. The corresponding values 556 are hex-encoded strings representing the uncompressed values. For 557 example: 559 { 560 "00": "3082...", 561 "01": "3082...", 562 } 564 When compressing a Certificate message, the sender examines the 565 cert_data field of each CertificateEntry. If the cert_data matches a 566 value in the known certificates object, then the sender replaces the 567 cert_data with the corresponding key. Decompression works the 568 opposite way, replacing keys with values. 570 Note that in this scheme, there is no signaling on the wire for 571 whether a given cert_data value is compressed or uncompressed. Known 572 certificates objects SHOULD be constructed in such a way as to avoid 573 a uncompressed object being mistaken for compressed one and 574 erroneously decompressed. For X.509, it is sufficient for the first 575 byte of the compressed value (key) to have a value other than 0x30, 576 since every X.509 certificate starts with this byte. 578 6. Examples 580 The following section provides some example specializations. 582 TLS 1.3 only: 584 { 585 "Version" : 0x0304 586 } 587 TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and 588 everything else is ordinary TLS 1.3. 590 { 591 "Version" : 772, 592 "Random": 16, 593 "CipherSuite" : "TLS_AES_128_GCM_SHA256", 594 "DHGroup": "X25519", 595 "Extensions": { 596 "named_groups": 29, 597 "application_layer_protocol_negotiation" : "030016832", 598 "..." : null 599 } 600 } 602 Version 772 corresponds to the hex representation 0x0304, named group 603 "29" (0x001D) represents X25519. 605 [[OPEN ISSUE: Should we have a registry of well-known profiles?]] 607 7. Security Considerations 609 WARNING: This document is effectively brand new and has seen no 610 analysis. The idea here is that cTLS is isomorphic to TLS 1.3, and 611 therefore should provide equivalent security guarantees. 613 The use of key ids is a new feature introduced in this document, 614 which requires some analysis, especially as it looks like a potential 615 source of identity misbinding. This is, however, entirely separable 616 from the rest of the specification. 618 Transcript expansion also needs some analysis and we need to 619 determine whether we need an extension to indicate that cTLS is in 620 use and with which profile. 622 8. IANA Considerations 624 This document has no IANA actions. 626 9. Normative References 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 634 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 635 May 2017, . 637 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 638 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 639 . 641 Appendix A. Sample Transcripts 643 In this section, we provide annotated example transcripts generated 644 using a draft implementation of this specification in the mint TLS 645 library. The transcripts shown are with the revised message formats 646 defined above, as well as specialization to the indicated cases, 647 using the aggressive compression profiles noted below. The resulting 648 byte counts are as follows: 650 ECDHE PSK 651 ------------------ ------------------ 652 TLS CTLS Overhead TLS CTLS Overhead 653 --- ---- -------- --- ---- -------- 654 ClientHello 132 50 10 147 67 15 655 ServerHello 90 48 8 56 18 2 656 ServerFlight 478 104 16 42 12 3 657 ClientFlight 458 100 11 36 10 1 658 ===================================================== 659 Total 1158 302 45 280 107 21 661 To increase legibility, we show the plaintext bytes of handshake 662 messages that would be encrypted and shorten some of the 663 cryptographic values (shown with "..."). The totals above include 9 664 bytes of encryption overhead for the client and server flights, which 665 would otherwise be encrypted (with a one-byte content type and an 666 8-byte tag). 668 Obviously, these figures are very provisional, and as noted at 669 several points above, there are additional opportunities to reduce 670 overhead. 672 NOTE: We are using a shortened Finished message here. See 673 Section 5.1 for notes on Finished size. However, the overhead is 674 constant for all reasonable Finished sizes.]] 676 A.1. ECDHE and Mutual Certificate-based Authentication 678 Compression Profile: 680 { 681 "version": 772, 682 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 683 "dhGroup": "X25519", 684 "signatureAlgorithm": "ECDSA_P256_SHA256", 685 "randomSize": 8, 686 "finishedSize": 8, 687 "clientHelloExtensions": { 688 "server_name": "000e00000b6578616d706c652e636f6d", 689 }, 690 "certificateRequestExtensions": { 691 "signature_algorithms": "00020403" 692 }, 693 "knownCertificates": { 694 "61": "3082...", 695 "62": "3082..." 696 } 697 } 699 ClientHello: 50 bytes = RANDOM(8) + DH(32) + Overhead(10) 701 01 // ClientHello 702 2ef16120dd84a721 // Random 703 28 // Extensions.length 704 33 26 // KeyShare 705 0024 // client_shares.length 706 001d // KeyShareEntry.group 707 0020 a690...af948 // KeyShareEntry.key_exchange 709 ServerHello: 48 = RANDOM(8) + DH(32) + Overhead(8) 711 02 // ServerHello 712 962547bba5e00973 // Random 713 26 // Extensions.length 714 33 24 // KeyShare 715 001d // KeyShareEntry.group 716 0020 9fbc...0f49 // KeyShareEntry.key_exchange 718 Server Flight: 96 = SIG(71) + MAC(8) + CERTID(1) + Overhead(16) 719 08 // EncryptedExtensions 720 00 // Extensions.length 721 0d // CertificateRequest 722 00 // CertificateRequestContext.length 723 00 // Extensions.length 724 0b // Certificate 725 00 // CertificateRequestContext 726 03 // CertificateList 727 01 // CertData.length 728 61 // CertData = 'a' 729 00 // Extensions.length 730 0f // CertificateVerify 731 0403 // SignatureAlgorithm 732 4047 3045...10ce // Signature 733 14 // Finished 734 bfc9d66715bb2b04 // VerifyData 736 Client Flight: 91 bytes = SIG(71) + MAC(8) + CERTID(1) + Overhead(11) 738 0b // Certificate 739 00 // CertificateRequestContext 740 03 // CertificateList 741 01 // CertData.length 742 62 // CertData = 'b' 743 00 // Extensions.length 744 0f // CertificateVerify 745 0403 // SignatureAlgorithm 746 4047 3045...f60e // Signature.length 747 14 // Finished 748 35e9c34eec2c5dc1 // VerifyData 750 A.2. PSK 752 Compression Profile: 754 { 755 "version": 772, 756 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 757 "signatureAlgorithm": "ECDSA_P256_SHA256", 758 "randomSize": 16, 759 "finishedSize": 0, 760 "clientHelloExtensions": { 761 "server_name": "000e00000b6578616d706c652e636f6d", 762 "psk_key_exchange_modes": "0100" 763 }, 764 "serverHelloExtensions": { 765 "pre_shared_key": "0000" 766 } 767 } 769 ClientHello: 67 bytes = RANDOM(16) + PSKID(4) + BINDER(32) + 770 Overhead(15) 772 01 // ClientHello 773 e230115e62d9a3b58f73e0f2896b2e35 // Random 774 2d // Extensions.length 775 29 2b // PreSharedKey 776 000a // identities.length 777 0004 00010203 // identity 778 7bd05af6 // obfuscated_ticket_age 779 0021 // binders.length 780 20 2428...bb3f // binder 782 ServerHello: 18 bytes = RANDOM(16) + 2 784 02 // ServerHello 785 7232e2d3e61e476b844d9c1f6a4c868f // Random 786 00 // Extensions.length 788 Server Flight: 3 bytes = Overhead(3) 790 08 // EncryptedExtensions 791 00 // Extensions.length 792 14 // Finished 794 Client Flight: 1 byte = Overhead(3) 796 14 // Finished 798 Acknowledgments 800 We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean 801 Turner, Martin Thomson and Chris Wood. 803 Authors' Addresses 805 Eric Rescorla 806 Mozilla 808 Email: ekr@rtfm.com 810 Richard Barnes 811 Cisco 813 Email: rlb@ipv.sx 815 Hannes Tschofenig 816 Arm Limited 818 Email: hannes.tschofenig@arm.com