idnits 2.17.1 draft-rescorla-tls-ctls-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 08, 2019) is 1754 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: 'TODO' is mentioned on line 101, but not defined -- Looks like a reference, but probably isn't: '16' on line 236 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: January 9, 2020 Cisco 6 July 08, 2019 8 Compact TLS 1.3 9 draft-rescorla-tls-ctls-02 11 Abstract 13 This document specifies a "compact" version of TLS 1.3. It is 14 isomorphic to TLS 1.3 but saves space by aggressive use of defaults 15 and tighter encodings. CTLS is not interoperable with TLS 1.3, but 16 it should eventually be possible for the server to distinguish TLS 17 1.3 and CTLS handshakes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 55 3. Common Primitives . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 4 59 3.4. Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1.1. KeyShare . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2.1. KeyShare . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2.2. PreSharedKeys . . . . . . . . . . . . . . . . . . . . 8 66 4.3. EncryptedExtensions . . . . . . . . . . . . . . . . . . . 8 67 4.4. CertificateRequest . . . . . . . . . . . . . . . . . . . 8 68 4.5. Certificate . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.5.1. Key IDs . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.5.2. CertificateVerify . . . . . . . . . . . . . . . . . . 9 71 4.5.3. Finished . . . . . . . . . . . . . . . . . . . . . . 9 72 4.5.4. HelloRetryRequest . . . . . . . . . . . . . . . . . . 10 73 5. Handshake Size Calculations . . . . . . . . . . . . . . . . . 10 74 5.1. ECDHE w/ Signatures . . . . . . . . . . . . . . . . . . . 10 75 5.1.1. Flight 1 (ClientHello) *** . . . . . . . . . . . . . 10 76 5.1.2. Flight 2 (ServerHello..Finished) . . . . . . . . . . 10 77 5.1.3. Flight 3 (Client Certificate..Finished) . . . . . . . 11 78 6. cTLS as Compression Layer [[OPEN ISSUE]] . . . . . . . . . . 12 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 82 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet 88 seen significant security analysis, so could contain major errors. 89 It should not be used as a basis for building production systems. 91 This document specifies a "compact" version of TLS 1.3 [RFC8446]. It 92 is isomorphic to TLS 1.3 but designed to take up minimal bandwidth. 93 The space reduction is achieved by two basic techniques: 95 o Default values for common configurations, thus avoiding the need 96 to take up space on the wire. 98 o More compact encodings, omitting unnecessary values. 100 For the common (EC)DHE handshake with (EC)DHE and pre-established 101 public keys, CTLS achieves an overhead of [TODO] bytes over the 102 minimum required by the cryptovariables. 104 Because cTLS is semantically equivalent to TLS, it can be viewed 105 either as a related protocol or as a compression mechanism. 106 Specifically, it can be implemented by a layer between the TLS 107 handshake state machine and the record layer. See Section 6 for more 108 details. 110 2. Conventions and Definitions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 Structure definitions listed below override TLS 1.3 definitions; any 119 PDU not internally defined is taken from TLS 1.3. 121 3. Common Primitives 123 3.1. Varints 125 CTLS makes use of variable-length integers in order to allow a wide 126 integer range while still providing for a minimal encoding. The 127 width of the integer is encoded in the first two bits of the field as 128 follows, with xs indicating bits that form part of the integer. 130 +----------------------------+----------------+ 131 | Bit pattern | Length (bytes) | 132 +----------------------------+----------------+ 133 | 0xxxxxxx | 1 | 134 | | | 135 | | | 136 | | | 137 | 10xxxxxx xxxxxxxx | 2 | 138 | | | 139 | | | 140 | | | 141 | 11xxxxxx xxxxxxxx xxxxxxxx | 3 | 142 +----------------------------+----------------+ 144 Thus, one byte can be used to carry values up to 127. 146 In the TLS syntax variable integers are denoted as "varint" and a 147 vector with a top range of a varint is denoted as: 149 opaque foo<1..V>; 151 [[OPEN ISSUE: Should we just re-encode this directly in CBOR?. That 152 might be easier for people, but I ran out of time.]] 154 3.2. Record Layer 156 The CTLS Record Layer assumes that records are externally framed 157 (i.e., that the length is already known because it is carried in a 158 UDP datagram or the like). Depending on how this was carried, you 159 might need another byte or two for that framing. Thus, only the type 160 byte need be carried. Thus, TLSPlaintext becomes: 162 struct { 163 ContentType type; 164 opaque fragment[TLSPlaintext.length]; 165 } TLSPlaintext; 167 In addition, because the epoch is known in advance, the dummy content 168 type is not needed for the ciphertext, so TLSCiphertext becomes: 170 struct { 171 opaque content[TLSPlaintext.length]; 172 ContentType type; 173 uint8 zeros[length_of_padding]; 174 } TLSInnerPlaintext; 176 struct { 177 opaque encrypted_record[TLSCiphertext.length]; 178 } TLSCiphertext; 180 Note: The user is responsible for ensuring that the sequence numbers/ 181 nonces are handled in the usual fashion. 183 Overhead: 1 byte per record. 185 3.3. Handshake Layer 187 The CTLS handshake layer is the same as the TLS 1.3 handshake layer 188 except that the length is a varint. 190 struct { 191 HandshakeType msg_type; /* handshake type */ 192 varint length; // CHANGED 193 select (Handshake.msg_type) { 194 case client_hello: ClientHello; 195 case server_hello: ServerHello; 196 case end_of_early_data: EndOfEarlyData; 197 case encrypted_extensions: EncryptedExtensions; 198 case certificate_request: CertificateRequest; 199 case certificate: Certificate; 200 case certificate_verify: CertificateVerify; 201 case finished: Finished; 202 case new_session_ticket: NewSessionTicket; 203 case key_update: KeyUpdate; 204 }; 205 } Handshake; 207 Overhead: 2 bytes per handshake message (min). 209 [OPEN ISSUE: This can be shrunk to 1 byte in some cases if we are 210 willing to use a custom encoding. There are 11 handshake types, so 211 we can use the first 4 bits for the type and then the bottom 4 bits 212 for an encoding of the length, but we would have to offset that by 16 213 or so to be able to have a meaningful impact.]] 215 3.4. Extensions 217 CTLS Extensions are the same as TLS 1.3 extensions, except varint 218 length coded: 220 struct { 221 ExtensionType extension_type; 222 opaque extension_data<0..V>; 223 } Extension; 225 4. Handshake Messages 227 In general, we retain the basic structure of each individual TLS 228 handshake message. However, the following handshake messages are 229 slightly modified for space reduction. 231 4.1. ClientHello 233 The CTLS ClientHello is as follows. 235 uint8 ProtocolVersion; // 1 byte 236 opaque Random[16]; // shortened 237 uint8 CipherSuite; // 1 byte 239 struct { 240 ProtocolVersion versions<0..255>; 241 Random random; 242 CipherSuite cipher_suites<1..V>; 243 Extension extensions[remainder_of_message]; 244 } ClientHello; 246 [[TODO: Define single-byte mappings of the cipher suites and protocol 247 version.]] 249 The versions list from "supported_versions" has moved into 250 ClientHello.versions with versions being one byte, but with the 251 modern semantics of the client offering N versions and the server 252 picking one. 254 In order to conserve space, the following extensions have default 255 values which apply if they are not present: 257 o SignatureAlgorithms: ed25519 259 o SupportedGroups: the list of groups present in the KeyShare 260 extension. 262 o Pre-Shared Key Exchange Modes: psk_dhe_ke 264 o Certificate Type: A new TBD value indicating a key index. 266 As a practical matter, the only extension needed is the KeyShare 267 extension, as defined below. 269 Overhead: 8 bytes (min) 271 o Versions: 1 + # Versions 273 o CipherSuites: 1 + # Suites 275 o Key shares: 2 + 2 * # shares 277 4.1.1. KeyShare 279 The KeyShare extension is redefined as: 281 uint8 NamedGroup; 282 struct { 283 NamedGroup group; 284 opaque key_exchange<1..V>; 285 } KeyShareEntry; 287 struct { 288 KeyShareEntry client_shares[length of extension]; 289 } KeyShareClientHello; 291 [[TODO: Need a mapping for 8-bit group ids]] 293 4.2. ServerHello 295 We redefine ServerHello in a similar way: 297 struct { 298 ProtocolVersion version; 299 Random random; 300 CipherSuite cipher_suite; 301 Extension extensions[remainder_of_message]; 302 } ServerHello; 304 The extensions have the same default values as in ClientHello, so as 305 a practical matter only KeyShare is needed. 307 Overhead: 6 bytes 309 o Version: 1 311 o Cipher Suite: 1 313 o KeyShare: 4 bytes 315 4.2.1. KeyShare 317 struct { 318 KeyShareEntry server_share; 319 } KeyShareServerHello; 321 [[OPEN ISSUE: We could save one byte here by removing the length of 322 the key share and another byte by only allowing the client to send 323 one key share (so group wasn't needed)..]] 325 [[TODO: Need to define a single-byte list of NamedGroups]]. 327 4.2.2. PreSharedKeys 329 [[TODO]] 331 4.3. EncryptedExtensions 333 Unchanged. 335 [[OPEN ISSUE: We could save 2 bytes in handshake header by omitting 336 this value when it's unneeded.]] 338 4.4. CertificateRequest 340 This message removes the certificate_request_context and re-encodes 341 the extensions. 343 struct { 344 Extension extensions[remainder of message]; 345 } CertificateRequest; 347 4.5. Certificate 349 We can slim down the Certficate message somewhat. 351 enum { 352 X509(0), 353 RawPublicKey(2), 354 (255) 355 } CertificateType; 357 struct { 358 select (certificate_type) { 359 case RawPublicKey: 360 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 361 opaque ASN1_subjectPublicKeyInfo<1..V>; 363 case X509: 364 opaque cert_data<1..V>; 365 }; 366 Extension extensions<0..V>; 367 } CertificateEntry; 369 struct { 370 CertificateEntry certificate_list[rest of extension]; 371 } Certificate; 373 For a single certificate, this message will have a minumum of 2 bytes 374 of overhead for the two length bytes. 376 [[OPEN ISSUE: What should the default type be?]] 378 4.5.1. Key IDs 380 WARNING: This is a new feature which has not seen any analysis and so 381 may have real problems. 383 [[OPEN ISSUE: Do we want this at all?]] 385 It may also be possible to slim down the Certificate message further, 386 by adding a KeyID-based mode, in which they keys were just a table 387 index. This would redefines Certificate as: 389 struct { 390 varint key_id; 391 } KeyIdCertificate; 393 struct { 394 select (certiticate_type): 395 case RawPublicKey, x509: 396 CertificateEntry certificate_list<0..2^24-1>; 398 case key_id: 399 KeyIdCertificate; 400 } 401 } Certificate; 403 This allows the use of a short key id. Note that this is orthogonal 404 to the rest of the changes. 406 IMPORTANT: You really want to include the certificate in the 407 handshake transcript somehow, but this isn't specified for how. 409 4.5.2. CertificateVerify 411 Remove the signature algorithm and assume it's tied to the key. Note 412 that this does not work for RSA keys, but if we just decide to be EC 413 only, it works fine. 415 struct { 416 opaque signature[rest of message]; 417 } CertificateVerify; 419 4.5.3. Finished 421 Unchanged. 423 4.5.4. HelloRetryRequest 425 [[TODO]] 427 5. Handshake Size Calculations 429 This section provides the size of cTLS handshakes with various 430 parameters [[TODO: Fill this out with more options.]] 432 5.1. ECDHE w/ Signatures 434 We compute the total flight size with X25519 and P-256 signatures, 435 thus the keys are 32-bytes long and the signatures 64 bytes, with a 436 cipher with an 8 byte auth tag, as in AEAD_AES_128_CCM_8. [Note: GCM 437 should not be used with a shortened tag.] Overhead estimates marked 438 with *** have been verified with Mint. Others are hand calculations 439 and so may prove to be approximate. 441 5.1.1. Flight 1 (ClientHello) *** 443 o Random: 16 445 o KeyShare: 32 447 o Message Overhead: 8 449 o Handshake Overhead: 2 451 o Record Overhead: 1 453 o Total: 59 455 5.1.2. Flight 2 (ServerHello..Finished) 457 ServerHello *** 459 o Random: 16 461 o KeyShare: 32 463 o Message Overhead: 6 465 o Handshake Overhead: 2 467 o Total: 56 469 EncryptedExtensions *** 470 o Handshake Overhead: 2 472 o Total: 2 474 CertificateRequest *** 476 o Handshake Overhead: 2 478 o Total: 2 480 Certificate 482 o Certificate: X 484 o Length bytes: 2 486 o Handshake Overhead: 2 488 o Total: 4 + X 490 CertificateVerify 492 o Signature: 64 494 o Handshake Overhead: 2 496 o Total: 66 498 Finished 500 o MAC: 32 502 o Overhead: 2 504 o Total: 34 506 Record Overhead: 2 bytes (2 records) + 8 bytes (auth tag). 508 [[OPEN ISSUE: We'll actually need a length field for the ServerHello, 509 to separate it from the ciphertext.]] 511 Total Size: 175 + X bytes. 513 5.1.3. Flight 3 (Client Certificate..Finished) 515 Certificate 517 o Certificate: X 518 o Length bytes: 2 520 o Handshake Overhead: 2 522 o Total: 4 + X 524 CertificateVerify 526 o Signature: 64 528 o Handshake Overhead: 2 530 o Total: 66 532 Finished 534 o MAC: 32 536 o Handshake Overhead: 2 538 o Total: 34 540 Record Overhead: 1 byte + 8 bytes (auth tag) 542 Total: 113 + X bytes 544 6. cTLS as Compression Layer [[OPEN ISSUE]] 546 The above text treates cTLS as a new protocol; however it is also 547 possible to view it as a form of compression for TLS, which sits in 548 between the handshake layer and the record layer, like so: 550 +---------------+---------------+---------------+ 551 | Handshake | Application | Alert | 552 +---------------+---------------+---------------+ 553 | cTLS Compression Layer | 554 +---------------+---------------+---------------+ 555 | cTLS Record Layer | 556 +---------------+---------------+---------------+ 558 This structure does involve one technical difference: because the 559 handshake message transformation happens below the handshake layer, 560 the cTLS handshake transcript would be the same as the TLS 1.3 561 handshake transcript. This has both advantages and disadvantages. 563 The major advantage is that it makes it possible to reuse all the TLS 564 security proofs even with very aggressive compression (with suitable 565 proofs about the bijectiveness of the compression). [Thanks to 566 Karthik Bhargavan for this point.] This probably also makes it 567 easier to implement more aggressive compression. For instance, the 568 above text shrinks the handshake headers but does not elide them 569 entirely. If the handshake shape (i.e., which messages are sent) is 570 known in advance, then these headers can be removed, thus trimming 571 about 20 bytes from the handshake. This is easier to reason about as 572 a form of compression. With somewhat aggressive parameters, 573 including predetermined cipher suites, this technique can bring the 574 handshake (without record overhead) to: 576 Client's first flight 48 577 Server's first flight 164 578 Client's second flight 116 580 The major potential disadvantage of a compression approach is that it 581 makes cTLS and TLS handshakes confusable. For instance, an attacker 582 who obtained the handshake keys might be able to undetectably 583 transform a cTLS <-> TLS connection into a TLS <-> TLS connection. 584 This is easily dealt with by modifying the transcript, e.g., by 585 injecting a cTLS extension in the transcript (though not into cTLS 586 wire format). 588 7. Security Considerations 590 WARNING: This document is effectively brand new and has seen no 591 analysis. The idea here is that CTLS is isomorphic to TLS 1.3, and 592 therefore should provide equivalent security guarantees, modulo use 593 of new features such as KeyID certificate messages. 595 One piece that is a new TLS 1.3 feature is the addition of the 596 key_id, which definitely requires some analysis, especially as it 597 looks like a potential source of identity misbinding. This is 598 entirely separable from the rest of the specification. The 599 compression version would also need further analysis. 601 8. IANA Considerations 603 This document has no IANA actions. 605 9. Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, 609 DOI 10.17487/RFC2119, March 1997, 610 . 612 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 613 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 614 May 2017, . 616 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 617 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 618 . 620 Acknowledgments 622 TODO acknowledge. 624 Authors' Addresses 626 Eric Rescorla 627 Mozilla 629 Email: ekr@rtfm.com 631 Richard Barnes 632 Cisco 634 Email: rlb@ipv.sx