idnits 2.17.1 draft-ietf-tls-ctls-01.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 (2 November 2020) is 1263 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 279, 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: 6 May 2021 Cisco 6 H. Tschofenig 7 Arm Limited 8 2 November 2020 10 Compact TLS 1.3 11 draft-ietf-tls-ctls-01 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 6 May 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 57 3. Common Primitives . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 6 61 4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 7 65 5. Template-Based Specialization . . . . . . . . . . . . . . . . 8 66 5.1. Specifying a Specialization . . . . . . . . . . . . . . . 8 67 5.1.1. Requirements on the TLS Implementation . . . . . . . 10 68 5.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 11 69 5.1.3. Known Certificates . . . . . . . . . . . . . . . . . 12 70 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 74 Appendix A. Sample Transcripts . . . . . . . . . . . . . . . . . 15 75 A.1. ECDHE and Mutual Certificate-based Authentication . . . . 15 76 A.2. PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 80 1. Introduction 82 DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet 83 seen significant security analysis, so could contain major errors. 84 It should not be used as a basis for building production systems. 86 This document specifies a "compact" version of TLS 1.3 [RFC8446]. It 87 is isomorphic to TLS 1.3 but designed to take up minimal bandwidth. 88 The space reduction is achieved by four basic techniques: 90 * Omitting unnecessary values that are a holdover from previous 91 versions of TLS. 93 * Omitting the fields and handshake messages required for preserving 94 backwards-compatibility with earlier TLS versions. 96 * More compact encodings, omitting unnecessary values. 98 * A template-based specialization mechanism that allows for the 99 creation of application specific versions of TLS that omit 100 unnecessary values. 102 For the common (EC)DHE handshake with pre-established certificates, 103 cTLS achieves an overhead of 45 bytes over the minimum required by 104 the cryptovariables. For a PSK handshake, the overhead is 21 bytes. 105 Annotated handshake transcripts for these cases can be found in 106 Appendix A. 108 Because cTLS is semantically equivalent to TLS, it can be viewed 109 either as a related protocol or as a compression mechanism. 110 Specifically, it can be implemented by a layer between the TLS 111 handshake state machine and the record layer. 113 2. Conventions and Definitions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 Structure definitions listed below override TLS 1.3 definitions; any 122 PDU not internally defined is taken from TLS 1.3 except for replacing 123 integers with varints. 125 3. Common Primitives 127 3.1. Varints 129 cTLS makes use of variable-length integers in order to allow a wide 130 integer range while still providing for a minimal encoding. The 131 width of the integer is encoded in the first two bits of the field as 132 follows, with xs indicating bits that form part of the integer. 134 +============================+================+ 135 | Bit pattern | Length (bytes) | 136 +============================+================+ 137 | 0xxxxxxx | 1 | 138 +----------------------------+----------------+ 139 +----------------------------+----------------+ 140 | 10xxxxxx xxxxxxxx | 2 | 141 +----------------------------+----------------+ 142 +----------------------------+----------------+ 143 | 11xxxxxx xxxxxxxx xxxxxxxx | 3 | 144 +----------------------------+----------------+ 146 Table 1 148 Thus, one byte can be used to carry values up to 127. 150 In the TLS syntax variable integers are denoted as "varint" and a 151 vector with a top range of a varint is denoted as: 153 opaque foo<1..V>; 155 cTLS uses the varint encoding for all multi-byte integers in TLS, 156 including: 158 * Values of type uint16, uint24, uint32, uint64 160 * Array and vector entries of these types 162 * Encoded lengths for vectors that allow more than 255 entries 164 * Enums that allow more than 255 entries 166 Values of type uint8, opaque values, and one-byte enums are not 167 affected. We do not show the structures which only change in this 168 way. 170 3.2. Record Layer 172 The only cTLS records that are sent in plaintext are handshake 173 records (ClientHello and ServerHello/HRR). The content type is 174 therefore constant (it is always "handshake"), so we instead set the 175 "content_type" field to a fixed cTLS-specific value to distinguish 176 cTLS plaintext records from encrypted records, TLS/DTLS records, and 177 other protocols using the same 5-tuple. 179 The "profile_id" field allows the client and server to agree on which 180 compression profile should be used for this session (see Section 5). 181 This field MUST be set to zero if and only if no compression profile 182 is used. Non-zero values are negotiated out of band between the 183 client and server, as part of the specification of the compression 184 profile. 186 struct { 187 ContentType content_type = ctls_handshake; 188 varint profile_id; 189 opaque fragment<0..V>; 190 } CTLSPlaintext; 192 [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform 193 the server what compression profile to use. For a ServerHello this 194 field is not required. Should we make this field optional?]] 196 Encrypted records use DTLS 1.3 record framing, comprising a 197 configuration octet followed by optional connection ID, sequence 198 number, and length fields. 200 0 1 2 3 4 5 6 7 201 +-+-+-+-+-+-+-+-+ 202 |0|0|1|C|S|L|E E| 203 +-+-+-+-+-+-+-+-+ 204 | Connection ID | Legend: 205 | (if any, | 206 / length as / C - Connection ID (CID) present 207 | negotiated) | S - Sequence number length 208 +-+-+-+-+-+-+-+-+ L - Length present 209 | 8 or 16 bit | E - Epoch 210 |Sequence Number| 211 | (if present) | 212 +-+-+-+-+-+-+-+-+ 213 | 16 bit Length | 214 | (if present) | 215 +-+-+-+-+-+-+-+-+ 217 struct { 218 opaque unified_hdr[variable]; 219 opaque encrypted_record[length]; 220 } CTLSCiphertext; 222 The presence and size of the connection ID field is negotiated as in 223 DTLS. 225 As with DTLS, the length field MAY be omitted by clearing the L bit, 226 which means that the record consumes the entire rest of the data in 227 the lower level transport. In this case it is not possible to have 228 multiple DTLSCiphertext format records without length fields in the 229 same datagram. In stream-oriented transports (e.g., TCP), the length 230 field MUST be present. For use over other transports length 231 information may be inferred from the underlying layer. 233 Normal DTLS does not provide a mechanism for suppressing the sequence 234 number field entirely. In cases where a sequence number is not 235 required (e.g., when a reliable transport is in use), a cTLS 236 implementation may suppress it by setting the 237 "suppressSequenceNumber" flag in the compression profile being used 238 (see Section 5.1). When this flag is enabled, the S bit in the 239 configuration octet MUST be cleared. 241 3.3. Handshake Layer 243 The cTLS handshake framing is same as the TLS 1.3 handshake framing, 244 except for two changes: 246 1. The length field is omitted 248 2. The HelloRetryRequest message is a true handshake message instead 249 of a specialization of ServerHello. 251 struct { 252 HandshakeType msg_type; /* handshake type */ 253 select (Handshake.msg_type) { 254 case client_hello: ClientHello; 255 case server_hello: ServerHello; 256 case hello_retry_request: HelloRetryRequest; 257 case end_of_early_data: EndOfEarlyData; 258 case encrypted_extensions: EncryptedExtensions; 259 case certificate_request: CertificateRequest; 260 case certificate: Certificate; 261 case certificate_verify: CertificateVerify; 262 case finished: Finished; 263 case new_session_ticket: NewSessionTicket; 264 case key_update: KeyUpdate; 265 }; 266 } Handshake; 268 4. Handshake Messages 270 In general, we retain the basic structure of each individual TLS 271 handshake message. However, the following handshake messages have 272 been modified for space reduction and cleaned up to remove pre TLS 273 1.3 baggage. 275 4.1. ClientHello 277 The cTLS ClientHello is as follows. 279 opaque Random[RandomLength]; // variable length 281 struct { 282 Random random; 283 CipherSuite cipher_suites<1..V>; 284 Extension extensions<1..V>; 285 } ClientHello; 287 4.2. ServerHello 289 We redefine ServerHello in a similar way: 291 struct { 292 Random random; 293 CipherSuite cipher_suite; 294 Extension extensions<1..V>; 295 } ServerHello; 297 4.3. HelloRetryRequest 299 The HelloRetryRequest has the following format: 301 struct { 302 CipherSuite cipher_suite; 303 Extension extensions<2..V>; 304 } HelloRetryRequest; 306 It is the same as the ServerHello above but without the unnecessary 307 sentinel Random value. 309 5. Template-Based Specialization 311 The protocol in the previous section is fully general and isomorphic 312 to TLS 1.3; effectively it's just a small cleanup of the wire 313 encoding to match what we might have done starting from scratch. It 314 achieves some compaction, but only a modest amount. cTLS also 315 includes a mechanism for achieving very high compaction using 316 template-based specialization. 318 The basic idea is that we start with the basic TLS 1.3 handshake, 319 which is fully general and then remove degrees of freedom, eliding 320 parts of the handshake which are used to express those degrees of 321 freedom. For example, if we only support one version of TLS, then it 322 is not necessary to have version negotiation and the 323 supported_versions extension can be omitted. 325 Importantly, this process is performed only for the wire encoding but 326 not for the handshake transcript. The result is that the transcript 327 for a specialized cTLS handshake is the same as the transcript for a 328 TLS 1.3 handshake with the same features used. 330 One way of thinking of this is as if specialization is a stateful 331 compression layer between the handshake and the record layer: 333 +---------------+---------------+---------------+ 334 | Handshake | Application | Alert | 335 +---------------+---------------+---------------+ +---------+ 336 | cTLS Compression Layer |<---| Profile | 337 +---------------+---------------+---------------+ +---------+ 338 | cTLS Record Layer / Application | 339 +---------------+---------------+---------------+ 341 Specializations are defined by a "compression profile" that specifies 342 what features are to be optimized out of the handshake. In the 343 following subsections, we define the structure of these profiles, and 344 how they are used in compressing and decompressing handshake 345 messages. 347 5.1. Specifying a Specialization 349 A compression profile defining of a specialized version of TLS is 350 defined using a JSON dictionary. Each axis of specialization is a 351 key in the dictionary. [[OPEN ISSUE: If we ever want to serialize 352 this, we'll want to use a list instead.]]. 354 For example, the following specialization describes a protocol with a 355 single fixed version (TLS 1.3) and a single fixed cipher suite 356 (TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites, 357 ServerHello.cipher_suites, and the supported_versions extensions in 358 the ClientHello and ServerHello would be omitted. 360 { 361 "profileID": 33, 362 "version" : 772, 363 "cipherSuite" : "TLS_AES_128_GCM_SHA256" 364 } 366 cTLS allows specialization along the following axes: 368 profileID (integer): The identifier for this profile, to be sent in 369 the "profile_id" field of CTLSPlaintext records. This value MUST 370 NOT be zero. If this value is not present, the default 371 "profile_id" is 1. 373 suppressSequenceNumber (boolean): If present and set to true, the 374 sequence number field is omitted from encrypted record headers. 376 version (integer): indicates that both sides agree to the single TLS 377 version specified by the given integer value (772 == 0x0304 for 378 TLS 1.3). The supported_versions extension is omitted from 379 ClientHello.extensions and reconstructed in the transcript as a 380 single-valued list with the specified value. The 381 supported_versions extension is omitted from 382 ClientHello.extensions and reconstructed in the transcript with 383 the specified value. 385 cipherSuite (string): indicates that both sides agree to the single 386 named cipher suite, using the "TLS_AEAD_HASH" syntax defined in 387 [RFC8446], Section 8.4. The ClientHello.cipher_suites field is 388 omitted and reconstructed in the transcript as a single-valued 389 list with the specified value. The server_hello.cipher_suite 390 field is omitted and reconstructed in the transcript as the 391 specified value. 393 dhGroup (string): specifies a single DH group to use for key 394 establishment. The group is listed by the code point name in 395 [RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal 396 "supported_groups" extension consisting solely of this group. 398 signatureAlgorithm (string): specifies a single signature scheme to 399 use for authentication. The group is listed by the code point 400 name in [RFC8446], Section 4.2.7. (e.g., ed25519). This implies a 401 literal "signature_algorithms" extension consisting solely of this 402 group. 404 randomSize (integer): indicates that the ClientHello.Random and 405 ServerHello.Random values are truncated to the given values. When 406 the transcript is reconstructed, the Random is padded to the right 407 with 0s and the anti-downgrade mechanism in {{RFC8446)}, 408 Section 4.1.3 is disabled. IMPORTANT: Using short Random values 409 can lead to potential attacks. When Random values are shorter 410 than 8 bytes, PSK-only modes MUST NOT be used, and each side MUST 411 use fresh DH ephemerals. The Random length MUST be less than or 412 equal to 32 bytes. 414 clientHelloExtensions (predefined extensions): Predefined 415 ClientHello extensions, see {predefined-extensions} 417 serverHelloExtensions (predefined extensions): Predefined 418 ServerHello extensions, see {predefined-extensions} 420 encryptedExtensions (predefined extensions): Predefined 421 EncryptedExtensions extensions, see {predefined-extensions} 423 certRequestExtensions (predefined extensions): Predefined 424 CertificateRequest extensions, see {predefined-extensions} 426 knownCertificates (known certificates): A compression dictionary for 427 the Certificate message, see {known-certs} 429 finishedSize (integer): indicates that the Finished value is to be 430 truncated to the given length. When the transcript is 431 reconstructed, the remainder of the Finished value is filled in by 432 the receiving side. [[OPEN ISSUE: How short should we allow this 433 to be? TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes. 434 More analysis is needed to know the minimum safe Finished size. 435 See [RFC8446]; Section E.1 for more on this, as well as 436 https://mailarchive.ietf.org/arch/msg/tls/ 437 TugB5ddJu3nYg7chcyeIyUqWSbA.]] 439 5.1.1. Requirements on the TLS Implementation 441 To be compatible with the specializations described in this section, 442 a TLS stack needs to provide two key features: 444 If specialization of extensions is to be used, then the TLS stack 445 MUST order each vector of Extension values in ascending order 446 according to the ExtensionType. This allows for a deterministic 447 reconstruction of the extension list. 449 If truncated Random values are to be used, then the TLS stack MUST be 450 configurable to set the remaining bytes of the random values to zero. 451 This ensures that the reconstructed, padded random value matches the 452 original. 454 If truncated Finished values are to be used, then the TLS stack MUST 455 be configurable so that only the provided bytes of the Finished are 456 verified, or so that the expected remaining values can be computed. 458 5.1.2. Predefined Extensions 460 Extensions used in the ClientHello, ServerHello, EncryptedExtensions, 461 and CertificateRequest messages can be "predefined" in a compression 462 profile, so that they do not have to be sent on the wire. A 463 predefined extensions object is a dictionary whose keys are extension 464 names specified in the TLS ExtensionTypeRegistry specified in 465 [RFC8446]. The corresponding value is a hex-encoded value for the 466 ExtensionData field of the extension. 468 When compressing a handshake message, the sender compares the 469 extensions in the message being compressed to the predefined 470 extensions object, applying the following rules: 472 * If the extensions list in the message is not sorted in ascending 473 order by extension type, it is an error, because the decompressed 474 message will not match. 476 * If there is no entry in the predefined extensions object for the 477 type of the extension, then the extension is included in the 478 compressed message 480 * If there is an entry: 482 - If the ExtensionData of the extension does not match the value 483 in the dictionary, it is an error, because decompression will 484 not produce the correct result. 486 - If the ExtensionData matches, then the extension is removed, 487 and not included in the compressed message. 489 When decompressing a handshake message the receiver reconstitutes the 490 original extensions list using the predefined extensions: 492 * If there is an extension in the compressed message with a type 493 that exists in the predefined extensions object, it is an error, 494 because such an extension would not have been sent by a sender 495 with a compatible compression profile. 497 * For each entry in the predefined extensions dictionary, an 498 extension is added to the decompressed message with the specified 499 type and value. 501 * The resulting vector of extensions MUST be sorted in ascending 502 order by extension type. 504 Note that the "version", "dhGroup", and "signatureAlgorithm" fields 505 in the compression profile are specific instances of this algorithm 506 for the corresponding extensions. 508 [[OPEN ISSUE: Are there other extensions that would benefit from 509 special treatment, as opposed to hex values.]] 511 5.1.3. Known Certificates 513 Certificates are a major contributor to the size of a TLS handshake. 514 In order to avoid this overhead when the parties to a handshake have 515 already exchanged certificates, a compression profile can specify a 516 dictionary of "known certificates" that effectively acts as a 517 compression dictionary on certificates. 519 A known certificates object is a JSON dictionary whose keys are 520 strings containing hex-encoded compressed values. The corresponding 521 values are hex-encoded strings representing the uncompressed values. 522 For example: 524 { 525 "00": "3082...", 526 "01": "3082...", 527 } 529 When compressing a Certificate message, the sender examines the 530 cert_data field of each CertificateEntry. If the cert_data matches a 531 value in the known certificates object, then the sender replaces the 532 cert_data with the corresponding key. Decompression works the 533 opposite way, replacing keys with values. 535 Note that in this scheme, there is no signaling on the wire for 536 whether a given cert_data value is compressed or uncompressed. Known 537 certificates objects SHOULD be constructed in such a way as to avoid 538 a uncompressed object being mistaken for compressed one and 539 erroneously decompressed. For X.509, it is sufficient for the first 540 byte of the compressed value (key) to have a value other than 0x30, 541 since every X.509 certificate starts with this byte. 543 6. Examples 545 The following section provides some example specializations. 547 TLS 1.3 only: 549 { 550 "version" : 0x0304 551 } 553 TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and 554 everything else is ordinary TLS 1.3. 556 { 557 "version" : 772, 558 "randomSize": 16, 559 "cipherSuite" : "TLS_AES_128_GCM_SHA256", 560 "dhGroup": "X25519", 561 "clientHelloExtensions": { 562 "named_groups": 29, 563 "application_layer_protocol_negotiation" : "030016832", 564 "..." : null 565 } 566 } 568 Version 772 corresponds to the hex representation 0x0304, named group 569 "29" (0x001D) represents X25519. 571 [[OPEN ISSUE: Should we have a registry of well-known profiles?]] 573 7. Security Considerations 575 WARNING: This document is effectively brand new and has seen no 576 analysis. The idea here is that cTLS is isomorphic to TLS 1.3, and 577 therefore should provide equivalent security guarantees. 579 The use of key ids is a new feature introduced in this document, 580 which requires some analysis, especially as it looks like a potential 581 source of identity misbinding. This is, however, entirely separable 582 from the rest of the specification. 584 Transcript expansion also needs some analysis and we need to 585 determine whether we need an extension to indicate that cTLS is in 586 use and with which profile. 588 8. IANA Considerations 590 This document requests that a code point be allocated from the "TLS 591 ContentType registry. This value must be in the range 0-31 592 (inclusive). The row to be added in the registry has the following 593 form: 595 +=======+=============+=========+===========+ 596 | Value | Description | DTLS-OK | Reference | 597 +=======+=============+=========+===========+ 598 | TBD | ctls | N | RFCXXXX | 599 +-------+-------------+---------+-----------+ 601 Table 2 603 [[ RFC EDITOR: Please replace the value TBD with the value assigned 604 by IANA, and the value XXXX to the RFC number assigned for this 605 document. ]] 607 [[OPEN ISSUE: Should we require standards action for all profile IDs 608 that would fit in 2 octets.]] 610 9. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 618 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 619 May 2017, . 621 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 622 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 623 . 625 Appendix A. Sample Transcripts 627 In this section, we provide annotated example transcripts generated 628 using a draft implementation of this specification in the mint TLS 629 library. The transcripts shown are with the revised message formats 630 defined above, as well as specialization to the indicated cases, 631 using the aggressive compression profiles noted below. The resulting 632 byte counts are as follows: 634 ECDHE PSK 635 ------------------ ------------------ 636 TLS CTLS Overhead TLS CTLS Overhead 637 --- ---- -------- --- ---- -------- 638 ClientHello 132 50 10 147 67 15 639 ServerHello 90 48 8 56 18 2 640 ServerFlight 478 104 16 42 12 3 641 ClientFlight 458 100 11 36 10 1 642 ===================================================== 643 Total 1158 302 45 280 107 21 645 To increase legibility, we show the plaintext bytes of handshake 646 messages that would be encrypted and shorten some of the 647 cryptographic values (shown with "..."). The totals above include 9 648 bytes of encryption overhead for the client and server flights, which 649 would otherwise be encrypted (with a one-byte content type and an 650 8-byte tag). 652 Obviously, these figures are very provisional, and as noted at 653 several points above, there are additional opportunities to reduce 654 overhead. 656 [[NOTE: We are using a shortened Finished message here. See 657 Section 5.1 for notes on Finished size. However, the overhead is 658 constant for all reasonable Finished sizes.]] 660 A.1. ECDHE and Mutual Certificate-based Authentication 662 Compression Profile: 664 { 665 "version": 772, 666 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 667 "dhGroup": "X25519", 668 "signatureAlgorithm": "ECDSA_P256_SHA256", 669 "randomSize": 8, 670 "finishedSize": 8, 671 "clientHelloExtensions": { 672 "server_name": "000e00000b6578616d706c652e636f6d", 673 }, 674 "certificateRequestExtensions": { 675 "signature_algorithms": "00020403" 676 }, 677 "knownCertificates": { 678 "61": "3082...", 679 "62": "3082..." 680 } 681 } 683 ClientHello: 50 bytes = RANDOM(8) + DH(32) + Overhead(10) 685 01 // ClientHello 686 2ef16120dd84a721 // Random 687 28 // Extensions.length 688 33 26 // KeyShare 689 0024 // client_shares.length 690 001d // KeyShareEntry.group 691 0020 a690...af948 // KeyShareEntry.key_exchange 693 ServerHello: 48 = RANDOM(8) + DH(32) + Overhead(8) 695 02 // ServerHello 696 962547bba5e00973 // Random 697 26 // Extensions.length 698 33 24 // KeyShare 699 001d // KeyShareEntry.group 700 0020 9fbc...0f49 // KeyShareEntry.key_exchange 702 Server Flight: 96 = SIG(71) + MAC(8) + CERTID(1) + Overhead(16) 703 08 // EncryptedExtensions 704 00 // Extensions.length 705 0d // CertificateRequest 706 00 // CertificateRequestContext.length 707 00 // Extensions.length 708 0b // Certificate 709 00 // CertificateRequestContext 710 03 // CertificateList 711 01 // CertData.length 712 61 // CertData = 'a' 713 00 // Extensions.length 714 0f // CertificateVerify 715 0403 // SignatureAlgorithm 716 4047 // Signature.length 717 3045...f60e // Signature 718 14 // Finished 719 bfc9d66715bb2b04 // VerifyData 721 Client Flight: 91 bytes = SIG(71) + MAC(8) + CERTID(1) + Overhead(11) 723 0b // Certificate 724 00 // CertificateRequestContext 725 03 // CertificateList 726 01 // CertData.length 727 62 // CertData = 'b' 728 00 // Extensions.length 729 0f // CertificateVerify 730 0403 // SignatureAlgorithm 731 4047 // Signature.length 732 3045...f60e // Signature 733 14 // Finished 734 35e9c34eec2c5dc1 // VerifyData 736 A.2. PSK 738 Compression Profile: 740 { 741 "version": 772, 742 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 743 "signatureAlgorithm": "ECDSA_P256_SHA256", 744 "randomSize": 16, 745 "finishedSize": 0, 746 "clientHelloExtensions": { 747 "server_name": "000e00000b6578616d706c652e636f6d", 748 "psk_key_exchange_modes": "0100" 749 }, 750 "serverHelloExtensions": { 751 "pre_shared_key": "0000" 752 } 753 } 755 ClientHello: 67 bytes = RANDOM(16) + PSKID(4) + BINDER(32) + 756 Overhead(15) 758 01 // ClientHello 759 e230115e62d9a3b58f73e0f2896b2e35 // Random 760 2d // Extensions.length 761 29 2b // PreSharedKey 762 000a // identities.length 763 0004 00010203 // identity 764 7bd05af6 // obfuscated_ticket_age 765 0021 // binders.length 766 20 2428...bb3f // binder 768 ServerHello: 18 bytes = RANDOM(16) + 2 770 02 // ServerHello 771 7232e2d3e61e476b844d9c1f6a4c868f // Random 772 00 // Extensions.length 774 Server Flight: 3 bytes = Overhead(3) 776 08 // EncryptedExtensions 777 00 // Extensions.length 778 14 // Finished 780 Client Flight: 1 byte = Overhead(3) 782 14 // Finished 784 Acknowledgments 786 We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean 787 Turner, Martin Thomson and Chris Wood. 789 Authors' Addresses 791 Eric Rescorla 792 Mozilla 794 Email: ekr@rtfm.com 796 Richard Barnes 797 Cisco 799 Email: rlb@ipv.sx 801 Hannes Tschofenig 802 Arm Limited 804 Email: hannes.tschofenig@arm.com