idnits 2.17.1 draft-rescorla-tls-ctls-04.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 (March 09, 2020) is 1503 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 253, 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: September 10, 2020 Cisco 6 H. Tschofenig 7 Arm Limited 8 March 09, 2020 10 Compact TLS 1.3 11 draft-rescorla-tls-ctls-04 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 September 10, 2020. 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 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 . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 5 62 4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 7 66 5. Template-Based Specialization . . . . . . . . . . . . . . . . 7 67 5.1. Specifying a Specialization . . . . . . . . . . . . . . . 8 68 5.1.1. Requirements on the TLS Implementation . . . . . . . 9 69 5.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 10 70 5.1.3. Known Certificates . . . . . . . . . . . . . . . . . 11 71 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 75 Appendix A. Sample Transcripts . . . . . . . . . . . . . . . . . 13 76 A.1. ECDHE and Mutual Certificate-based Authentication . . . . 14 77 A.2. PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet 84 seen significant security analysis, so could contain major errors. 85 It should not be used as a basis for building production systems. 87 This document specifies a "compact" version of TLS 1.3 [RFC8446]. It 88 is isomorphic to TLS 1.3 but designed to take up minimal bandwidth. 89 The space reduction is achieved by four basic techniques: 91 o Omitting unnecessary values that are a holdover from previous 92 versions of TLS. 94 o Omitting the fields and handshake messages required for preserving 95 backwards-compatibility with earlier TLS versions. 97 o More compact encodings, omitting unnecessary values. 99 o A template-based specialization mechanism that allows for the 100 creation of application specific versions of TLS that omit 101 unnecessary values. 103 For the common (EC)DHE handshake with pre-established certificates, 104 cTLS achieves an overhead of 45 bytes over the minimum required by 105 the cryptovariables. For a PSK handshake, the overhead is 21 bytes. 106 Annotated handshake transcripts for these cases can be found in 107 Appendix A. 109 Because cTLS is semantically equivalent to TLS, it can be viewed 110 either as a related protocol or as a compression mechanism. 111 Specifically, it can be implemented by a layer between the TLS 112 handshake state machine and the record layer. 114 2. Conventions and Definitions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 Structure definitions listed below override TLS 1.3 definitions; any 123 PDU not internally defined is taken from TLS 1.3 except for replacing 124 integers with varints. 126 3. Common Primitives 128 3.1. Varints 130 cTLS makes use of variable-length integers in order to allow a wide 131 integer range while still providing for a minimal encoding. The 132 width of the integer is encoded in the first two bits of the field as 133 follows, with xs indicating bits that form part of the integer. 135 +----------------------------+----------------+ 136 | Bit pattern | Length (bytes) | 137 +----------------------------+----------------+ 138 | 0xxxxxxx | 1 | 139 | | | 140 | | | 141 | | | 142 | 10xxxxxx xxxxxxxx | 2 | 143 | | | 144 | | | 145 | | | 146 | 11xxxxxx xxxxxxxx xxxxxxxx | 3 | 147 +----------------------------+----------------+ 149 Thus, one byte can be used to carry values up to 127. 151 In the TLS syntax variable integers are denoted as "varint" and a 152 vector with a top range of a varint is denoted as: 154 opaque foo<1..V>; 156 cTLS replaces all integers in TLS with varints, including: 158 o Values of uint8, uint16, uint24, uint32, and uint64 160 o Vector length prefixes 162 o Enum / code point values 164 We do not show the structures which only change in this way. 166 This allows implementations' encoding and decoding logic to implement 167 cTLS simply by having a mode in which integers always use the varint 168 encoding. Note that if implementations treat opaque data in the same 169 way as "uint8" values, they MUST NOT convert the bytes of an opaque 170 value to varints. 172 As an example, suppose we are given the following struct: 174 struct { 175 uint32 FieldA; 176 opaque FieldB<0..2^16-1>; 177 } ExampleStruct; 179 Encoding a value of this type with values FieldA=0x0A and 180 FieldB=0x0B0B0B0B0B would result in the following octet strings in 181 "normal" (RFC 8446) and "compact" modes, respectively: 183 Normal: 0000000A00050B0B0B0B0B 184 Compact: 0A050B0B0B0B0B 186 3.2. Record Layer 188 The cTLS Record Layer assumes that records are externally framed 189 (i.e., that the length is already known because it is carried in a 190 UDP datagram or the like). Depending on how this was carried, you 191 might need another byte or two for that framing. Thus, only the type 192 byte need be carried and TLSPlaintext becomes: 194 struct { 195 ContentType type; 196 opaque fragment[TLSPlaintext.length]; 197 } TLSPlaintext; 199 In addition, because the epoch is known in advance, the dummy content 200 type is not needed for the ciphertext, so TLSCiphertext becomes: 202 struct { 203 opaque content[TLSPlaintext.length]; 204 ContentType type; 205 uint8 zeros[length_of_padding]; 206 } TLSInnerPlaintext; 208 struct { 209 opaque encrypted_record[TLSCiphertext.length]; 210 } TLSCiphertext; 212 Note: The user is responsible for ensuring that the sequence numbers/ 213 nonces are handled in the usual fashion. 215 3.3. Handshake Layer 217 The cTLS handshake framing is same as the TLS 1.3 handshake framing, 218 except for two changes: 220 1. The length field is omitted 222 2. The HelloRetryRequest message is a true handshake message instead 223 of a specialization of ServerHello. 225 struct { 226 HandshakeType msg_type; /* handshake type */ 227 select (Handshake.msg_type) { 228 case client_hello: ClientHello; 229 case server_hello: ServerHello; 230 case hello_retry_request: HelloRetryRequest; 231 case end_of_early_data: EndOfEarlyData; 232 case encrypted_extensions: EncryptedExtensions; 233 case certificate_request: CertificateRequest; 234 case certificate: Certificate; 235 case certificate_verify: CertificateVerify; 236 case finished: Finished; 237 case new_session_ticket: NewSessionTicket; 238 case key_update: KeyUpdate; 239 }; 240 } Handshake; 242 4. Handshake Messages 244 In general, we retain the basic structure of each individual TLS 245 handshake message. However, the following handshake messages have 246 been modified for space reduction and cleaned up to remove pre TLS 247 1.3 baggage. 249 4.1. ClientHello 251 The cTLS ClientHello is as follows. 253 opaque Random[RandomLength]; // variable length 255 struct { 256 Random random; 257 CipherSuite cipher_suites<1..V>; 258 Extension extensions<1..V>; 259 } ClientHello; 261 4.2. ServerHello 263 We redefine ServerHello in a similar way: 265 struct { 266 Random random; 267 CipherSuite cipher_suite; 268 Extension extensions<1..V>; 269 } ServerHello; 271 4.3. HelloRetryRequest 273 The HelloRetryRequest has the following format: 275 struct { 276 CipherSuite cipher_suite; 277 Extension extensions<2..V>; 278 } HelloRetryRequest; 280 It is the same as the ServerHello above but without the unnecessary 281 sentinel Random value. 283 5. Template-Based Specialization 285 The protocol in the previous section is fully general and isomorphic 286 to TLS 1.3; effectively it's just a small cleanup of the wire 287 encoding to match what we might have done starting from scratch. It 288 achieves some compaction, but only a modest amount. cTLS also 289 includes a mechanism for achieving very high compaction using 290 template-based specialization. 292 The basic idea is that we start with the basic TLS 1.3 handshake, 293 which is fully general and then remove degrees of freedom, eliding 294 parts of the handshake which are used to express those degrees of 295 freedom. For example, if we only support one version of TLS, then it 296 is not necessary to have version negotiation and the 297 supported_versions extension can be omitted. 299 Importantly, this process is performed only for the wire encoding but 300 not for the handshake transcript. The result is that the transcript 301 for a specialized cTLS handshake is the same as the transcript for a 302 TLS 1.3 handshake with the same features used. 304 One way of thinking of this is as if specialization is a stateful 305 compression layer between the handshake and the record layer: 307 +---------------+---------------+---------------+ 308 | Handshake | Application | Alert | 309 +---------------+---------------+---------------+ +---------+ 310 | cTLS Compression Layer |<---| Profile | 311 +---------------+---------------+---------------+ +---------+ 312 | cTLS Record Layer / Application | 313 +---------------+---------------+---------------+ 315 Specializations are defined by a "compression profile" that specifies 316 what features are to be optimized out of the handshake. In the 317 following subsections, we define the structure of these profiles, and 318 how they are used in compressing and decompressing handshake 319 messages. 321 [[OPEN ISSUE: Do we want to have an explicit cTLS extension 322 indicating that cTLS is in use and which specialization is in use? 323 This goes back to whether we want the use of cTLS to be explicit.]] 325 5.1. Specifying a Specialization 327 A compression profile defining of a specialized version of TLS is 328 defined using a JSON dictionary. Each axis of specialization is a 329 key in the dictionary. [[OPEN ISSUE: If we ever want to serialize 330 this, we'll want to use a list instead.]]. 332 For example, the following specialization describes a protocol with a 333 single fixed version (TLS 1.3) and a single fixed cipher suite 334 (TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites, 335 ServerHello.cipher_suites, and the supported_versions extensions in 336 the ClientHello and ServerHello would be omitted. 338 { 339 "version" : 772, 340 "cipherSuite" : "TLS_AES_128_GCM_SHA256" 341 } 343 cTLS allows specialization along the following axes: 345 version (integer): indicates that both sides agree to the single TLS 346 version specified by the given integer value (772 == 0x0304 for 347 TLS 1.3). The supported_versions extension is omitted from 348 ClientHello.extensions and reconstructed in the transcript as a 349 single-valued list with the specified value. The 350 supported_versions extension is omitted from 351 ClientHello.extensions and reconstructed in the transcript with 352 the specified value. 354 cipherSuite (string): indicates that both sides agree to the single 355 named cipher suite, using the "TLS_AEAD_HASH" syntax defined in 356 [RFC8446], Section 8.4. The ClientHello.cipher_suites field is 357 omitted and reconstructed in the transcript as a single-valued 358 list with the specified value. The server_hello.cipher_suite 359 field is omitted and reconstructed in the transcript as the 360 specified value. 362 dhGroup (string): specifies a single DH group to use for key 363 establishment. The group is listed by the code point name in 364 [RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal 365 "supported_groups" extension consisting solely of this group. 367 signatureAlgorithm (string): specifies a single signature scheme to 368 use for authentication. The group is listed by the code point 369 name in [RFC8446], Section 4.2.7. (e.g., ed25519). This implies a 370 literal "signature_algorithms" extension consisting solely of this 371 group. 373 randomSize (integer): indicates that the ClientHello.Random and 374 ServerHello.Random values are truncated to the given values. When 375 the transcript is reconstructed, the Random is padded to the right 376 with 0s and the anti-downgrade mechanism in {{RFC8446)}, 377 Section 4.1.3 is disabled. IMPORTANT: Using short Random values 378 can lead to potential attacks. When Random values are shorter 379 than 8 bytes, PSK-only modes MUST NOT be used, and each side MUST 380 use fresh DH ephemerals. The Random length MUST be less than or 381 equal to 32 bytes. 383 clientHelloExtensions (predefined extensions): Predefined 384 ClientHello extensions, see {predefined-extensions} 386 serverHelloExtensions (predefined extensions): Predefined 387 ServerHello extensions, see {predefined-extensions} 389 encryptedExtensions (predefined extensions): Predefined 390 EncryptedExtensions extensions, see {predefined-extensions} 392 certRequestExtensions (predefined extensions): Predefined 393 CertificateRequest extensions, see {predefined-extensions} 395 knownCertificates (known certificates): A compression dictionary for 396 the Certificate message, see {known-certs} 398 finishedSize (integer): indicates that the Finished value is to be 399 truncated to the given length. When the transcript is 400 reconstructed, the remainder of the Finished value is filled in by 401 the receiving side. [[OPEN ISSUE: How short should we allow this 402 to be? TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes. 403 More analysis is needed to know the minimum safe Finished size. 404 See [RFC8446]; Section E.1 for more on this, as well as 405 https://mailarchive.ietf.org/arch/msg/tls/ 406 TugB5ddJu3nYg7chcyeIyUqWSbA.]] 408 5.1.1. Requirements on the TLS Implementation 410 To be compatible with the specializations described in this section, 411 a TLS stack needs to provide two key features: 413 If specialization of extensions is to be used, then the TLS stack 414 MUST order each vector of Extension values in ascending order 415 according to the ExtensionType. This allows for a deterministic 416 reconstruction of the extension list. 418 If truncated Random values are to be used, then the TLS stack MUST be 419 configurable to set the remaining bytes of the random values to zero. 420 This ensures that the reconstructed, padded random value matches the 421 original. 423 If truncated Finished values are to be used, then the TLS stack MUST 424 be configurable so that only the provided bytes of the Finished are 425 verified, or so that the expected remaining values can be computed. 427 5.1.2. Predefined Extensions 429 Extensions used in the ClientHello, ServerHello, EncryptedExtensions, 430 and CertificateRequest messages can be "predefined" in a compression 431 profile, so that they do not have to be sent on the wire. A 432 predefined extensions object is a dictionary whose keys are extension 433 names specified in the TLS ExtensionTypeRegistry specified in 434 [RFC8446]. The corresponding value is a hex-encoded value for the 435 ExtensionData field of the extension. 437 When compressing a handshake message, the sender compares the 438 extensions in the message being compressed to the predefined 439 extensions object, applying the following rules: 441 o If the extensions list in the message is not sorted in ascending 442 order by extension type, it is an error, because the decompressed 443 message will not match. 445 o If there is no entry in the predefined extensions object for the 446 type of the extension, then the extension is included in the 447 compressed message 449 o If there is an entry: 451 * If the ExtensionData of the extension does not match the value 452 in the dictionary, it is an error, because decompression will 453 not produce the correct result. 455 * If the ExtensionData matches, then the extension is removed, 456 and not included in the compressed message. 458 When decompressing a handshake message the receiver reconstitutes the 459 original extensions list using the predefined extensions: 461 o If there is an extension in the compressed message with a type 462 that exists in the predefined extensions object, it is an error, 463 because such an extension would not have been sent by a sender 464 with a compatible compression profile. 466 o For each entry in the predefined extensions dictionary, an 467 extension is added to the decompressed message with the specified 468 type and value. 470 o The resulting vector of extensions MUST be sorted in ascending 471 order by extension type. 473 Note that the "version", "dhGroup", and "signatureAlgorithm" fields 474 in the compression profile are specific instances of this algorithm 475 for the corresponding extensions. 477 [[OPEN ISSUE: Are there other extensions that would benefit from 478 special treatment, as opposed to hex values.]] 480 5.1.3. Known Certificates 482 Certificates are a major contributor to the size of a TLS handshake. 483 In order to avoid this overhead when the parties to a handshake have 484 already exchanged certificates, a compression profile can specify a 485 dictionary of "known certificates" that effectively acts as a 486 compression dictionary on certificates. 488 A known certificates object is a JSON dictionary whose keys are 489 strings containing hex-encoded compressed values. The corresponding 490 values are hex-encoded strings representing the uncompressed values. 491 For example: 493 { 494 "00": "3082...", 495 "01": "3082...", 496 } 498 When compressing a Certificate message, the sender examines the 499 cert_data field of each CertificateEntry. If the cert_data matches a 500 value in the known certificates object, then the sender replaces the 501 cert_data with the corresponding key. Decompression works the 502 opposite way, replacing keys with values. 504 Note that in this scheme, there is no signaling on the wire for 505 whether a given cert_data value is compressed or uncompressed. Known 506 certificates objects SHOULD be constructed in such a way as to avoid 507 a uncompressed object being mistaken for compressed one and 508 erroneously decompressed. For X.509, it is sufficient for the first 509 byte of the compressed value (key) to have a value other than 0x30, 510 since every X.509 certificate starts with this byte. 512 6. Examples 514 The following section provides some example specializations. 516 TLS 1.3 only: 518 { 519 "Version" : 0x0304 520 } 522 TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and 523 everything else is ordinary TLS 1.3. 525 { 526 "Version" : 772, 527 "Random": 16, 528 "CipherSuite" : "TLS_AES_128_GCM_SHA256", 529 "DHGroup": "X25519", 530 "Extensions": { 531 "named_groups": 29, 532 "application_layer_protocol_negotiation" : "030016832", 533 "..." : null 534 } 535 } 537 Version 772 corresponds to the hex representation 0x0304, named group 538 "29" (0x001D) represents X25519. 540 [[OPEN ISSUE: Should we have a registry of well-known profiles?]] 542 7. Security Considerations 544 WARNING: This document is effectively brand new and has seen no 545 analysis. The idea here is that cTLS is isomorphic to TLS 1.3, and 546 therefore should provide equivalent security guarantees. 548 The use of key ids is a new feature introduced in this document, 549 which requires some analysis, especially as it looks like a potential 550 source of identity misbinding. This is, however, entirely separable 551 from the rest of the specification. 553 Transcript expansion also needs some analysis and we need to 554 determine whether we need an extension to indicate that cTLS is in 555 use and with which profile. 557 8. IANA Considerations 559 This document has no IANA actions. 561 9. Normative References 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, 565 DOI 10.17487/RFC2119, March 1997, 566 . 568 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 569 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 570 May 2017, . 572 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 573 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 574 . 576 Appendix A. Sample Transcripts 578 In this section, we provide annotated example transcripts generated 579 using a draft implementation of this specification in the mint TLS 580 library. The transcripts shown are with the revised message formats 581 defined above, as well as specialization to the indicated cases, 582 using the aggressive compression profiles noted below. The resulting 583 byte counts are as follows: 585 ECDHE PSK 586 ------------------ ------------------ 587 TLS CTLS Overhead TLS CTLS Overhead 588 --- ---- -------- --- ---- -------- 589 ClientHello 132 50 10 147 67 15 590 ServerHello 90 48 8 56 18 2 591 ServerFlight 478 104 16 42 12 3 592 ClientFlight 458 100 11 36 10 1 593 ===================================================== 594 Total 1158 302 45 280 107 21 596 To increase legibility, we show the plaintext bytes of handshake 597 messages that would be encrypted and shorten some of the 598 cryptographic values (shown with "..."). The totals above include 9 599 bytes of encryption overhead for the client and server flights, which 600 would otherwise be encrypted (with a one-byte content type and an 601 8-byte tag). 603 Obviously, these figures are very provisional, and as noted at 604 several points above, there are additional opportunities to reduce 605 overhead. 607 [[NOTE: We are using a shortened Finished message here. See 608 Section 5.1 for notes on Finished size. However, the overhead is 609 constant for all reasonable Finished sizes.]] 611 A.1. ECDHE and Mutual Certificate-based Authentication 613 Compression Profile: 615 { 616 "version": 772, 617 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 618 "dhGroup": "X25519", 619 "signatureAlgorithm": "ECDSA_P256_SHA256", 620 "randomSize": 8, 621 "finishedSize": 8, 622 "clientHelloExtensions": { 623 "server_name": "000e00000b6578616d706c652e636f6d", 624 }, 625 "certificateRequestExtensions": { 626 "signature_algorithms": "00020403" 627 }, 628 "knownCertificates": { 629 "61": "3082...", 630 "62": "3082..." 631 } 632 } 634 ClientHello: 50 bytes = RANDOM(8) + DH(32) + Overhead(10) 636 01 // ClientHello 637 2ef16120dd84a721 // Random 638 28 // Extensions.length 639 33 26 // KeyShare 640 0024 // client_shares.length 641 001d // KeyShareEntry.group 642 0020 a690...af948 // KeyShareEntry.key_exchange 644 ServerHello: 48 = RANDOM(8) + DH(32) + Overhead(8) 645 02 // ServerHello 646 962547bba5e00973 // Random 647 26 // Extensions.length 648 33 24 // KeyShare 649 001d // KeyShareEntry.group 650 0020 9fbc...0f49 // KeyShareEntry.key_exchange 652 Server Flight: 96 = SIG(71) + MAC(8) + CERTID(1) + Overhead(16) 654 08 // EncryptedExtensions 655 00 // Extensions.length 656 0d // CertificateRequest 657 00 // CertificateRequestContext.length 658 00 // Extensions.length 659 0b // Certificate 660 00 // CertificateRequestContext 661 03 // CertificateList 662 01 // CertData.length 663 61 // CertData = 'a' 664 00 // Extensions.length 665 0f // CertificateVerify 666 0403 // SignatureAlgorithm 667 4047 3045...10ce // Signature 668 14 // Finished 669 bfc9d66715bb2b04 // VerifyData 671 Client Flight: 91 bytes = SIG(71) + MAC(8) + CERTID(1) + Overhead(11) 673 0b // Certificate 674 00 // CertificateRequestContext 675 03 // CertificateList 676 01 // CertData.length 677 62 // CertData = 'b' 678 00 // Extensions.length 679 0f // CertificateVerify 680 0403 // SignatureAlgorithm 681 4047 3045...f60e // Signature.length 682 14 // Finished 683 35e9c34eec2c5dc1 // VerifyData 685 A.2. PSK 687 Compression Profile: 689 { 690 "version": 772, 691 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 692 "signatureAlgorithm": "ECDSA_P256_SHA256", 693 "randomSize": 16, 694 "finishedSize": 0, 695 "clientHelloExtensions": { 696 "server_name": "000e00000b6578616d706c652e636f6d", 697 "psk_key_exchange_modes": "0100" 698 }, 699 "serverHelloExtensions": { 700 "pre_shared_key": "0000" 701 } 702 } 704 ClientHello: 67 bytes = RANDOM(16) + PSKID(4) + BINDER(32) + 705 Overhead(15) 707 01 // ClientHello 708 e230115e62d9a3b58f73e0f2896b2e35 // Random 709 2d // Extensions.length 710 29 2b // PreSharedKey 711 000a // identities.length 712 0004 00010203 // identity 713 7bd05af6 // obfuscated_ticket_age 714 0021 // binders.length 715 20 2428...bb3f // binder 717 ServerHello: 18 bytes = RANDOM(16) + 2 719 02 // ServerHello 720 7232e2d3e61e476b844d9c1f6a4c868f // Random 721 00 // Extensions.length 723 Server Flight: 3 bytes = Overhead(3) 725 08 // EncryptedExtensions 726 00 // Extensions.length 727 14 // Finished 729 Client Flight: 1 byte = Overhead(3) 731 14 // Finished 733 Acknowledgments 735 We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean 736 Turner, Martin Thomson and Chris Wood. 738 Authors' Addresses 740 Eric Rescorla 741 Mozilla 743 Email: ekr@rtfm.com 745 Richard Barnes 746 Cisco 748 Email: rlb@ipv.sx 750 Hannes Tschofenig 751 Arm Limited 753 Email: hannes.tschofenig@arm.com