TLS Working Group                                            E. Rescorla
Internet-Draft                                                   Mozilla
Intended status: Informational Standards Track                               R. Barnes
Expires: 6 November 2021 January 13, 2022                                          Cisco
                                                           H. Tschofenig
                                                             Arm Limited
                                                              5 May
                                                           July 12, 2021

                            Compact TLS 1.3
                         draft-ietf-tls-ctls-02
                         draft-ietf-tls-ctls-03

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, and a template-based specialization technique. 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 6 November 2021. January 13, 2022.

Copyright Notice

   Copyright (c) 2021 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)
   (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Common Primitives . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Varints . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Record Layer  . . . . . . . .  Template-based Specialization . . . . . . . . . . . . . .   4
     3.3.  Handshake Layer . . . . . . .
       3.2.1.  Requirements on TLS Implementations . . . . . . . . .   8
       3.2.2.  Predefined Extensions . . . . .   6
   4.  Handshake Messages . . . . . . . . . . .   8
       3.2.3.  Known Certificates  . . . . . . . . . .   7
     4.1.  ClientHello . . . . . . .   9
     3.3.  Record Layer  . . . . . . . . . . . . . . . .   7
     4.2.  ServerHello . . . . . .  10
     3.4.  Handshake Layer . . . . . . . . . . . . . . . . .   7
     4.3.  HelloRetryRequest . . . .  11
   4.  Handshake Messages  . . . . . . . . . . . . . . . .   7
   5.  Template-Based Specialization . . . . .  12
     4.1.  ClientHello . . . . . . . . . . .   8
     5.1.  Specifying a Specialization . . . . . . . . . . . .  12
     4.2.  ServerHello . . .   8
       5.1.1.  Requirements on the TLS Implementation . . . . . . .  10
       5.1.2.  Predefined Extensions . . . . . . . . . . . . .  12
     4.3.  HelloRetryRequest . . .  11
       5.1.3.  Known Certificates . . . . . . . . . . . . . . . . .  12
   6.  13
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Appendix A.  Sample Transcripts . .  Example Exchange . . . . . . . . . . . . . . .  15
     A.1.  ECDHE and Mutual Certificate-based Authentication . . . .  15
     A.2.  PSK . . . . . . . . . . . . . . . . . . . . . . . . . . .  17  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19  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 four basic techniques:

   *

   o  Omitting unnecessary values that are a holdover from previous
      versions of TLS.

   *

   o  Omitting the fields and handshake messages required for preserving
      backwards-compatibility with earlier TLS versions.

   *

   o  More compact encodings, omitting unnecessary values.

   * encodings.

   o  A template-based specialization mechanism that allows for pre-
      populating information at both endpoints without the
      creation of application specific versions of TLS that omit
      unnecessary values. need for
      negotiation.

   For the common (EC)DHE handshake with pre-established certificates,
   cTLS achieves an overhead of 45 bytes over the minimum required by
   the cryptovariables.  For a PSK handshake, the overhead is 21 bytes.
   Annotated handshake transcripts for these cases can be found in
   Appendix A.

   Because cTLS is semantically equivalent to TLS, it can be viewed
   either as a related protocol or as a compression mechanism.
   Specifically, it can be implemented by a layer between the TLS
   handshake state machine and the record layer.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Structure definitions listed below override TLS 1.3 definitions; any
   PDU not internally defined is taken from TLS 1.3 except for replacing
   integers with varints.

3.  Common Primitives

3.1.  Varints

   cTLS makes use of variable-length integers in order to allow a wide
   integer range while still providing for a minimal encoding.  The
   width of the integer is encoded in the first two bits of the field as
   follows, with xs indicating bits that form part of the integer.

              +============================+================+

              +----------------------------+----------------+
              | Bit pattern                | Length (bytes) |
              +============================+================+
              +----------------------------+----------------+
              | 0xxxxxxx                   | 1              |
              +----------------------------+----------------+
              +----------------------------+----------------+
              |                            |                |
              |                            |                |
              |                            |                |
              | 10xxxxxx xxxxxxxx          | 2              |
              +----------------------------+----------------+
              +----------------------------+----------------+
              |                            |                |
              |                            |                |
              |                            |                |
              | 11xxxxxx xxxxxxxx xxxxxxxx | 3              |
              +----------------------------+----------------+

                                  Table 1

   Thus, one byte can be used to carry values up to 127.

   In the TLS syntax variable integers are denoted as "varint" and a
   vector with a top range of a varint is denoted as:

        opaque foo<1..V>;

   cTLS uses the varint encoding for all multi-byte integers in TLS,
   including:

   *

   o  Values of type uint16, uint24, uint32, uint64

   *

   o  Array and vector entries of these types

   *

   o  Encoded lengths for vectors that allow more than 255 entries

   *

   o  Enums that allow more than 255 entries

   Values of type uint8, opaque values, and one-byte enums are not
   affected.  We do not show the structures which only change in this
   way.

3.2.  Record Layer  Template-based Specialization

   The only cTLS records that are sent transmission overhead in plaintext are handshake
   records (ClientHello and ServerHello/HRR).  The content type is
   therefore constant (it TLS 1.3 is always "handshake"), so we instead set the
   "content_type" field to a fixed cTLS-specific value largely contributed to distinguish
   cTLS plaintext records from encrypted records, TLS/DTLS records, and
   other protocols using the same 5-tuple.

   The "profile_id" field allows by two
   factors, : - the client negotiation of algorithm parameters, and server to agree on which extensions,
   as well as - the exchange of certificates.

   TLS 1.3 supports different credential types and modes that are
   impacted differently by a compression profile should scheme.  For example, TLS
   supports certificate-based authentication, raw public key-based
   authentication as well as pre-shared key (PSK)-based authentication.
   PSK-based authentication can be used for this session (see Section 5).
   This field MUST be set with externally configured PSKs
   or with PSKs established through tickets.

   The basic idea of template-based specialization is that we start with
   the basic TLS 1.3 handshake, which is fully general and then remove
   degrees of freedom, eliding parts of the handshake which are used to zero
   express those degrees of freedom.  For example, if we only support
   one version of TLS, then it is not necessary to have version
   negotiation and the supported_versions extension can be omitted.

   Importantly, this process is performed only if no compression profile for the wire encoding but
   not for the handshake transcript.  The result is that the transcript
   for a specialized cTLS handshake is the same as the transcript for a
   TLS 1.3 handshake with the same features used.  Non-zero values are negotiated out

   One way of band thinking of this is as if specialization is a stateful
   compression layer between the
   client handshake and server, as part of the specification record layer:

   +---------------+---------------+---------------+
   |   Handshake   |  Application  |     Alert     |
   +---------------+---------------+---------------+    +---------+
   |               cTLS Compression Layer          |<---| Profile |
   +---------------+---------------+---------------+    +---------+
   |          cTLS Record Layer / Application      |
   +---------------+---------------+---------------+

   By assuming that out-of-band agreements took place already prior to
   the start of the cTLS protocol exchange, the amount of data exchanged
   can be radically reduced.  Because different clients may use
   different compression
   profile.

         struct {
             ContentType content_type = ctls_handshake;
             varint profile_id;
             opaque fragment<0..V>;
         } CTLSPlaintext;

   [[OPEN ISSUE: The profile_id is needed templates and because multiple compression
   templates may be available for use in the ClientHello different deployment
   environments, a client needs to inform the server what compression about the profile
   it is planning 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.

         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
         | 8 or 16 bit   |   E   - Epoch
         |Sequence Number|
         | (if present)  |
         +-+-+-+-+-+-+-+-+
         | 16 bit Length |
         | (if present)  |
         +-+-+-+-+-+-+-+-+

         struct {
             opaque unified_hdr[variable];
             opaque encrypted_record[length];
         } CTLSCiphertext;  The presence and size of the connection ID profile field is negotiated as in
   DTLS.

   As with DTLS, the length field MAY be omitted by clearing the L bit,
   which means that ClientHello serves
   this purpose.

   Although the record consumes template-based specialization mechanisms described here
   are general, we also include specific mechanism for certificate-based
   exchanges because those are where the entire rest most complexity and size
   reduction can be obtained.  Most of the data other exchanges in
   the lower level transport.  In this case it is TLS 1.3
   are highly optimized and do not possible require compression 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 used.

   The compression profile defining the underlying layer.

   Normal DTLS does not provide use of algorithms, algorithm
   parameters, and extensions is specified via a mechanism for suppressing JSON dictionary.

   For example, the sequence
   number field entirely.  In cases where following specialization describes a sequence number is not
   required (e.g., when protocol with a reliable transport is in use),
   single fixed version (TLS 1.3) and a cTLS
   implementation may suppress it by setting the
   "suppressSequenceNumber" flag in single fixed cipher suite
   (TLS_AES_128_GCM_SHA256).  On the compression profile being used
   (see Section 5.1).  When this flag is enabled, wire, ClientHello.cipher_suites,
   ServerHello.cipher_suites, and the S bit supported_versions extensions in
   the
   configuration octet MUST ClientHello and ServerHello would be cleared.

3.3.  Handshake Layer omitted.

   {
      "version" : 772,
      "cipherSuite" : "TLS_AES_128_GCM_SHA256"
   }

   The cTLS handshake framing is same as following elements are defined:

   profile (integer):  identifies the profile being defined.

   version (integer):  indicates that both sides agree to the single TLS 1.3 handshake framing,
   except
      version specified by the given integer value (772 == 0x0304 for two changes:

   1.
      TLS 1.3).  The length field supported_versions extension is omitted

   2.  The HelloRetryRequest message is a true handshake message instead
       of a specialization of ServerHello.

         struct {
             HandshakeType msg_type;    /* handshake type */
             select (Handshake.msg_type) {
                 case client_hello:          ClientHello;
                 case server_hello:          ServerHello;
                 case hello_retry_request:   HelloRetryRequest;
                 case end_of_early_data:     EndOfEarlyData;
                 case encrypted_extensions:  EncryptedExtensions;
                 case certificate_request:   CertificateRequest;
                 case certificate:           Certificate;
                 case certificate_verify:    CertificateVerify;
                 case finished:              Finished;
                 case new_session_ticket:    NewSessionTicket;
                 case key_update:            KeyUpdate;
             };
         } Handshake;

4.  Handshake Messages

   In general, we retain from
      ClientHello.extensions and reconstructed in the basic structure of each individual TLS
   handshake message.  However, transcript as a
      single-valued list with the following handshake messages have
   been modified for space reduction specified value.  The
      supported_versions extension is omitted from
      ClientHello.extensions and cleaned up reconstructed in the transcript with
      the specified value.

   cipherSuite (string):  indicates that both sides agree to remove pre TLS
   1.3 baggage.

4.1.  ClientHello the single
      named cipher suite, using the "TLS_AEAD_HASH" syntax defined in
      [RFC8446], Section 8.4.  The cTLS ClientHello ClientHello.cipher_suites field is as follows.

         opaque Random[RandomLength];      // variable length

         struct {
             Random random;
             CipherSuite cipher_suites<1..V>;
             Extension extensions<1..V>;
         } ClientHello;

4.2.  ServerHello

   We redefine ServerHello
      omitted and reconstructed in the transcript as a similar way:

         struct {
             Random random;
             CipherSuite cipher_suite;
             Extension extensions<1..V>;
         } ServerHello;

4.3.  HelloRetryRequest

   The HelloRetryRequest has single-valued
      list with the following format:

         struct {
             CipherSuite cipher_suite;
             Extension extensions<2..V>;
         } HelloRetryRequest;

   It specified value.  The server_hello.cipher_suite
      field is omitted and reconstructed in the same transcript as the ServerHello above but without the unnecessary
   sentinel Random
      specified value.

5.  Template-Based Specialization

   dhGroup (string):  specifies a single DH group to use for key
      establishment.  The protocol 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 previous section code point
      name in [RFC8446], Section 4.2.7.  (e.g., ed25519).  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 fully general reconstructed, the Random is padded to the right
      with 0s and isomorphic the anti-downgrade mechanism in [RFC8446],
      Section 4.1.3 is disabled.  IMPORTANT: Using short Random values
      can lead to TLS 1.3; effectively it's just a small cleanup potential attacks.  The Random length MUST be less
      than or equal to 32 bytes.

   [[Open Issue: Karthik Bhargavan suggested the idea of hashing
   ephemeral public keys and to use the wire
   encoding result (truncated to match what we might have done starting from scratch.  It
   achieves some compaction, but only 32 bytes)
   as random values.  Such a modest amount. cTLS also
   includes change would require a mechanism for achieving very high compaction using
   template-based specialization.

   The basic idea is security analysis.
   ]]

   mutualAuth (boolean):  if set to true, indicates that we start with the basic TLS 1.3 handshake,
   which is fully general client must
      authenticate with a certificate by sending Certificate and then remove degrees of freedom, eliding
   parts of a
      CertificateVerify message.  The server MUST omit the handshake which
      CertificateRequest message, as its contents are used to express those degrees of
   freedom.  For example, if redundant.  [[OPEN
      ISSUE: We don't actually say that you can omit empty messages, so
      we only support one version of TLS, then it need to add that somewhere.]]

   extension_order:  indicates in what order extensions appear in
      respective messages.  This allows to omit sending the type.  If
      there is not necessary only a single extension to have version negotiation and be transmitted, then the
   supported_versions
      extension length field can also be omitted.

   Importantly, this process is performed only for the wire encoding but
   not for the handshake transcript.  The result is  For example, imagine
      that only the transcript
   for a specialized cTLS handshake is KeyShare extension needs to be sent in the same
      ClientHello as the transcript for a
   TLS 1.3 handshake with only extension.  Then, the same features used.

   One way of thinking of this is as if specialization following structure

      28                    // Extensions.length
      33 26                 // KeyShare
        0024                // client_shares.length
          001d              // KeyShareEntry.group
          0020 a690...af948 // KeyShareEntry.key_exchange

   is a stateful compressed down to (assuming the KeyShare group has been pre-
   agreed)

      0020 a690...af948 // KeyShareEntry.key_exchange

   clientHelloExtensions (predefined extensions):  Predefined
      ClientHello extensions, see {predefined-extensions}

   serverHelloExtensions (predefined extensions):  Predefined
      ServerHello extensions, see {predefined-extensions}

   encryptedExtensions (predefined extensions):  Predefined
      EncryptedExtensions extensions, see {predefined-extensions}

   certRequestExtensions (predefined extensions):  Predefined
      CertificateRequest extensions, see {predefined-extensions}

   knownCertificates (known certificates):  A compression layer between the handshake and dictionary for
      the record layer:

   +---------------+---------------+---------------+
   |   Handshake   |  Application  |     Alert     |
   +---------------+---------------+---------------+    +---------+
   |               cTLS Compression Layer          |<---| Profile |
   +---------------+---------------+---------------+    +---------+
   |          cTLS Record Layer / Application      |
   +---------------+---------------+---------------+

   Specializations are defined by a "compression profile" Certificate message, see {known-certs}

   finishedSize (integer):  indicates that specifies
   what features are the Finished value is to be optimized out of the handshake.  In
      truncated to the
   following subsections, we define given length.  When the structure of these profiles, and
   how they are used in compressing and decompressing handshake
   messages.

5.1.  Specifying a Specialization

   A compression profile defining of a specialized version of TLS transcript is
   defined using a JSON dictionary.  Each axis
      reconstructed, the remainder of specialization the Finished value is a
   key filled in by
      the dictionary. receiving side.

   [[OPEN ISSUE: If How short should we ever want to serialize
   this, we'll want allow this to use a list instead.]].

   For example, the following specialization describes a protocol with a
   single fixed version (TLS 1.3) and a single fixed cipher suite
   (TLS_AES_128_GCM_SHA256).  On the wire, ClientHello.cipher_suites,
   ServerHello.cipher_suites, and the supported_versions extensions in be?  TLS 1.3 uses the ClientHello
   native hash and ServerHello would be omitted.

   {
      "profileID": 33,
      "version" : 772,
      "cipherSuite" : "TLS_AES_128_GCM_SHA256"
   }

   cTLS allows specialization along TLS 1.2 used 12 bytes.  More analysis is needed to
   know the following axes:

   profileID (integer):  The identifier minimum safe Finished size.  See [RFC8446]; Section E.1 for this profile, to
   more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/
   TugB5ddJu3nYg7chcyeIyUqWSbA.]]

3.2.1.  Requirements on TLS Implementations

   To be sent in compatible with the "profile_id" field of CTLSPlaintext records.  This value MUST
      NOT be zero.  If specializations described in this value is not present, the default
      "profile_id" is 1.

   suppressSequenceNumber (boolean):  If present and set section,
   a TLS stack needs to true, provide the
      sequence number field following features:

   o  If specialization of extensions is omitted from encrypted record headers.

   version (integer):  indicates that both sides agree to be used, then the single TLS
      version specified by the given integer value (772 == 0x0304 for TLS 1.3).  The supported_versions extension is omitted from
      ClientHello.extensions and reconstructed stack
      MUST order each vector of Extension values in ascending order
      according to the transcript as ExtensionType.  This allows for a
      single-valued list with deterministic
      reconstruction of the specified value.  The
      supported_versions extension is omitted from
      ClientHello.extensions and reconstructed in the transcript with list.

   o  If truncated Random values are to be used, then the specified value.

   cipherSuite (string):  indicates that both sides agree TLS stack MUST
      be configurable to set the single
      named cipher suite, using remaining bytes of the "TLS_AEAD_HASH" syntax defined in
      [RFC8446], Section 8.4.  The ClientHello.cipher_suites field is
      omitted and reconstructed in random values to
      zero.  This ensures that the transcript as a single-valued
      list with reconstructed, padded random value
      matches the specified value.  The server_hello.cipher_suite
      field is omitted and reconstructed in original.

   o  If truncated Finished values are to be used, then the transcript as TLS stack
      MUST be configurable so that only the
      specified value.

   dhGroup (string):  specifies a single DH group to use for key
      establishment.  The group is listed by provided bytes of the code point name
      Finished are verified, or so that the expected remaining values
      can be computed.

3.2.2.  Predefined Extensions

   Extensions used in the ClientHello, ServerHello, EncryptedExtensions,
   and CertificateRequest messages can be "predefined" 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 compression
   profile, so that they do not have to
      use for authentication.  The group be sent on the wire.  A
   predefined extensions object is listed by a dictionary whose keys are extension
   names specified in the code point
      name TLS ExtensionTypeRegistry specified in [RFC8446], Section 4.2.7. (e.g., ed25519).  This implies
   [RFC8446].  The corresponding value is a
      literal "signature_algorithms" extension consisting solely hex-encoded value for the
   ExtensionData field of this
      group.

   randomSize (integer):  indicates that the ClientHello.Random and
      ServerHello.Random values are truncated extension.

   When compressing a handshake message, the sender compares the
   extensions in the message being compressed to the given values.  When predefined
   extensions object, applying the transcript following rules:

   o  If the extensions list in the message is reconstructed, not sorted in ascending
      order by extension type, it is an error, because the Random decompressed
      message will not match.

   o  If there is padded to no entry in the right
      with 0s and predefined extensions object for the anti-downgrade mechanism
      type of the extension, then the extension is included in {{RFC8446)},
      Section 4.1.3 the
      compressed message

   o  If there is disabled.  IMPORTANT: Using short Random values
      can lead to potential attacks.  When Random values are shorter
      than 8 bytes, PSK-only modes MUST NOT be used, and each side MUST
      use fresh DH ephemerals.  The Random length MUST be less than or
      equal to 32 bytes.

   clientHelloExtensions (predefined extensions):  Predefined
      ClientHello extensions, see {predefined-extensions}

   serverHelloExtensions (predefined extensions):  Predefined
      ServerHello extensions, see {predefined-extensions}

   encryptedExtensions (predefined extensions):  Predefined
      EncryptedExtensions extensions, see {predefined-extensions}

   certRequestExtensions (predefined extensions):  Predefined
      CertificateRequest extensions, see {predefined-extensions}

   knownCertificates (known certificates):  A compression dictionary for an entry:

      *  If the Certificate message, see {known-certs}

   finishedSize (integer):  indicates that ExtensionData of the extension does not match the Finished value
         in the dictionary, it is to be
      truncated to an error, because decompression will
         not produce the given length.  When correct result.

      *  If the transcript ExtensionData matches, then the extension is
      reconstructed, removed,
         and not included in the remainder of compressed message.

   When decompressing a handshake message the Finished value receiver reconstitutes the
   original extensions list using the predefined extensions:

   o  If there is filled an extension in by the receiving side.  [[OPEN ISSUE: How short should we allow this
      to be?  TLS 1.3 uses compressed message with a type
      that exists in the native hash and TLS 1.2 used 12 bytes.
      More analysis predefined extensions object, it is needed an error,
      because such an extension would not have been sent by a sender
      with a compatible compression profile.

   o  For each entry in the predefined extensions dictionary, an
      extension is added 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.]]

5.1.1.  Requirements on decompressed message with the TLS Implementation

   To specified
      type and value.

   o  The resulting vector of extensions MUST be compatible with sorted in ascending
      order by extension type.

   Note that the specializations described "version", "dhGroup", and "signatureAlgorithm" fields
   in this section,
   a TLS stack needs to provide two key features:

   If specialization the compression profile are specific instances of this algorithm
   for the corresponding extensions.

   [[OPEN ISSUE: Are there other extensions is that would benefit from
   special treatment, as opposed to hex values.]]

3.2.3.  Known Certificates

   Certificates are a major contributor to be used, then the TLS stack
   MUST order each vector size of Extension values in ascending a TLS handshake.
   In order
   according to avoid this overhead when the ExtensionType.  This allows for parties to a deterministic
   reconstruction handshake have
   already exchanged certificates, a compression profile can specify a
   dictionary of the extension list.

   If truncated Random "known certificates" that effectively acts as a
   compression dictionary on certificates.

   A known certificates object is a JSON dictionary whose keys are
   strings containing hex-encoded compressed values.  The corresponding
   values are to be used, then hex-encoded strings representing the TLS stack MUST be
   configurable to set uncompressed values.
   For example:

   {
     "00": "3082...",
     "01": "3082...",
   }
   When compressing a Certificate message, the remaining bytes of sender examines the random values to zero.
   This ensures that
   cert_data field of each CertificateEntry.  If the reconstructed, padded random value cert_data matches a
   value in the
   original.

   If truncated Finished values are to be used, known certificates object, then the TLS stack MUST
   be configurable so that only sender replaces the provided bytes of
   cert_data with the Finished are
   verified, or so that corresponding key.  Decompression works the expected remaining values can be computed.

5.1.2.  Predefined Extensions

   Extensions used
   opposite way, replacing keys with values.

   Note that in this scheme, there is no signaling on the ClientHello, ServerHello, EncryptedExtensions,
   and CertificateRequest messages can wire for
   whether a given cert_data value is compressed or uncompressed.  Known
   certificates objects SHOULD be "predefined" constructed in such a compression
   profile, so that they do not have way as to be sent on the wire.  A
   predefined extensions 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 dictionary whose keys value other than 0x30,
   since every X.509 certificate starts with this byte.

3.3.  Record Layer

   The only cTLS records that are extension
   names specified in the TLS ExtensionTypeRegistry specified sent in
   [RFC8446]. plaintext are handshake
   records (ClientHello and ServerHello/HRR).  The corresponding value content type is
   therefore constant (it is always "handshake"), so we instead set the
   "content_type" field to a hex-encoded fixed cTLS-specific value for to distinguish
   cTLS plaintext records from encrypted records, TLS/DTLS records, and
   other protocols using the
   ExtensionData 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 3.2).  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 extension.

   When compressing a handshake message, client and server, as part of the sender compares specification of
   the
   extensions compression profile.

         struct {
             ContentType content_type = ctls_handshake;
             varint profile_id;
             opaque fragment<0..V>;
         } CTLSPlaintext;

   [[OPEN ISSUE: The profile_id is needed in the message being compressed ClientHello to inform
   the predefined
   extensions object, applying the following rules:

   *  If the extensions list in the message server what compression profile to use.  For a ServerHello this
   field is not sorted in ascending
      order required.  Should we make this field optional?]]

   Encrypted records use DTLS 1.3 record framing, comprising a
   configuration octet followed by extension type, it is an error, because optional connection ID, sequence
   number, and length fields.

         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
         | 8 or 16 bit   |   E   - Epoch
         |Sequence Number|
         | (if present)  |
         +-+-+-+-+-+-+-+-+
         | 16 bit Length |
         | (if present)  |
         +-+-+-+-+-+-+-+-+

         struct {
             opaque unified_hdr[variable];
             opaque encrypted_record[length];
         } CTLSCiphertext;

   The presence and size of the decompressed
      message will not match.

   *  If there connection ID field is no entry negotiated as in
   DTLS.

   As with DTLS, the predefined extensions object for the
      type of the extension, then length field MAY be omitted by clearing the extension is included in L bit,
   which means that the
      compressed message

   *  If there is an entry:

      -  If record consumes the ExtensionData entire rest of the extension does not match the value data in
   the dictionary, lower level transport.  In this case it is an error, because decompression will
         not produce the correct result.

      -  If the ExtensionData matches, then the extension is removed,
         and not included possible to have
   multiple DTLSCiphertext format records without length fields in the compressed message.

   When decompressing a handshake message the receiver reconstitutes the
   original extensions list using the predefined extensions:

   *  If there is an extension in
   same datagram.  In stream-oriented transports (e.g., TCP), the compressed message with a type
      that exists in length
   field MUST be present.  For use over other transports length
   information may be inferred from the predefined extensions object, it is an error,
      because such an extension would underlying layer.

   Normal DTLS does not have been sent by a sender
      with provide a compatible compression profile.

   *  For each entry in mechanism for suppressing the predefined extensions dictionary, an
      extension sequence
   number field entirely.  In cases where a sequence number is not
   required (e.g., when a reliable transport is added to the decompressed message with the specified
      type and value.

   *  The resulting vector of extensions MUST be sorted in ascending
      order use), a cTLS
   implementation may suppress it by extension type.

   Note that setting the "version", "dhGroup", and "signatureAlgorithm" fields
   "suppressSequenceNumber" flag in the compression profile are specific instances of being used
   (see Section 3.2).  When this algorithm
   for flag is enabled, the corresponding extensions.

   [[OPEN ISSUE: Are there other extensions that would benefit from
   special treatment, S bit in the
   configuration octet MUST be cleared.

3.4.  Handshake Layer

   The cTLS handshake framing is same as opposed to hex values.]]

5.1.3.  Known Certificates

   Certificates are a major contributor to the size of a TLS handshake.
   In order to avoid this overhead when the parties to a 1.3 handshake have
   already exchanged certificates, a compression profile can specify framing,
   except for two changes:

   o  The length field is omitted.

   o  The HelloRetryRequest message is a
   dictionary true handshake message instead
      of "known certificates" that effectively acts as a
   compression dictionary on certificates.

   A known certificates object is a JSON dictionary whose keys are
   strings containing hex-encoded compressed values.  The corresponding
   values are hex-encoded strings representing the uncompressed values.
   For example: specialization of ServerHello.

         struct {
     "00": "3082...",
     "01": "3082...",
             HandshakeType msg_type;    /* handshake type */
             select (Handshake.msg_type) {
                 case client_hello:          ClientHello;
                 case server_hello:          ServerHello;
                 case hello_retry_request:   HelloRetryRequest;
                 case end_of_early_data:     EndOfEarlyData;
                 case encrypted_extensions:  EncryptedExtensions;
                 case certificate_request:   CertificateRequest;
                 case certificate:           Certificate;
                 case certificate_verify:    CertificateVerify;
                 case finished:              Finished;
                 case new_session_ticket:    NewSessionTicket;
                 case key_update:            KeyUpdate;
             };
         }

   When compressing a Certificate message, the sender examines Handshake;

4.  Handshake Messages

   In general, we retain the
   cert_data field basic structure of each CertificateEntry.  If individual TLS
   handshake message.  However, the cert_data matches a
   value following handshake messages have
   been modified for space reduction and cleaned up to remove pre-TLS
   1.3 baggage.

4.1.  ClientHello

   The cTLS ClientHello is defined as follows.

         opaque Random[RandomLength];      // variable length

         struct {
             Random random;
             CipherSuite cipher_suites<1..V>;
             Extension extensions<1..V>;
         } ClientHello;

4.2.  ServerHello

   We redefine ServerHello in the known certificates object, then the sender replaces the
   cert_data with the corresponding key.  Decompression works following way.

         struct {
             Random random;
             CipherSuite cipher_suite;
             Extension extensions<1..V>;
         } ServerHello;

4.3.  HelloRetryRequest

   The HelloRetryRequest has the
   opposite way, replacing keys with values.

   Note that in this scheme, there following format.

         struct {
             CipherSuite cipher_suite;
             Extension extensions<2..V>;
         } HelloRetryRequest;

   The HelloRetryRequest is no signaling on the wire for
   whether a given cert_data value is compressed or uncompressed.  Known
   certificates objects SHOULD be constructed in such a way same 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 ServerHello above but
   without the compressed value (key) to have a value other than 0x30,
   since every X.509 certificate starts with this byte.

6. unnecessary sentinel Random value.

5.  Examples

   The following

   This section provides some example specializations.

   For this example we use TLS 1.3 only:

   {
      "version" : 0x0304
   }

   TLS 1.3 only with AES_GCM and X25519 and AES_GCM, X25519, ALPN h2,
   short random values, and everything else is ordinary TLS 1.3.

   {
      "version"
      "Version" : 0x0304
      "Profile" : 1,
      "Version" : 772,
      "randomSize":
      "Random": 16,
      "cipherSuite"
      "CipherSuite" : "TLS_AES_128_GCM_SHA256",
      "dhGroup":
      "DHGroup": "X25519",
      "clientHelloExtensions":
      "Extensions": {
         "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?]]

7.

6.  Security Considerations

   WARNING: This document is effectively brand new and has seen no
   analysis.  The idea here is that cTLS is isomorphic to TLS 1.3, and
   therefore should provide equivalent security guarantees.

   The use of key ids is a new feature introduced in this document,
   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.

8.

7.  IANA Considerations

   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   |
               +-------+-------------+---------+-----------+

                                  Table 2

   [[ 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.]]

9.

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Appendix A.  Sample Transcripts

   In this section, we provide annotated example transcripts generated  Example Exchange

   The follow exchange illustrates a complete cTLS-based exchange
   supporting mutual authentication using a draft implementation of this specification in the mint TLS
   library. certificates.  The transcripts shown are digital
   signatures use ECDSA with SHA256 and NIST P256r1.  The ephemeral
   Diffie-Hellman uses the revised message formats
   defined above, as well as specialization to the indicated cases,
   using FX25519 curve and the aggressive compression profiles noted below. exchange negotiates
   TLS-AES-128-CCM8-SHA256.  The certificates are exchanged using
   certificate identifiers.

   The resulting byte counts are as follows:

                        ECDHE                PSK
                 ------------------
                 ------------------
                 TLS  CTLS  Overhead  TLS  CTLS  Overhead
                 ---  ----  --------
                 ---  ----  --------
   ClientHello   132   50      10     147   67      15   36       4
   ServerHello    90   48       8      56   18       2   36       4
   ServerFlight  478  104      16      42   12       3   80       7
   ClientFlight  458  100      11      36   10       1
   =====================================================   80       7
   ==================================
   Total        1158  302      45     280  107      21

   To increase legibility, we show the plaintext bytes of handshake
   messages that would be encrypted and shorten some of the
   cryptographic values (shown with "...").  232      22

   The totals above include 9
   bytes of encryption overhead for the client and server flights, which
   would otherwise be encrypted (with a one-byte content type and an
   8-byte tag).

   Obviously, these figures are very provisional, and as noted at
   several points above, there are additional opportunities to reduce
   overhead.

   [[NOTE: We are using a shortened Finished message here.  See
   Section 5.1 for notes on Finished size.  However, the overhead is
   constant for all reasonable Finished sizes.]]

A.1.  ECDHE and Mutual Certificate-based Authentication

   Compression Profile: 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",
     "randomSize": 8,
     "finishedSize": 8,
     "clientHelloExtensions": {
       "server_name": "000e00000b6578616d706c652e636f6d",
     },
     "certificateRequestExtensions": {
       "certificate_request_context": 0,
       "signature_algorithms": "00020403"
     },
     "mutualAuth": true,
     "extension-order": {
          "clientHelloExtensions": {
             Key_share
          },
          "ServerHelloExtensions": {
             Key_share
          },
     },

     "knownCertificates": {
       "61": "3082...",
       "62": "3082..." "3082...",
       "63": "...",
       "64": "...",
       ...
     }
   }
   ClientHello: 50 36 bytes = RANDOM(8) + DH(32) + Overhead(10) Overhead(4)

   01                    // ClientHello
   2ef16120dd84a721      // Random
   28                    // Extensions.length
   33 26                 // KeyShare
     0024                // client_shares.length
       001d
   01                    // KeyShareEntry.group Profile ID
   0020 a690...af948     // KeyShareEntry.key_exchange

   ServerHello: 48 36 = RANDOM(8) + DH(32) + Overhead(8) Overhead(4)

   02                 // ServerHello
   962547bba5e00973   // Random
   26                 // Extensions.length
   33 24              // KeyShare
     001d             // KeyShareEntry.group
   0020 9fbc...0f49   // KeyShareEntry.key_exchange

   Server Flight: 96 80 = SIG(71) SIG(64) + MAC(8) + CERTID(1) + Overhead(16)
   08                 // EncryptedExtensions
     00               //   Extensions.length
   0d                 // Overhead(7)

   The EncryptedExtensions, and the CertificateRequest
     00               //   CertificateRequestContext.length
     00               //   Extensions.length messages are
   omitted because they are empty.

   0b                 // Certificate
     00               //   CertificateRequestContext
     03               //   CertificateList
       01             //     CertData.length
         61           //       CertData = 'a'
       00             //   Extensions.length

   0f                 // CertificateVerify
     0403             //   SignatureAlgorithm
     4047
     4064             //   Signature.length
        3045...f60e
          3045...10ce //   Signature

   14                 // Finished
     bfc9d66715bb2b04 //   VerifyData

   Client Flight: 91 80 bytes = SIG(71) SIG(64) + MAC(8) + CERTID(1) + Overhead(11) Overhead(7)

   0b                 // Certificate
     00               //   CertificateRequestContext
     03               //   CertificateList
       01             //     CertData.length
         62           //       CertData = 'b'
       00             //     Extensions.length

   0f                 // CertificateVerify
     0403             //   SignatureAlgorithm
     4047
     4064             //   Signature.length
          3045...f60e //   Signature

   14                 // Finished
     35e9c34eec2c5dc1 //   VerifyData

A.2.  PSK

   Compression Profile:

   {
     "version": 772,
     "cipherSuite": "TLS_AES_128_CCM_8_SHA256",
     "signatureAlgorithm": "ECDSA_P256_SHA256",
     "randomSize": 16,
     "finishedSize": 0,
     "clientHelloExtensions": {
       "server_name": "000e00000b6578616d706c652e636f6d",
       "psk_key_exchange_modes": "0100"
     },
     "serverHelloExtensions": {
       "pre_shared_key": "0000"
     }
   }

   ClientHello: 67 bytes = RANDOM(16) + PSKID(4) + BINDER(32) +
   Overhead(15)

   01                               // ClientHello
   e230115e62d9a3b58f73e0f2896b2e35 // Random
   2d                               // Extensions.length
   29 2b                            // PreSharedKey
       000a                         //   identities.length
         0004 00010203              //     identity
         7bd05af6                   //     obfuscated_ticket_age
       0021                         //   binders.length
         20 2428...bb3f             //     binder

   ServerHello: 18 bytes = RANDOM(16) + 2

   02                                // ServerHello
   7232e2d3e61e476b844d9c1f6a4c868f  // Random
   00                                // Extensions.length

   Server Flight: 3 bytes = Overhead(3)

   08    // EncryptedExtensions
     00  //   Extensions.length
   14    // Finished

   Client Flight: 1 byte = Overhead(3)

   14    // Finished

Acknowledgments

   We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean
   Turner, 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