idnits 2.17.1 draft-ietf-tls-ctls-00.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 (26 April 2020) is 1462 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 252, 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: 28 October 2020 Cisco 6 H. Tschofenig 7 Arm Limited 8 26 April 2020 10 Compact TLS 1.3 11 draft-ietf-tls-ctls-00 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 28 October 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 (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 . . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 5 61 4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 7 65 5. Template-Based Specialization . . . . . . . . . . . . . . . . 7 66 5.1. Specifying a Specialization . . . . . . . . . . . . . . . 8 67 5.1.1. Requirements on the TLS Implementation . . . . . . . 10 68 5.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 10 69 5.1.3. Known Certificates . . . . . . . . . . . . . . . . . 11 70 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Sample Transcripts . . . . . . . . . . . . . . . . . 13 75 A.1. ECDHE and Mutual Certificate-based Authentication . . . . 14 76 A.2. PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 replaces all integers in TLS with varints, including: 157 * Values of uint8, uint16, uint24, uint32, and uint64 159 * Vector length prefixes 161 * Enum / code point values 163 We do not show the structures which only change in this way. 165 This allows implementations' encoding and decoding logic to implement 166 cTLS simply by having a mode in which integers always use the varint 167 encoding. Note that if implementations treat opaque data in the same 168 way as "uint8" values, they MUST NOT convert the bytes of an opaque 169 value to varints. 171 As an example, suppose we are given the following struct: 173 struct { 174 uint32 FieldA; 175 opaque FieldB<0..2^16-1>; 176 } ExampleStruct; 178 Encoding a value of this type with values FieldA=0x0A and 179 FieldB=0x0B0B0B0B0B would result in the following octet strings in 180 "normal" (RFC 8446) and "compact" modes, respectively: 182 Normal: 0000000A00050B0B0B0B0B 183 Compact: 0A050B0B0B0B0B 185 3.2. Record Layer 187 The cTLS Record Layer assumes that records are externally framed 188 (i.e., that the length is already known because it is carried in a 189 UDP datagram or the like). Depending on how this was carried, you 190 might need another byte or two for that framing. Thus, only the type 191 byte need be carried and TLSPlaintext becomes: 193 struct { 194 ContentType type; 195 opaque fragment[TLSPlaintext.length]; 196 } TLSPlaintext; 198 In addition, because the epoch is known in advance, the dummy content 199 type is not needed for the ciphertext, so TLSCiphertext becomes: 201 struct { 202 opaque content[TLSPlaintext.length]; 203 ContentType type; 204 uint8 zeros[length_of_padding]; 205 } TLSInnerPlaintext; 207 struct { 208 opaque encrypted_record[TLSCiphertext.length]; 209 } TLSCiphertext; 211 Note: The user is responsible for ensuring that the sequence numbers/ 212 nonces are handled in the usual fashion. 214 3.3. Handshake Layer 216 The cTLS handshake framing is same as the TLS 1.3 handshake framing, 217 except for two changes: 219 1. The length field is omitted 221 2. The HelloRetryRequest message is a true handshake message instead 222 of a specialization of ServerHello. 224 struct { 225 HandshakeType msg_type; /* handshake type */ 226 select (Handshake.msg_type) { 227 case client_hello: ClientHello; 228 case server_hello: ServerHello; 229 case hello_retry_request: HelloRetryRequest; 230 case end_of_early_data: EndOfEarlyData; 231 case encrypted_extensions: EncryptedExtensions; 232 case certificate_request: CertificateRequest; 233 case certificate: Certificate; 234 case certificate_verify: CertificateVerify; 235 case finished: Finished; 236 case new_session_ticket: NewSessionTicket; 237 case key_update: KeyUpdate; 238 }; 239 } Handshake; 241 4. Handshake Messages 243 In general, we retain the basic structure of each individual TLS 244 handshake message. However, the following handshake messages have 245 been modified for space reduction and cleaned up to remove pre TLS 246 1.3 baggage. 248 4.1. ClientHello 250 The cTLS ClientHello is as follows. 252 opaque Random[RandomLength]; // variable length 254 struct { 255 Random random; 256 CipherSuite cipher_suites<1..V>; 257 Extension extensions<1..V>; 258 } ClientHello; 260 4.2. ServerHello 262 We redefine ServerHello in a similar way: 264 struct { 265 Random random; 266 CipherSuite cipher_suite; 267 Extension extensions<1..V>; 268 } ServerHello; 270 4.3. HelloRetryRequest 272 The HelloRetryRequest has the following format: 274 struct { 275 CipherSuite cipher_suite; 276 Extension extensions<2..V>; 277 } HelloRetryRequest; 279 It is the same as the ServerHello above but without the unnecessary 280 sentinel Random value. 282 5. Template-Based Specialization 284 The protocol in the previous section is fully general and isomorphic 285 to TLS 1.3; effectively it's just a small cleanup of the wire 286 encoding to match what we might have done starting from scratch. It 287 achieves some compaction, but only a modest amount. cTLS also 288 includes a mechanism for achieving very high compaction using 289 template-based specialization. 291 The basic idea is that we start with the basic TLS 1.3 handshake, 292 which is fully general and then remove degrees of freedom, eliding 293 parts of the handshake which are used to express those degrees of 294 freedom. For example, if we only support one version of TLS, then it 295 is not necessary to have version negotiation and the 296 supported_versions extension can be omitted. 298 Importantly, this process is performed only for the wire encoding but 299 not for the handshake transcript. The result is that the transcript 300 for a specialized cTLS handshake is the same as the transcript for a 301 TLS 1.3 handshake with the same features used. 303 One way of thinking of this is as if specialization is a stateful 304 compression layer between the handshake and the record layer: 306 +---------------+---------------+---------------+ 307 | Handshake | Application | Alert | 308 +---------------+---------------+---------------+ +---------+ 309 | cTLS Compression Layer |<---| Profile | 310 +---------------+---------------+---------------+ +---------+ 311 | cTLS Record Layer / Application | 312 +---------------+---------------+---------------+ 313 Specializations are defined by a "compression profile" that specifies 314 what features are to be optimized out of the handshake. In the 315 following subsections, we define the structure of these profiles, and 316 how they are used in compressing and decompressing handshake 317 messages. 319 [[OPEN ISSUE: Do we want to have an explicit cTLS extension 320 indicating that cTLS is in use and which specialization is in use? 321 This goes back to whether we want the use of cTLS to be explicit.]] 323 5.1. Specifying a Specialization 325 A compression profile defining of a specialized version of TLS is 326 defined using a JSON dictionary. Each axis of specialization is a 327 key in the dictionary. [[OPEN ISSUE: If we ever want to serialize 328 this, we'll want to use a list instead.]]. 330 For example, the following specialization describes a protocol with a 331 single fixed version (TLS 1.3) and a single fixed cipher suite 332 (TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites, 333 ServerHello.cipher_suites, and the supported_versions extensions in 334 the ClientHello and ServerHello would be omitted. 336 { 337 "version" : 772, 338 "cipherSuite" : "TLS_AES_128_GCM_SHA256" 339 } 341 cTLS allows specialization along the following axes: 343 version (integer): indicates that both sides agree to the single TLS 344 version specified by the given integer value (772 == 0x0304 for 345 TLS 1.3). The supported_versions extension is omitted from 346 ClientHello.extensions and reconstructed in the transcript as a 347 single-valued list with the specified value. The 348 supported_versions extension is omitted from 349 ClientHello.extensions and reconstructed in the transcript with 350 the specified value. 352 cipherSuite (string): indicates that both sides agree to the single 353 named cipher suite, using the "TLS_AEAD_HASH" syntax defined in 354 [RFC8446], Section 8.4. The ClientHello.cipher_suites field is 355 omitted and reconstructed in the transcript as a single-valued 356 list with the specified value. The server_hello.cipher_suite 357 field is omitted and reconstructed in the transcript as the 358 specified value. 360 dhGroup (string): specifies a single DH group to use for key 361 establishment. The group is listed by the code point name in 362 [RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal 363 "supported_groups" extension consisting solely of this group. 365 signatureAlgorithm (string): specifies a single signature scheme to 366 use for authentication. The group is listed by the code point 367 name in [RFC8446], Section 4.2.7. (e.g., ed25519). This implies a 368 literal "signature_algorithms" extension consisting solely of this 369 group. 371 randomSize (integer): indicates that the ClientHello.Random and 372 ServerHello.Random values are truncated to the given values. When 373 the transcript is reconstructed, the Random is padded to the right 374 with 0s and the anti-downgrade mechanism in {{RFC8446)}, 375 Section 4.1.3 is disabled. IMPORTANT: Using short Random values 376 can lead to potential attacks. When Random values are shorter 377 than 8 bytes, PSK-only modes MUST NOT be used, and each side MUST 378 use fresh DH ephemerals. The Random length MUST be less than or 379 equal to 32 bytes. 381 clientHelloExtensions (predefined extensions): Predefined 382 ClientHello extensions, see {predefined-extensions} 384 serverHelloExtensions (predefined extensions): Predefined 385 ServerHello extensions, see {predefined-extensions} 387 encryptedExtensions (predefined extensions): Predefined 388 EncryptedExtensions extensions, see {predefined-extensions} 390 certRequestExtensions (predefined extensions): Predefined 391 CertificateRequest extensions, see {predefined-extensions} 393 knownCertificates (known certificates): A compression dictionary for 394 the Certificate message, see {known-certs} 396 finishedSize (integer): indicates that the Finished value is to be 397 truncated to the given length. When the transcript is 398 reconstructed, the remainder of the Finished value is filled in by 399 the receiving side. [[OPEN ISSUE: How short should we allow this 400 to be? TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes. 401 More analysis is needed to know the minimum safe Finished size. 402 See [RFC8446]; Section E.1 for more on this, as well as 403 https://mailarchive.ietf.org/arch/msg/tls/ 404 TugB5ddJu3nYg7chcyeIyUqWSbA.]] 406 5.1.1. Requirements on the TLS Implementation 408 To be compatible with the specializations described in this section, 409 a TLS stack needs to provide two key features: 411 If specialization of extensions is to be used, then the TLS stack 412 MUST order each vector of Extension values in ascending order 413 according to the ExtensionType. This allows for a deterministic 414 reconstruction of the extension list. 416 If truncated Random values are to be used, then the TLS stack MUST be 417 configurable to set the remaining bytes of the random values to zero. 418 This ensures that the reconstructed, padded random value matches the 419 original. 421 If truncated Finished values are to be used, then the TLS stack MUST 422 be configurable so that only the provided bytes of the Finished are 423 verified, or so that the expected remaining values can be computed. 425 5.1.2. Predefined Extensions 427 Extensions used in the ClientHello, ServerHello, EncryptedExtensions, 428 and CertificateRequest messages can be "predefined" in a compression 429 profile, so that they do not have to be sent on the wire. A 430 predefined extensions object is a dictionary whose keys are extension 431 names specified in the TLS ExtensionTypeRegistry specified in 432 [RFC8446]. The corresponding value is a hex-encoded value for the 433 ExtensionData field of the extension. 435 When compressing a handshake message, the sender compares the 436 extensions in the message being compressed to the predefined 437 extensions object, applying the following rules: 439 * If the extensions list in the message is not sorted in ascending 440 order by extension type, it is an error, because the decompressed 441 message will not match. 443 * If there is no entry in the predefined extensions object for the 444 type of the extension, then the extension is included in the 445 compressed message 447 * If there is an entry: 449 - If the ExtensionData of the extension does not match the value 450 in the dictionary, it is an error, because decompression will 451 not produce the correct result. 453 - If the ExtensionData matches, then the extension is removed, 454 and not included in the compressed message. 456 When decompressing a handshake message the receiver reconstitutes the 457 original extensions list using the predefined extensions: 459 * If there is an extension in the compressed message with a type 460 that exists in the predefined extensions object, it is an error, 461 because such an extension would not have been sent by a sender 462 with a compatible compression profile. 464 * For each entry in the predefined extensions dictionary, an 465 extension is added to the decompressed message with the specified 466 type and value. 468 * The resulting vector of extensions MUST be sorted in ascending 469 order by extension type. 471 Note that the "version", "dhGroup", and "signatureAlgorithm" fields 472 in the compression profile are specific instances of this algorithm 473 for the corresponding extensions. 475 [[OPEN ISSUE: Are there other extensions that would benefit from 476 special treatment, as opposed to hex values.]] 478 5.1.3. Known Certificates 480 Certificates are a major contributor to the size of a TLS handshake. 481 In order to avoid this overhead when the parties to a handshake have 482 already exchanged certificates, a compression profile can specify a 483 dictionary of "known certificates" that effectively acts as a 484 compression dictionary on certificates. 486 A known certificates object is a JSON dictionary whose keys are 487 strings containing hex-encoded compressed values. The corresponding 488 values are hex-encoded strings representing the uncompressed values. 489 For example: 491 { 492 "00": "3082...", 493 "01": "3082...", 494 } 496 When compressing a Certificate message, the sender examines the 497 cert_data field of each CertificateEntry. If the cert_data matches a 498 value in the known certificates object, then the sender replaces the 499 cert_data with the corresponding key. Decompression works the 500 opposite way, replacing keys with values. 502 Note that in this scheme, there is no signaling on the wire for 503 whether a given cert_data value is compressed or uncompressed. Known 504 certificates objects SHOULD be constructed in such a way as to avoid 505 a uncompressed object being mistaken for compressed one and 506 erroneously decompressed. For X.509, it is sufficient for the first 507 byte of the compressed value (key) to have a value other than 0x30, 508 since every X.509 certificate starts with this byte. 510 6. Examples 512 The following section provides some example specializations. 514 TLS 1.3 only: 516 { 517 "Version" : 0x0304 518 } 520 TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and 521 everything else is ordinary TLS 1.3. 523 { 524 "Version" : 772, 525 "Random": 16, 526 "CipherSuite" : "TLS_AES_128_GCM_SHA256", 527 "DHGroup": "X25519", 528 "Extensions": { 529 "named_groups": 29, 530 "application_layer_protocol_negotiation" : "030016832", 531 "..." : null 532 } 533 } 535 Version 772 corresponds to the hex representation 0x0304, named group 536 "29" (0x001D) represents X25519. 538 [[OPEN ISSUE: Should we have a registry of well-known profiles?]] 540 7. Security Considerations 542 WARNING: This document is effectively brand new and has seen no 543 analysis. The idea here is that cTLS is isomorphic to TLS 1.3, and 544 therefore should provide equivalent security guarantees. 546 The use of key ids is a new feature introduced in this document, 547 which requires some analysis, especially as it looks like a potential 548 source of identity misbinding. This is, however, entirely separable 549 from the rest of the specification. 551 Transcript expansion also needs some analysis and we need to 552 determine whether we need an extension to indicate that cTLS is in 553 use and with which profile. 555 8. IANA Considerations 557 This document has no IANA actions. 559 9. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, 563 DOI 10.17487/RFC2119, March 1997, 564 . 566 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 567 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 568 May 2017, . 570 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 571 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 572 . 574 Appendix A. Sample Transcripts 576 In this section, we provide annotated example transcripts generated 577 using a draft implementation of this specification in the mint TLS 578 library. The transcripts shown are with the revised message formats 579 defined above, as well as specialization to the indicated cases, 580 using the aggressive compression profiles noted below. The resulting 581 byte counts are as follows: 583 ECDHE PSK 584 ------------------ ------------------ 585 TLS CTLS Overhead TLS CTLS Overhead 586 --- ---- -------- --- ---- -------- 587 ClientHello 132 50 10 147 67 15 588 ServerHello 90 48 8 56 18 2 589 ServerFlight 478 104 16 42 12 3 590 ClientFlight 458 100 11 36 10 1 591 ===================================================== 592 Total 1158 302 45 280 107 21 593 To increase legibility, we show the plaintext bytes of handshake 594 messages that would be encrypted and shorten some of the 595 cryptographic values (shown with "..."). The totals above include 9 596 bytes of encryption overhead for the client and server flights, which 597 would otherwise be encrypted (with a one-byte content type and an 598 8-byte tag). 600 Obviously, these figures are very provisional, and as noted at 601 several points above, there are additional opportunities to reduce 602 overhead. 604 [[NOTE: We are using a shortened Finished message here. See 605 Section 5.1 for notes on Finished size. However, the overhead is 606 constant for all reasonable Finished sizes.]] 608 A.1. ECDHE and Mutual Certificate-based Authentication 610 Compression Profile: 612 { 613 "version": 772, 614 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 615 "dhGroup": "X25519", 616 "signatureAlgorithm": "ECDSA_P256_SHA256", 617 "randomSize": 8, 618 "finishedSize": 8, 619 "clientHelloExtensions": { 620 "server_name": "000e00000b6578616d706c652e636f6d", 621 }, 622 "certificateRequestExtensions": { 623 "signature_algorithms": "00020403" 624 }, 625 "knownCertificates": { 626 "61": "3082...", 627 "62": "3082..." 628 } 629 } 631 ClientHello: 50 bytes = RANDOM(8) + DH(32) + Overhead(10) 633 01 // ClientHello 634 2ef16120dd84a721 // Random 635 28 // Extensions.length 636 33 26 // KeyShare 637 0024 // client_shares.length 638 001d // KeyShareEntry.group 639 0020 a690...af948 // KeyShareEntry.key_exchange 641 ServerHello: 48 = RANDOM(8) + DH(32) + Overhead(8) 643 02 // ServerHello 644 962547bba5e00973 // Random 645 26 // Extensions.length 646 33 24 // KeyShare 647 001d // KeyShareEntry.group 648 0020 9fbc...0f49 // KeyShareEntry.key_exchange 650 Server Flight: 96 = SIG(71) + MAC(8) + CERTID(1) + Overhead(16) 652 08 // EncryptedExtensions 653 00 // Extensions.length 654 0d // CertificateRequest 655 00 // CertificateRequestContext.length 656 00 // Extensions.length 657 0b // Certificate 658 00 // CertificateRequestContext 659 03 // CertificateList 660 01 // CertData.length 661 61 // CertData = 'a' 662 00 // Extensions.length 663 0f // CertificateVerify 664 0403 // SignatureAlgorithm 665 4047 3045...10ce // Signature 666 14 // Finished 667 bfc9d66715bb2b04 // VerifyData 669 Client Flight: 91 bytes = SIG(71) + MAC(8) + CERTID(1) + Overhead(11) 671 0b // Certificate 672 00 // CertificateRequestContext 673 03 // CertificateList 674 01 // CertData.length 675 62 // CertData = 'b' 676 00 // Extensions.length 677 0f // CertificateVerify 678 0403 // SignatureAlgorithm 679 4047 3045...f60e // Signature.length 680 14 // Finished 681 35e9c34eec2c5dc1 // VerifyData 683 A.2. PSK 685 Compression Profile: 687 { 688 "version": 772, 689 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 690 "signatureAlgorithm": "ECDSA_P256_SHA256", 691 "randomSize": 16, 692 "finishedSize": 0, 693 "clientHelloExtensions": { 694 "server_name": "000e00000b6578616d706c652e636f6d", 695 "psk_key_exchange_modes": "0100" 696 }, 697 "serverHelloExtensions": { 698 "pre_shared_key": "0000" 699 } 700 } 702 ClientHello: 67 bytes = RANDOM(16) + PSKID(4) + BINDER(32) + 703 Overhead(15) 705 01 // ClientHello 706 e230115e62d9a3b58f73e0f2896b2e35 // Random 707 2d // Extensions.length 708 29 2b // PreSharedKey 709 000a // identities.length 710 0004 00010203 // identity 711 7bd05af6 // obfuscated_ticket_age 712 0021 // binders.length 713 20 2428...bb3f // binder 715 ServerHello: 18 bytes = RANDOM(16) + 2 717 02 // ServerHello 718 7232e2d3e61e476b844d9c1f6a4c868f // Random 719 00 // Extensions.length 721 Server Flight: 3 bytes = Overhead(3) 723 08 // EncryptedExtensions 724 00 // Extensions.length 725 14 // Finished 727 Client Flight: 1 byte = Overhead(3) 729 14 // Finished 731 Acknowledgments 733 We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean 734 Turner, Martin Thomson and Chris Wood. 736 Authors' Addresses 738 Eric Rescorla 739 Mozilla 741 Email: ekr@rtfm.com 743 Richard Barnes 744 Cisco 746 Email: rlb@ipv.sx 748 Hannes Tschofenig 749 Arm Limited 751 Email: hannes.tschofenig@arm.com