--- 1/draft-ietf-tls-ctls-04.txt 2022-03-07 13:13:32.165695248 -0800 +++ 2/draft-ietf-tls-ctls-05.txt 2022-03-07 13:13:32.201696156 -0800 @@ -1,21 +1,21 @@ TLS Working Group E. Rescorla Internet-Draft Mozilla Intended status: Standards Track R. Barnes -Expires: 28 April 2022 Cisco +Expires: 8 September 2022 Cisco H. Tschofenig Arm Limited - 25 October 2021 + 7 March 2022 Compact TLS 1.3 - draft-ietf-tls-ctls-04 + draft-ietf-tls-ctls-05 Abstract This document specifies a "compact" version of TLS 1.3. It is isomorphic to TLS 1.3 but saves space by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3, but it should eventually be possible for a cTLS/TLS 1.3 server to exist and successfully interoperate. @@ -27,57 +27,59 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 April 2022. + This Internet-Draft will expire on 8 September 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2.1. Template-based Specialization . . . . . . . . . . . . . . 3 - 2.1.1. Requirements on TLS Implementations . . . . . . . . . 6 + 2.1.1. Requirements on TLS Implementations . . . . . . . . . 7 2.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 7 2.1.3. Known Certificates . . . . . . . . . . . . . . . . . 8 2.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 10 3. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 11 3.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 12 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 7. Normative References . . . . . . . . . . . . . . . . . . . . 13 - Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 14 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.1. Adding a ContentType . . . . . . . . . . . . . . . . . . 13 + 6.2. Template Keys . . . . . . . . . . . . . . . . . . . . . . 13 + 7. Normative References . . . . . . . . . . . . . . . . . . . . 14 + Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 15 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet seen significant security analysis, so could contain major errors. It should not be used as a basis for building production systems. This document specifies a "compact" version of TLS 1.3 [RFC8446]. It is isomorphic to TLS 1.3 but designed to take up minimal bandwidth. The space reduction is achieved by five basic techniques: @@ -204,24 +206,24 @@ list with the specified value. The server_hello.cipher_suite field is omitted and reconstructed in the transcript as the specified value. dhGroup (string): specifies a single DH group to use for key establishment. The group is listed by the code point name in [RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal "supported_groups" extension consisting solely of this group. signatureAlgorithm (string): specifies a single signature scheme to - use for authentication. The group is listed by the code point - name in [RFC8446], Section 4.2.7. (e.g., ed25519). This implies a - literal "signature_algorithms" extension consisting solely of this - group. + use for authentication. The signature algorithm is listed by the + code point name in [RFC8446], Section 4.2.3. (e.g., + ecdsa_secp256r1_sha256). This implies a literal + "signature_algorithms" extension consisting solely of this group. random (integer): indicates that the ClientHello.Random and ServerHello.Random values are truncated to the given length. When the transcript is reconstructed, the Random is padded to the right with 0s and the anti-downgrade mechanism in [RFC8446], Section 4.1.3 is disabled. IMPORTANT: Using short Random values can lead to potential attacks. The Random length MUST be less than or equal to 32 bytes. [[Open Issue: Karthik Bhargavan suggested the idea of hashing @@ -273,20 +275,26 @@ truncated to the given length. When the transcript is reconstructed, the remainder of the Finished value is filled in by the receiving side. [[OPEN ISSUE: How short should we allow this to be? TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes. More analysis is needed to know the minimum safe Finished size. See [RFC8446]; Section E.1 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA.]] + optional (object): contains keys that are not required to be + understood by the client. Server operators MUST NOT place a key + in this section unless the server is able to determine whether the + key is in use based on the client data it receives. A key MUST + NOT appear in both the main template and the optional section. + 2.1.1. Requirements on TLS Implementations To be compatible with the specializations described in this section, a TLS stack needs to provide the following features: * If specialization of extensions is to be used, then the TLS stack MUST order each vector of Extension values in ascending order according to the ExtensionType. This allows for a deterministic reconstruction of the extension list. @@ -381,46 +388,39 @@ whether a given cert_data value is compressed or uncompressed. Known certificates objects SHOULD be constructed in such a way as to avoid a uncompressed object being mistaken for compressed one and erroneously decompressed. For X.509, it is sufficient for the first byte of the compressed value (key) to have a value other than 0x30, since every X.509 certificate starts with this byte. 2.2. Record Layer The only cTLS records that are sent in plaintext are handshake - records (ClientHello and ServerHello/HRR). The content type is - therefore constant (it is always handshake), so we instead set the - content_type field to a fixed cTLS-specific value to distinguish cTLS - plaintext records from encrypted records, TLS/DTLS records, and other - protocols using the same 5-tuple. - - The profile_id field allows the client and server to agree on which - compression profile should be used for this session (see - Section 2.1). This field MUST be set to zero if and only if no - compression profile is used. Non-zero values are negotiated out of - band between the client and server, as part of the specification of - the compression profile. + records (ClientHello and ServerHello/HRR) and alerts. cTLS alerts are + the same as TLS alerts and use the same content types. For handshake + records, we set the content_type field to a fixed cTLS-specific value + to distinguish cTLS plaintext records from encrypted records, TLS/ + DTLS records, and other protocols using the same 5-tuple. struct { ContentType content_type = ctls_handshake; - opaque profile_id<0..2^8-1>; - opaque fragment<0..V>; + opaque fragment<0..2^16-1>; } CTLSPlaintext; [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use. For a ServerHello this field is not required. Should we make this field optional?]] - Encrypted records use DTLS 1.3 record framing, comprising a - configuration octet followed by optional connection ID, sequence - number, and length fields. + Encrypted records use DTLS [I-D.draft-ietf-tls-dtls] 1.3 record + framing, comprising a configuration octet followed by optional + connection ID, sequence number, and length fields. The encryption + process and additional data are also as described in DTLS. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0|1|C|S|L|E E| +-+-+-+-+-+-+-+-+ | Connection ID | Legend: | (if any, | / length as / C - Connection ID (CID) present | negotiated) | S - Sequence number length +-+-+-+-+-+-+-+-+ L - Length present @@ -442,26 +442,25 @@ As with DTLS, the length field MAY be omitted by clearing the L bit, which means that the record consumes the entire rest of the data in the lower level transport. In this case it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram. In stream-oriented transports (e.g., TCP), the length field MUST be present. For use over other transports length information may be inferred from the underlying layer. Normal DTLS does not provide a mechanism for suppressing the sequence - number field entirely. In cases where a sequence number is not - required (e.g., when a reliable transport is in use), a cTLS - implementation may suppress it by setting the suppressSequenceNumber - flag in the compression profile being used (see Section 2.1). When - this flag is enabled, the S bit in the configuration octet MUST be - cleared. + number field entirely. When a reliable, ordered transport (e.g., + TCP) is in use, the S bit in the configuration octet MUST be cleared + and the sequence number MUST be omitted. When an unreliable + transport is in use, the S bit has its usual meaning and the sequence + number MUST be included. 2.3. Handshake Layer The cTLS handshake framing is same as the TLS 1.3 handshake framing, except for two changes: * The length field is omitted. * The HelloRetryRequest message is a true handshake message instead of a specialization of ServerHello. @@ -490,62 +489,69 @@ been modified for space reduction and cleaned up to remove pre-TLS 1.3 baggage. 3.1. ClientHello The cTLS ClientHello is defined as follows. opaque Random[RandomLength]; // variable length struct { + opaque profile_id<0..2^8-1>; Random random; - CipherSuite cipher_suites<1..V>; - Extension extensions<1..V>; + CipherSuite cipher_suites<1..2^16-1>; + Extension extensions<1..2^16-1>; } ClientHello; + The client uses the profile_id field to inform the server about the + compression profile being used (see Section 2.1). This field MUST be + set to a zero-length value and only if no compression profile is + used. Non zero-length values are agreed out of band between the + client and server, as part of the specification of the compression + profile. + 3.2. ServerHello We redefine ServerHello in the following way. struct { Random random; CipherSuite cipher_suite; - Extension extensions<1..V>; + Extension extensions<1..2^16-1>; } ServerHello; 3.3. HelloRetryRequest The HelloRetryRequest has the following format. struct { CipherSuite cipher_suite; - Extension extensions<2..V>; + Extension extensions<2..2^16-1>; } HelloRetryRequest; The HelloRetryRequest is the same as the ServerHello above but without the unnecessary sentinel Random value. 4. Examples This section provides some example specializations. For this example we use TLS 1.3 only with AES_GCM, X25519, ALPN h2, short random values, and everything else is ordinary TLS 1.3. { - "Version" : 0x0304 - "Profile" : 1, - "Version" : 772, - "Random": 16, - "CipherSuite" : "TLS_AES_128_GCM_SHA256", - "DHGroup": "X25519", - "Extensions": { + "profile" : 1, + "version" : 772, + "random": 16, + "cipherSuite" : "TLS_AES_128_GCM_SHA256", + "dhGroup": "X25519", + "clientHelloExtensions": { "named_groups": 29, "application_layer_protocol_negotiation" : "030016832", "..." : null } } Version 772 corresponds to the hex representation 0x0304, named group "29" (0x001D) represents X25519. [[OPEN ISSUE: Should we have a registry of well-known profiles?]] @@ -560,42 +566,92 @@ which requires some analysis, especially as it looks like a potential source of identity misbinding. This is, however, entirely separable from the rest of the specification. Transcript expansion also needs some analysis and we need to determine whether we need an extension to indicate that cTLS is in use and with which profile. 6. IANA Considerations +6.1. Adding a ContentType + This document requests that a code point be allocated from the "TLS ContentType registry. This value must be in the range 0-31 (inclusive). The row to be added in the registry has the following form: - +=======+=============+=========+===========+ + +=======+================+=========+===========+ | Value | Description | DTLS-OK | Reference | - +=======+=============+=========+===========+ - | TBD | ctls | N | RFCXXXX | - +-------+-------------+---------+-----------+ + +=======+================+=========+===========+ + | TBD | ctls | Y | RFCXXXX | + +-------+----------------+---------+-----------+ + | TBD | ctls_handshake | Y | RFCXXXX | + +-------+----------------+---------+-----------+ Table 1 [[ RFC EDITOR: Please replace the value TBD with the value assigned by IANA, and the value XXXX to the RFC number assigned for this document. ]] [[OPEN ISSUE: Should we require standards action for all profile IDs that would fit in 2 octets.]] +6.2. Template Keys + + This document requests that IANA open a new registry entitled "cTLS + Template Keys", on the Transport Layer Security (TLS) Parameters + page, with a "Specification Required" registration policy and the + following initial contents: + + +=======================+============+=================+ + | Key | JSON Type | Reference | + +=======================+============+=================+ + | profile | number | (This document) | + +-----------------------+------------+-----------------+ + | version | number | (This document) | + +-----------------------+------------+-----------------+ + | cipherSuite | string | (This document) | + +-----------------------+------------+-----------------+ + | dhGroup | string | (This document) | + +-----------------------+------------+-----------------+ + | signatureAlgorithm | string | (This document) | + +-----------------------+------------+-----------------+ + | random | number | (This document) | + +-----------------------+------------+-----------------+ + | mutualAuth | true/false | (This document) | + +-----------------------+------------+-----------------+ + | extension_order | object | (This document) | + +-----------------------+------------+-----------------+ + | clientHelloExtensions | object | (This document) | + +-----------------------+------------+-----------------+ + | serverHelloExtensions | object | (This document) | + +-----------------------+------------+-----------------+ + | encryptedExtensions | object | (This document) | + +-----------------------+------------+-----------------+ + | certRequestExtensions | object | (This document) | + +-----------------------+------------+-----------------+ + | knownCertificates | object | (This document) | + +-----------------------+------------+-----------------+ + | finishedSize | number | (This document) | + +-----------------------+------------+-----------------+ + | optional | object | (This document) | + +-----------------------+------------+-----------------+ + + Table 2 + 7. Normative References + [I-D.draft-ietf-tls-dtls] + "*** BROKEN REFERENCE ***". + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol @@ -624,37 +680,37 @@ ================================== Total 1158 232 22 The following compression profile was used in this example: { "profile": 1, "version": 772, "cipherSuite": "TLS_AES_128_CCM_8_SHA256", "dhGroup": "X25519", - "signatureAlgorithm": "ECDSA_P256_SHA256", + "signatureAlgorithm": "ecdsa_secp256r1_sha256", "finishedSize": 8, "clientHelloExtensions": { "server_name": "000e00000b6578616d706c652e636f6d", }, "certificateRequestExtensions": { "certificate_request_context": 0, "signature_algorithms": "00020403" }, "mutualAuth": true, "extension-order": { - "clientHelloExtensions": { - Key_share - }, - "ServerHelloExtensions": { - Key_share - }, + "clientHelloExtensions": [ + "key_share" + ], + "ServerHelloExtensions": [ + "key_share" + ], }, "knownCertificates": { "61": "3082...", "62": "3082...", "63": "...", "64": "...", ... } } @@ -697,27 +753,24 @@ 0f // CertificateVerify 4064 // Signature.length 3045...f60e // Signature 14 // Finished 35e9c34eec2c5dc1 // VerifyData Acknowledgments We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean - Turner, Martin Thomson and Chris Wood. + Turner, Benjamin Schwartz, Martin Thomson, and Chris Wood. Authors' Addresses Eric Rescorla Mozilla - Email: ekr@rtfm.com Richard Barnes Cisco - Email: rlb@ipv.sx Hannes Tschofenig Arm Limited - Email: hannes.tschofenig@arm.com