idnits 2.17.00 (12 Aug 2021) /tmp/idnits55518/draft-ietf-tls-ctls-05.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 document date (7 March 2022) is 68 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RandomLength' is mentioned on line 496, but not defined -- No information found for draft-ietf-tls-dtls - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-ietf-tls-dtls' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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: Standards Track R. Barnes 5 Expires: 8 September 2022 Cisco 6 H. Tschofenig 7 Arm Limited 8 7 March 2022 10 Compact TLS 1.3 11 draft-ietf-tls-ctls-05 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, a template-based specialization technique, and 18 alternative cryptographic techniques. cTLS is not directly 19 interoperable with TLS 1.3, but it should eventually be possible for 20 a cTLS/TLS 1.3 server to exist and successfully 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 8 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 57 2.1. Template-based Specialization . . . . . . . . . . . . . . 3 58 2.1.1. Requirements on TLS Implementations . . . . . . . . . 7 59 2.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 7 60 2.1.3. Known Certificates . . . . . . . . . . . . . . . . . 8 61 2.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 9 62 2.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 10 63 3. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 11 64 3.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 12 67 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 6.1. Adding a ContentType . . . . . . . . . . . . . . . . . . 13 71 6.2. Template Keys . . . . . . . . . . . . . . . . . . . . . . 13 72 7. Normative References . . . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 15 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet 80 seen significant security analysis, so could contain major errors. 81 It should not be used as a basis for building production systems. 83 This document specifies a "compact" version of TLS 1.3 [RFC8446]. It 84 is isomorphic to TLS 1.3 but designed to take up minimal bandwidth. 85 The space reduction is achieved by five basic techniques: 87 * Omitting unnecessary values that are a holdover from previous 88 versions of TLS. 90 * Omitting the fields and handshake messages required for preserving 91 backwards-compatibility with earlier TLS versions. 93 * More compact encodings, for example point compression. 95 * A template-based specialization mechanism that allows pre- 96 populating information at both endpoints without the need for 97 negotiation. 99 * Alternative cryptographic techniques, such as semi-static Diffie- 100 Hellman. 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. 124 2.1. Template-based Specialization 126 A significant transmission overhead in TLS 1.3 is contributed to by 127 two factors, : - the negotiation of algorithm parameters, and 128 extensions, as well as - the exchange of certificates. 130 TLS 1.3 supports different credential types and modes that are 131 impacted differently by a compression scheme. For example, TLS 132 supports certificate-based authentication, raw public key-based 133 authentication as well as pre-shared key (PSK)-based authentication. 134 PSK-based authentication can be used with externally configured PSKs 135 or with PSKs established through tickets. 137 The basic idea of template-based specialization is that we start with 138 the basic TLS 1.3 handshake, which is fully general and then remove 139 degrees of freedom, eliding parts of the handshake which are used to 140 express those degrees of freedom. For example, if we only support 141 one version of TLS, then it is not necessary to have version 142 negotiation and the supported_versions extension can be omitted. 144 Importantly, this process is performed only for the wire encoding but 145 not for the handshake transcript. The result is that the transcript 146 for a specialized cTLS handshake is the same as the transcript for a 147 TLS 1.3 handshake with the same features used. 149 One way of thinking of this is as if specialization is a stateful 150 compression layer between the handshake and the record layer: 152 +---------------+---------------+---------------+ 153 | Handshake | Application | Alert | 154 +---------------+---------------+---------------+ +---------+ 155 | cTLS Compression Layer |<---| Profile | 156 +---------------+---------------+---------------+ +---------+ 157 | cTLS Record Layer / Application | 158 +---------------+---------------+---------------+ 160 By assuming that out-of-band agreements took place already prior to 161 the start of the cTLS protocol exchange, the amount of data exchanged 162 can be radically reduced. Because different clients may use 163 different compression templates and because multiple compression 164 templates may be available for use in different deployment 165 environments, a client needs to inform the server about the profile 166 it is planning to use. The profile field in the ClientHello serves 167 this purpose. 169 Although the template-based specialization mechanisms described here 170 are general, we also include specific mechanism for certificate-based 171 exchanges because those are where the most complexity and size 172 reduction can be obtained. Most of the other exchanges in TLS 1.3 173 are highly optimized and do not require compression to be used. 175 The compression profile defining the use of algorithms, algorithm 176 parameters, and extensions is specified via a JSON dictionary. 178 For example, the following specialization describes a protocol with a 179 single fixed version (TLS 1.3) and a single fixed cipher suite 180 (TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites, 181 ServerHello.cipher_suites, and the supported_versions extensions in 182 the ClientHello and ServerHello would be omitted. 184 { 185 "version" : 772, 186 "cipherSuite" : "TLS_AES_128_GCM_SHA256" 187 } 189 The following elements are defined: 191 profile (integer): identifies the profile being defined. 193 version (integer): indicates that both sides agree to the single TLS 194 version specified by the given integer value (772 == 0x0304 for 195 TLS 1.3). The supported_versions extension is omitted from 196 ClientHello.extensions and reconstructed in the transcript as a 197 single-valued list with the specified value. The 198 supported_versions extension is omitted from 199 ClientHello.extensions and reconstructed in the transcript with 200 the specified value. 202 cipherSuite (string): indicates that both sides agree to the single 203 named cipher suite, using the "TLS_AEAD_HASH" syntax defined in 204 [RFC8446], Section 8.4. The ClientHello.cipher_suites field is 205 omitted and reconstructed in the transcript as a single-valued 206 list with the specified value. The server_hello.cipher_suite 207 field is omitted and reconstructed in the transcript as the 208 specified value. 210 dhGroup (string): specifies a single DH group to use for key 211 establishment. The group is listed by the code point name in 212 [RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal 213 "supported_groups" extension consisting solely of this group. 215 signatureAlgorithm (string): specifies a single signature scheme to 216 use for authentication. The signature algorithm is listed by the 217 code point name in [RFC8446], Section 4.2.3. (e.g., 218 ecdsa_secp256r1_sha256). This implies a literal 219 "signature_algorithms" extension consisting solely of this group. 221 random (integer): indicates that the ClientHello.Random and 222 ServerHello.Random values are truncated to the given length. When 223 the transcript is reconstructed, the Random is padded to the right 224 with 0s and the anti-downgrade mechanism in [RFC8446], 225 Section 4.1.3 is disabled. IMPORTANT: Using short Random values 226 can lead to potential attacks. The Random length MUST be less 227 than or equal to 32 bytes. 229 [[Open Issue: Karthik Bhargavan suggested the idea of hashing 230 ephemeral public keys and to use the result (truncated to 32 bytes) 231 as random values. Such a change would require a security analysis. 232 ]] 234 mutualAuth (boolean): if set to true, indicates that the client must 235 authenticate with a certificate by sending Certificate and a 236 CertificateVerify message. The server MUST omit the 237 CertificateRequest message, as its contents are redundant. [[OPEN 238 ISSUE: We don't actually say that you can omit empty messages, so 239 we need to add that somewhere.]] 241 extension_order: indicates in what order extensions appear in 242 respective messages. This allows to omit sending the type. If 243 there is only a single extension to be transmitted, then the 244 extension length field can also be omitted. For example, imagine 245 that only the KeyShare extension needs to be sent in the 246 ClientHello as the only extension. Then, the following structure 248 28 // Extensions.length 249 33 26 // KeyShare 250 0024 // client_shares.length 251 001d // KeyShareEntry.group 252 0020 a690...af948 // KeyShareEntry.key_exchange 254 is compressed down to (assuming the KeyShare group has been pre- 255 agreed) 257 0020 a690...af948 // KeyShareEntry.key_exchange 259 clientHelloExtensions (predefined extensions): Predefined 260 ClientHello extensions, see {predefined-extensions} 262 serverHelloExtensions (predefined extensions): Predefined 263 ServerHello extensions, see {predefined-extensions} 265 encryptedExtensions (predefined extensions): Predefined 266 EncryptedExtensions extensions, see {predefined-extensions} 268 certRequestExtensions (predefined extensions): Predefined 269 CertificateRequest extensions, see {predefined-extensions} 271 knownCertificates (known certificates): A compression dictionary for 272 the Certificate message, see {known-certs} 274 finishedSize (integer): indicates that the Finished value is to be 275 truncated to the given length. When the transcript is 276 reconstructed, the remainder of the Finished value is filled in by 277 the receiving side. 279 [[OPEN ISSUE: How short should we allow this to be? TLS 1.3 uses the 280 native hash and TLS 1.2 used 12 bytes. More analysis is needed to 281 know the minimum safe Finished size. See [RFC8446]; Section E.1 for 282 more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ 283 TugB5ddJu3nYg7chcyeIyUqWSbA.]] 285 optional (object): contains keys that are not required to be 286 understood by the client. Server operators MUST NOT place a key 287 in this section unless the server is able to determine whether the 288 key is in use based on the client data it receives. A key MUST 289 NOT appear in both the main template and the optional section. 291 2.1.1. Requirements on TLS Implementations 293 To be compatible with the specializations described in this section, 294 a TLS stack needs to provide the following features: 296 * If specialization of extensions is to be used, then the TLS stack 297 MUST order each vector of Extension values in ascending order 298 according to the ExtensionType. This allows for a deterministic 299 reconstruction of the extension list. 301 * If truncated Random values are to be used, then the TLS stack MUST 302 be configurable to set the remaining bytes of the random values to 303 zero. This ensures that the reconstructed, padded random value 304 matches the original. 306 * If truncated Finished values are to be used, then the TLS stack 307 MUST be configurable so that only the provided bytes of the 308 Finished are verified, or so that the expected remaining values 309 can be computed. 311 2.1.2. Predefined Extensions 313 Extensions used in the ClientHello, ServerHello, EncryptedExtensions, 314 and CertificateRequest messages can be "predefined" in a compression 315 profile, so that they do not have to be sent on the wire. A 316 predefined extensions object is a dictionary whose keys are extension 317 names specified in the TLS ExtensionTypeRegistry specified in 318 [RFC8446]. The corresponding value is a hex-encoded value for the 319 ExtensionData field of the extension. 321 When compressing a handshake message, the sender compares the 322 extensions in the message being compressed to the predefined 323 extensions object, applying the following rules: 325 * If the extensions list in the message is not sorted in ascending 326 order by extension type, it is an error, because the decompressed 327 message will not match. 329 * If there is no entry in the predefined extensions object for the 330 type of the extension, then the extension is included in the 331 compressed message 333 * If there is an entry: 335 - If the ExtensionData of the extension does not match the value 336 in the dictionary, it is an error, because decompression will 337 not produce the correct result. 339 - If the ExtensionData matches, then the extension is removed, 340 and not included in the compressed message. 342 When decompressing a handshake message the receiver reconstitutes the 343 original extensions list using the predefined extensions: 345 * If there is an extension in the compressed message with a type 346 that exists in the predefined extensions object, it is an error, 347 because such an extension would not have been sent by a sender 348 with a compatible compression profile. 350 * For each entry in the predefined extensions dictionary, an 351 extension is added to the decompressed message with the specified 352 type and value. 354 * The resulting vector of extensions MUST be sorted in ascending 355 order by extension type. 357 Note that the "version", "dhGroup", and "signatureAlgorithm" fields 358 in the compression profile are specific instances of this algorithm 359 for the corresponding extensions. 361 [[OPEN ISSUE: Are there other extensions that would benefit from 362 special treatment, as opposed to hex values.]] 364 2.1.3. Known Certificates 366 Certificates are a major contributor to the size of a TLS handshake. 367 In order to avoid this overhead when the parties to a handshake have 368 already exchanged certificates, a compression profile can specify a 369 dictionary of "known certificates" that effectively acts as a 370 compression dictionary on certificates. 372 A known certificates object is a JSON dictionary whose keys are 373 strings containing hex-encoded compressed values. The corresponding 374 values are hex-encoded strings representing the uncompressed values. 375 For example: 377 { 378 "00": "3082...", 379 "01": "3082...", 380 } 381 When compressing a Certificate message, the sender examines the 382 cert_data field of each CertificateEntry. If the cert_data matches a 383 value in the known certificates object, then the sender replaces the 384 cert_data with the corresponding key. Decompression works the 385 opposite way, replacing keys with values. 387 Note that in this scheme, there is no signaling on the wire for 388 whether a given cert_data value is compressed or uncompressed. Known 389 certificates objects SHOULD be constructed in such a way as to avoid 390 a uncompressed object being mistaken for compressed one and 391 erroneously decompressed. For X.509, it is sufficient for the first 392 byte of the compressed value (key) to have a value other than 0x30, 393 since every X.509 certificate starts with this byte. 395 2.2. Record Layer 397 The only cTLS records that are sent in plaintext are handshake 398 records (ClientHello and ServerHello/HRR) and alerts. cTLS alerts are 399 the same as TLS alerts and use the same content types. For handshake 400 records, we set the content_type field to a fixed cTLS-specific value 401 to distinguish cTLS plaintext records from encrypted records, TLS/ 402 DTLS records, and other protocols using the same 5-tuple. 404 struct { 405 ContentType content_type = ctls_handshake; 406 opaque fragment<0..2^16-1>; 407 } CTLSPlaintext; 409 [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform 410 the server what compression profile to use. For a ServerHello this 411 field is not required. Should we make this field optional?]] 413 Encrypted records use DTLS [I-D.draft-ietf-tls-dtls] 1.3 record 414 framing, comprising a configuration octet followed by optional 415 connection ID, sequence number, and length fields. The encryption 416 process and additional data are also as described in DTLS. 418 0 1 2 3 4 5 6 7 419 +-+-+-+-+-+-+-+-+ 420 |0|0|1|C|S|L|E E| 421 +-+-+-+-+-+-+-+-+ 422 | Connection ID | Legend: 423 | (if any, | 424 / length as / C - Connection ID (CID) present 425 | negotiated) | S - Sequence number length 426 +-+-+-+-+-+-+-+-+ L - Length present 427 | 8 or 16 bit | E - Epoch 428 |Sequence Number| 429 | (if present) | 430 +-+-+-+-+-+-+-+-+ 431 | 16 bit Length | 432 | (if present) | 433 +-+-+-+-+-+-+-+-+ 435 struct { 436 opaque unified_hdr[variable]; 437 opaque encrypted_record[length]; 438 } CTLSCiphertext; 440 The presence and size of the connection ID field is negotiated as in 441 DTLS. 443 As with DTLS, the length field MAY be omitted by clearing the L bit, 444 which means that the record consumes the entire rest of the data in 445 the lower level transport. In this case it is not possible to have 446 multiple DTLSCiphertext format records without length fields in the 447 same datagram. In stream-oriented transports (e.g., TCP), the length 448 field MUST be present. For use over other transports length 449 information may be inferred from the underlying layer. 451 Normal DTLS does not provide a mechanism for suppressing the sequence 452 number field entirely. When a reliable, ordered transport (e.g., 453 TCP) is in use, the S bit in the configuration octet MUST be cleared 454 and the sequence number MUST be omitted. When an unreliable 455 transport is in use, the S bit has its usual meaning and the sequence 456 number MUST be included. 458 2.3. Handshake Layer 460 The cTLS handshake framing is same as the TLS 1.3 handshake framing, 461 except for two changes: 463 * The length field is omitted. 465 * The HelloRetryRequest message is a true handshake message instead 466 of a specialization of ServerHello. 468 struct { 469 HandshakeType msg_type; /* handshake type */ 470 select (Handshake.msg_type) { 471 case client_hello: ClientHello; 472 case server_hello: ServerHello; 473 case hello_retry_request: HelloRetryRequest; 474 case end_of_early_data: EndOfEarlyData; 475 case encrypted_extensions: EncryptedExtensions; 476 case certificate_request: CertificateRequest; 477 case certificate: Certificate; 478 case certificate_verify: CertificateVerify; 479 case finished: Finished; 480 case new_session_ticket: NewSessionTicket; 481 case key_update: KeyUpdate; 482 }; 483 } Handshake; 485 3. Handshake Messages 487 In general, we retain the basic structure of each individual TLS 488 handshake message. However, the following handshake messages have 489 been modified for space reduction and cleaned up to remove pre-TLS 490 1.3 baggage. 492 3.1. ClientHello 494 The cTLS ClientHello is defined as follows. 496 opaque Random[RandomLength]; // variable length 498 struct { 499 opaque profile_id<0..2^8-1>; 500 Random random; 501 CipherSuite cipher_suites<1..2^16-1>; 502 Extension extensions<1..2^16-1>; 503 } ClientHello; 505 The client uses the profile_id field to inform the server about the 506 compression profile being used (see Section 2.1). This field MUST be 507 set to a zero-length value and only if no compression profile is 508 used. Non zero-length values are agreed out of band between the 509 client and server, as part of the specification of the compression 510 profile. 512 3.2. ServerHello 514 We redefine ServerHello in the following way. 516 struct { 517 Random random; 518 CipherSuite cipher_suite; 519 Extension extensions<1..2^16-1>; 520 } ServerHello; 522 3.3. HelloRetryRequest 524 The HelloRetryRequest has the following format. 526 struct { 527 CipherSuite cipher_suite; 528 Extension extensions<2..2^16-1>; 529 } HelloRetryRequest; 531 The HelloRetryRequest is the same as the ServerHello above but 532 without the unnecessary sentinel Random value. 534 4. Examples 536 This section provides some example specializations. 538 For this example we use TLS 1.3 only with AES_GCM, X25519, ALPN h2, 539 short random values, and everything else is ordinary TLS 1.3. 541 { 542 "profile" : 1, 543 "version" : 772, 544 "random": 16, 545 "cipherSuite" : "TLS_AES_128_GCM_SHA256", 546 "dhGroup": "X25519", 547 "clientHelloExtensions": { 548 "named_groups": 29, 549 "application_layer_protocol_negotiation" : "030016832", 550 "..." : null 551 } 552 } 554 Version 772 corresponds to the hex representation 0x0304, named group 555 "29" (0x001D) represents X25519. 557 [[OPEN ISSUE: Should we have a registry of well-known profiles?]] 559 5. Security Considerations 561 WARNING: This document is effectively brand new and has seen no 562 analysis. The idea here is that cTLS is isomorphic to TLS 1.3, and 563 therefore should provide equivalent security guarantees. 565 The use of key ids is a new feature introduced in this document, 566 which requires some analysis, especially as it looks like a potential 567 source of identity misbinding. This is, however, entirely separable 568 from the rest of the specification. 570 Transcript expansion also needs some analysis and we need to 571 determine whether we need an extension to indicate that cTLS is in 572 use and with which profile. 574 6. IANA Considerations 576 6.1. Adding a ContentType 578 This document requests that a code point be allocated from the "TLS 579 ContentType registry. This value must be in the range 0-31 580 (inclusive). The row to be added in the registry has the following 581 form: 583 +=======+================+=========+===========+ 584 | Value | Description | DTLS-OK | Reference | 585 +=======+================+=========+===========+ 586 | TBD | ctls | Y | RFCXXXX | 587 +-------+----------------+---------+-----------+ 588 | TBD | ctls_handshake | Y | RFCXXXX | 589 +-------+----------------+---------+-----------+ 591 Table 1 593 [[ RFC EDITOR: Please replace the value TBD with the value assigned 594 by IANA, and the value XXXX to the RFC number assigned for this 595 document. ]] 597 [[OPEN ISSUE: Should we require standards action for all profile IDs 598 that would fit in 2 octets.]] 600 6.2. Template Keys 602 This document requests that IANA open a new registry entitled "cTLS 603 Template Keys", on the Transport Layer Security (TLS) Parameters 604 page, with a "Specification Required" registration policy and the 605 following initial contents: 607 +=======================+============+=================+ 608 | Key | JSON Type | Reference | 609 +=======================+============+=================+ 610 | profile | number | (This document) | 611 +-----------------------+------------+-----------------+ 612 | version | number | (This document) | 613 +-----------------------+------------+-----------------+ 614 | cipherSuite | string | (This document) | 615 +-----------------------+------------+-----------------+ 616 | dhGroup | string | (This document) | 617 +-----------------------+------------+-----------------+ 618 | signatureAlgorithm | string | (This document) | 619 +-----------------------+------------+-----------------+ 620 | random | number | (This document) | 621 +-----------------------+------------+-----------------+ 622 | mutualAuth | true/false | (This document) | 623 +-----------------------+------------+-----------------+ 624 | extension_order | object | (This document) | 625 +-----------------------+------------+-----------------+ 626 | clientHelloExtensions | object | (This document) | 627 +-----------------------+------------+-----------------+ 628 | serverHelloExtensions | object | (This document) | 629 +-----------------------+------------+-----------------+ 630 | encryptedExtensions | object | (This document) | 631 +-----------------------+------------+-----------------+ 632 | certRequestExtensions | object | (This document) | 633 +-----------------------+------------+-----------------+ 634 | knownCertificates | object | (This document) | 635 +-----------------------+------------+-----------------+ 636 | finishedSize | number | (This document) | 637 +-----------------------+------------+-----------------+ 638 | optional | object | (This document) | 639 +-----------------------+------------+-----------------+ 641 Table 2 643 7. Normative References 645 [I-D.draft-ietf-tls-dtls] 646 "*** BROKEN REFERENCE ***". 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, 650 DOI 10.17487/RFC2119, March 1997, 651 . 653 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 654 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 655 May 2017, . 657 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 658 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 659 . 661 Appendix A. Example Exchange 663 The follow exchange illustrates a complete cTLS-based exchange 664 supporting mutual authentication using certificates. The digital 665 signatures use ECDSA with SHA256 and NIST P256r1. The ephemeral 666 Diffie-Hellman uses the FX25519 curve and the exchange negotiates 667 TLS-AES-128-CCM8-SHA256. The certificates are exchanged using 668 certificate identifiers. 670 The resulting byte counts are as follows: 672 ECDHE 673 ------------------ 674 TLS CTLS Overhead 675 --- ---- -------- 676 ClientHello 132 36 4 677 ServerHello 90 36 4 678 ServerFlight 478 80 7 679 ClientFlight 458 80 7 680 ================================== 681 Total 1158 232 22 683 The following compression profile was used in this example: 685 { 686 "profile": 1, 687 "version": 772, 688 "cipherSuite": "TLS_AES_128_CCM_8_SHA256", 689 "dhGroup": "X25519", 690 "signatureAlgorithm": "ecdsa_secp256r1_sha256", 691 "finishedSize": 8, 692 "clientHelloExtensions": { 693 "server_name": "000e00000b6578616d706c652e636f6d", 694 }, 695 "certificateRequestExtensions": { 696 "certificate_request_context": 0, 697 "signature_algorithms": "00020403" 698 }, 699 "mutualAuth": true, 700 "extension-order": { 701 "clientHelloExtensions": [ 702 "key_share" 703 ], 704 "ServerHelloExtensions": [ 705 "key_share" 706 ], 707 }, 709 "knownCertificates": { 710 "61": "3082...", 711 "62": "3082...", 712 "63": "...", 713 "64": "...", 714 ... 715 } 716 } 718 ClientHello: 36 bytes = DH(32) + Overhead(4) 720 01 // ClientHello 721 01 // Profile ID 722 0020 a690...af948 // KeyShareEntry.key_exchange 724 ServerHello: 36 = DH(32) + Overhead(4) 726 02 // ServerHello 727 26 // Extensions.length 728 0020 9fbc...0f49 // KeyShareEntry.key_exchange 730 Server Flight: 80 = SIG(64) + MAC(8) + CERTID(1) + Overhead(7) 731 The EncryptedExtensions, and the CertificateRequest messages are 732 omitted because they are empty. 734 0b // Certificate 735 03 // CertificateList 736 01 // CertData.length 737 61 // CertData = 'a' 739 0f // CertificateVerify 740 4064 // Signature.length 741 3045...10ce // Signature 743 14 // Finished 744 bfc9d66715bb2b04 // VerifyData 746 Client Flight: 80 bytes = SIG(64) + MAC(8) + CERTID(1) + Overhead(7) 748 0b // Certificate 749 03 // CertificateList 750 01 // CertData.length 751 62 // CertData = 'b' 753 0f // CertificateVerify 754 4064 // Signature.length 755 3045...f60e // Signature 757 14 // Finished 758 35e9c34eec2c5dc1 // VerifyData 760 Acknowledgments 762 We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean 763 Turner, Benjamin Schwartz, Martin Thomson, and Chris Wood. 765 Authors' Addresses 767 Eric Rescorla 768 Mozilla 769 Email: ekr@rtfm.com 771 Richard Barnes 772 Cisco 773 Email: rlb@ipv.sx 774 Hannes Tschofenig 775 Arm Limited 776 Email: hannes.tschofenig@arm.com