idnits 2.17.1 draft-rescorla-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1866 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 542, but not defined -- Looks like a reference, but probably isn't: '16' on line 235 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 March 11, 2019 5 Expires: September 12, 2019 7 Compact TLS 1.3 8 draft-rescorla-tls-ctls-00 10 Abstract 12 This document specifies a "compact" version of TLS 1.3. It is 13 isomorphic to TLS 1.3 but saves space by aggressive use of defaults 14 and tighter encodings. CTLS is not interoperable with TLS 1.3, but 15 it should eventually be possible for the server to distinguish TLS 16 1.3 and CTLS handshakes. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 12, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 54 3. Common Primitives . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 4 57 3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 4 58 3.4. Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1.1. KeyShare . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2.1. KeyShare . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2.2. PreSharedKeys . . . . . . . . . . . . . . . . . . . . 8 65 4.3. EncryptedExtensions . . . . . . . . . . . . . . . . . . . 8 66 4.4. CertificateRequest . . . . . . . . . . . . . . . . . . . 8 67 4.5. Certificate . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.5.1. Key IDs . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.5.2. CertificateVerify . . . . . . . . . . . . . . . . . . 9 70 4.5.3. Finished . . . . . . . . . . . . . . . . . . . . . . 9 71 4.5.4. HelloRetryRequest . . . . . . . . . . . . . . . . . . 10 72 5. Handshake Size Calculations . . . . . . . . . . . . . . . . . 10 73 5.1. ECDHE w/ Signatures . . . . . . . . . . . . . . . . . . . 10 74 5.1.1. Flight 1 (ClientHello) *** . . . . . . . . . . . . . 10 75 5.1.2. Flight 2 (ServerHello..Finished) . . . . . . . . . . 10 76 5.1.3. Flight 3 (Client Certificate..Finished) . . . . . . . 11 77 5.2. ECDHE w/ PSK . . . . . . . . . . . . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Normative References . . . . . . . . . . . . . . . . . . . . 13 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 DDISCLAIMER: This is a work-in-progress draft of MLS and has not yet 87 seen significant security analysis, so could contain major errors. 88 It should not be used as a basis for building production systems. 90 This document specifies a "compact" version of TLS 1.3 [RFC8446]. It 91 is isomorphic to TLS 1.3 but designed to take up minimal bandwidth. 92 The space reduction is achieved by two basic techniques: 94 o Default values for common configurations, thus avoiding the need 95 to take up space on the wire. 97 o More compact encodings, omitting unnecessary values. 99 For the common (EC)DHE handshake with (EC)DHE and pre-established 100 public keys, CTLS achieves an overhead of [TODO] bytes over the 101 minimum required by the cryptovariables. 103 Although isomorphic, CTLS implementations cannot interoperate with 104 TLS 1.3 implementations because the packet formats are non- 105 interoperable. It is probably possible to make a TLS 1.3 server 106 switch-hit between CTLS and TLS 1.3 but this specification does not 107 define how. 109 2. Conventions and Definitions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 Structure definitions listed below override TLS 1.3 definitions; any 118 PDU not internally defined is taken from TLS 1.3. 120 3. Common Primitives 122 3.1. Varints 124 CTLS makes use of variable-length integers in order to allow a wide 125 integer range while still providing for a minimal encoding. The 126 width of the integer is encoded in the first two bits of the field as 127 follows, with xs indicating bits that form part of the integer. 129 +----------------------------+----------------+ 130 | Bit pattern | Length (bytes) | 131 +----------------------------+----------------+ 132 | 0xxxxxxx | 1 | 133 | | | 134 | | | 135 | | | 136 | 10xxxxxx xxxxxxxx | 2 | 137 | | | 138 | | | 139 | | | 140 | 11xxxxxx xxxxxxxx xxxxxxxx | 3 | 141 +----------------------------+----------------+ 143 Thus, one byte can be used to carry values up to 127. 145 In the TLS syntax variable integers are denoted as "varint" and a 146 vector with a top range of a varint is denoted as: 148 opaque foo<1..V>; 150 [[OPEN ISSUE: Should we just re-encode this directly in CBOR?. That 151 might be easier for people, but I ran out of time.]] 153 3.2. Record Layer 155 The CTLS Record Layer assumes that records are externally framed 156 (i.e., that the length is already known because it is carried in a 157 UDP datagram or the like). Depending on how this was carried, you 158 might need another byte or two for that framing. Thus, only the type 159 byte need be carried. Thus, TLSPlaintext becomes: 161 struct { 162 ContentType type; 163 opaque fragment[TLSPlaintext.length]; 164 } TLSPlaintext; 166 In addition, because the epoch is known in advance, the dummy content 167 type is not needed for the ciphertext, so TLSCiphertext becomes: 169 struct { 170 opaque content[TLSPlaintext.length]; 171 ContentType type; 172 uint8 zeros[length_of_padding]; 173 } TLSInnerPlaintext; 175 struct { 176 opaque encrypted_record[TLSCiphertext.length]; 177 } TLSCiphertext; 179 Note: The user is responsible for ensuring that the sequence numbers/ 180 nonces are handled in the usual fashion. 182 Overhead: 1 byte per record. 184 3.3. Handshake Layer 186 The CTLS handshake layer is the same as the TLS 1.3 handshake layer 187 except that the length is a varint. 189 struct { 190 HandshakeType msg_type; /* handshake type */ 191 varint length; // CHANGED 192 select (Handshake.msg_type) { 193 case client_hello: ClientHello; 194 case server_hello: ServerHello; 195 case end_of_early_data: EndOfEarlyData; 196 case encrypted_extensions: EncryptedExtensions; 197 case certificate_request: CertificateRequest; 198 case certificate: Certificate; 199 case certificate_verify: CertificateVerify; 200 case finished: Finished; 201 case new_session_ticket: NewSessionTicket; 202 case key_update: KeyUpdate; 203 }; 204 } Handshake; 206 Overhead: 2 bytes per handshake message (min). 208 [OPEN ISSUE: This can be shrunk to 1 byte in some cases if we are 209 willing to use a custom encoding. There are 11 handshake types, so 210 we can use the first 4 bits for the type and then the bottom 4 bits 211 for an encoding of the length, but we would have to offset that by 16 212 or so to be able to have a meaningful impact.]] 214 3.4. Extensions 216 CTLS Extensions are the same as TLS 1.3 extensions, except varint 217 length coded: 219 struct { 220 ExtensionType extension_type; 221 opaque extension_data<0..V>; 222 } Extension; 224 4. Handshake Messages 226 In general, we retain the basic structure of each individual TLS 227 handshake message. However, the following handshake messages are 228 slightly modified for space reduction. 230 4.1. ClientHello 232 The CTLS ClientHello is as follows. 234 uint8 ProtocolVersion; // 1 byte 235 opaque Random[16]; // shortened 236 uint8 CipherSuite; // 1 byte 238 struct { 239 ProtocolVersion versions<0..255>; 240 Random random; 241 CipherSuite cipher_suites<1..V>; 242 Extension extensions[remainder_of_message]; 243 } ClientHello; 245 [[TODO: Define single-byte mappings of the cipher suites and protocol 246 version.]] 248 The versions list from "supported_versions" has moved into 249 ClientHello.versions with versions being one byte, but with the 250 modern semantics of the client offering N versions and the server 251 picking one. 253 In order to conserve space, the following extensions have default 254 values which apply if they are not present: 256 o SignatureAlgorithms: ed25519 258 o SupportedGroups: the list of groups present in the KeyShare 259 extension. 261 o Pre-Shared Key Exchange Modes: psk_dhe_ke 263 o Certificate Type: A new TBD value indicating a key index. 265 As a practical matter, the only extension needed is the KeyShare 266 extension, as defined below. 268 Overhead: 8 bytes (min) 270 o Versions: 1 + # Versions 272 o CipherSuites: 1 + # Suites 274 o Key shares: 2 + 2 * # shares 276 4.1.1. KeyShare 278 The KeyShare extension is redefined as: 280 uint8 NamedGroup; 281 struct { 282 NamedGroup group; 283 opaque key_exchange<1..V>; 284 } KeyShareEntry; 286 struct { 287 KeyShareEntry client_shares[length of extension]; 288 } KeyShareClientHello; 290 [[TODO: Need a mapping for 8-bit group ids]] 292 4.2. ServerHello 294 We redefine ServerHello in a similar way: 296 struct { 297 ProtocolVersion version; 298 Random random; 299 CipherSuite cipher_suite; 300 Extension extensions[remainder_of_message]; 301 } ServerHello; 303 The extensions have the same default values as in ClientHello, so as 304 a practical matter only KeyShare is needed. 306 Overhead: 6 bytes 308 o Version: 1 310 o Cipher Suite: 1 312 o KeyShare: 4 bytes 314 4.2.1. KeyShare 316 struct { 317 KeyShareEntry server_share; 318 } KeyShareServerHello; 320 [[OPEN ISSUE: We could save one byte here by removing the length of 321 the key share and another byte by only allowing the client to send 322 one key share (so group wasn't needed)..]] 324 [[TODO: Need to define a single-byte list of NamedGroups]]. 326 4.2.2. PreSharedKeys 328 [[TODO]] 330 4.3. EncryptedExtensions 332 Unchanged. 334 [[OPEN ISSUE: We could save 2 bytes in handshake header by omitting 335 this value when it's unneeded.]] 337 4.4. CertificateRequest 339 This message removes the certificate_request_context and re-encodes 340 the extensions. 342 struct { 343 Extension extensions[remainder of message]; 344 } CertificateRequest; 346 4.5. Certificate 348 We can slim down the Certficate message somewhat. 350 enum { 351 X509(0), 352 RawPublicKey(2), 353 (255) 354 } CertificateType; 356 struct { 357 select (certificate_type) { 358 case RawPublicKey: 359 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 360 opaque ASN1_subjectPublicKeyInfo<1..V>; 362 case X509: 363 opaque cert_data<1..V>; 364 }; 365 Extension extensions<0..V>; 366 } CertificateEntry; 368 struct { 369 CertificateEntry certificate_list[rest of extension]; 370 } Certificate; 372 For a single certificate, this message will have a minumum of 2 bytes 373 of overhead for the two length bytes. 375 [[OPEN ISSUE: What should the default type be?]] 377 4.5.1. Key IDs 379 WARNING: This is a new feature which has not seen any analysis and so 380 may have real problems. 382 [[OPEN ISSUE: Do we want this at all?]] 384 It may also be possible to slim down the Certificate message further, 385 by adding a KeyID-based mode, in which they keys were just a table 386 index. This would redefines Certificate as: 388 struct { 389 varint key_id; 390 } KeyIdCertificate; 392 struct { 393 select (certiticate_type): 394 case RawPublicKey, x509: 395 CertificateEntry certificate_list<0..2^24-1>; 397 case key_id: 398 KeyIdCertificate; 399 } 400 } Certificate; 402 This allows the use of a short key id. Note that this is orthogonal 403 to the rest of the changes. 405 IMPORTANT: You really want to include the certificate in the 406 handshake transcript somehow, but this isn't specified for how. 408 4.5.2. CertificateVerify 410 Remove the signature algorithm and assume it's tied to the key. Note 411 that this does not work for RSA keys, but if we just decide to be EC 412 only, it works fine. 414 struct { 415 opaque signature[rest of message]; 416 } CertificateVerify; 418 4.5.3. Finished 420 Unchanged. 422 4.5.4. HelloRetryRequest 424 [[TODO]] 426 5. Handshake Size Calculations 428 5.1. ECDHE w/ Signatures 430 We compute the total flight size with X25519 and P-256 signatures, 431 thus the keys are 32-bytes long and the signatures 64 bytes, with a 432 cipher with an 8 byte auth tag, as in AEAD_AES_128_CCM_8. [Note: GCM 433 should not be used with a shortened tag.] Overhead estimates marked 434 with *** have been verified with Mint. Others are hand calculations 435 and so may prove to be approximate. 437 5.1.1. Flight 1 (ClientHello) *** 439 o Random: 16 441 o KeyShare: 32 443 o Message Overhead: 8 445 o Handshake Overhead: 2 447 o Record Overhead: 1 449 o Total: 59 451 5.1.2. Flight 2 (ServerHello..Finished) 453 ServerHello *** 455 o Random: 16 457 o KeyShare: 32 459 o Message Overhead: 6 461 o Handshake Overhead: 2 463 o Total: 56 465 EncryptedExtensions *** 467 o Handshake Overhead: 2 469 o Total: 2 470 CertificateRequest *** 472 o Handshake Overhead: 2 474 o Total: 2 476 Certificate 478 o Certificate: X 480 o Length bytes: 2 482 o Handshake Overhead: 2 484 o Total: 4 + X 486 CertificateVerify 488 o Signature: 64 490 o Handshake Overhead: 2 492 o Total: 66 494 Finished 496 o MAC: 32 498 o Overhead: 2 500 o Total: 34 502 Record Overhead: 2 bytes (2 records) + 8 bytes (auth tag). 504 [[OPEN ISSUE: We'll actually need a length field for the ServerHello, 505 to separate it from the ciphertext.]] 507 Total Size: 175 + X bytes. 509 5.1.3. Flight 3 (Client Certificate..Finished) 511 Certificate 513 o Certificate: X 515 o Length bytes: 2 517 o Handshake Overhead: 2 518 o Total: 4 + X 520 CertificateVerify 522 o Signature: 64 524 o Handshake Overhead: 2 526 o Total: 66 528 Finished 530 o MAC: 32 532 o Handshake Overhead: 2 534 o Total: 34 536 Record Overhead: 1 byte + 8 bytes (auth tag) 538 Total: 113 + X bytes 540 5.2. ECDHE w/ PSK 542 [TODO] 544 6. Security Considerations 546 WARNING: This document is effectively brand new and has seen no 547 analysis. The idea here is that CTLS is isomorphic to TLS 1.3, and 548 therefore should provide equivalent security guarantees, modulo use 549 of new features such as KeyID certificate messages. 551 One piece that is a new TLS 1.3 feature is the addition of the 552 key_id, which definitely requires some analysis, especially as it 553 looks like a potential source of identity misbinding. This is 554 entirely separable from the rest of the specification. 556 [[OPEN ISSUE: One could imagine internally translating CTLS to TLS 557 1.3 so that the transcript, etc. were the same, but I doubt it's 558 worth it, and then you might need to worry about cross-protocol 559 attacks.]] 561 7. IANA Considerations 563 This document has no IANA actions. 565 8. Normative References 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 573 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 574 May 2017, . 576 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 577 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 578 . 580 Acknowledgments 582 TODO acknowledge. 584 Author's Address 586 Eric Rescorla 587 Mozilla 589 Email: ekr@rtfm.com