Original text:
Omitting the fields and handshake messages required for preserving backwards-compatibility with earlier TLS versions. <del> More compact encodings, omitting unnecessary values. </del>  <del> A template-based specialization mechanism that allows for the creation of application specific versions of TLS that omit unnecessary values. </del>  For the common (EC)DHE handshake with pre-established certificates, cTLS achieves an overhead of 45 bytes over the minimum required by 3.2. <del> 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 template- based-specialization).  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. [[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. The presence and size of the connection ID field is negotiated as in DTLS. 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 specifying-a-specialization).  When this flag is enabled, the S bit in the configuration octet MUST be cleared. 3.3. 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. 4. In general, we retain the basic structure of each individual TLS handshake message.  However, the following handshake messages have been modified for space reduction and cleaned up to remove pre TLS 1.3 baggage. 4.1. The cTLS ClientHello is as follows. 4.2. We redefine ServerHello in a similar way: 4.3. </del>  <del> The HelloRetryRequest has the following format: </del>  <del> It is the same as the ServerHello above but without the unnecessary sentinel Random value. 5. The protocol in the previous section is fully general and isomorphic to TLS 1.3; effectively it's just a small cleanup of the wire encoding to match what we might have done starting from scratch.  It achieves some compaction, but only a modest amount. cTLS also includes a mechanism for achieving very high compaction using template-based specialization. The basic idea 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 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. </del>  Importantly, this process is performed only for the wire encoding but not for the handshake transcript.  The result is that the transcript One way of thinking of this is as if specialization is a stateful compression layer between the handshake and the record layer: <del> Specializations are defined by a "compression profile" that specifies what features are to be optimized out of the handshake.  In the following subsections, we define the structure of these profiles, and how they are used in compressing and decompressing handshake messages. </del>  <del> 5.1. </del>  <del> A compression profile defining of a specialized version of TLS is defined using a JSON dictionary.  Each axis of specialization is a key in the dictionary.  [[OPEN ISSUE: If we ever want to serialize this, we'll want to use a list instead.]]. </del>  For example, the following specialization describes a protocol with a single fixed version (TLS 1.3) and a single fixed cipher suite ServerHello.cipher_suites, and the supported_versions extensions in the ClientHello and ServerHello would be omitted. <del> cTLS allows specialization along the following axes: The identifier for this profile, to be sent in the "profile_id" field of CTLSPlaintext records.  This value MUST NOT be zero.  If this value is not present, the default "profile_id" is 1. </del>  <del> If present and set to true, the sequence number field is omitted from encrypted record headers. </del>  indicates that both sides agree to the single TLS version specified by the given integer value (772 == 0x0304 for TLS 1.3). "signature_algorithms" extension consisting solely of this group. indicates that the ClientHello.Random and ServerHello.Random <del> values are truncated to the given values.  When the transcript is </del>  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 <del> 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 </del>  bytes.  Predefined ClientHello extensions, see {predefined-extensions} Predefined ServerHello extensions, see {predefined-extensions} indicates that the Finished value is to be truncated to the given length.  When the transcript is reconstructed, the remainder of <del> 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.]] </del>  <del> 5.1.1. </del>  To be compatible with the specializations described in this section, <del> a TLS stack needs to provide two key features: </del>  <del> 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. </del>  <del> If truncated Random values are to be used, then the TLS stack MUST be configurable to set the remaining bytes of the random values to zero. This ensures that the reconstructed, padded random value matches the original. </del>  <del> If truncated Finished values are to be used, then the TLS stack MUST be configurable so that only the provided bytes of the Finished are verified, or so that the expected remaining values can be computed. </del>  <del> 5.1.2. </del>  Extensions used in the ClientHello, ServerHello, EncryptedExtensions, and CertificateRequest messages can be "predefined" in a compression [[OPEN ISSUE: Are there other extensions that would benefit from special treatment, as opposed to hex values.]] <del> 5.1.3. </del>  Certificates are a major contributor to the size of a TLS handshake. In order to avoid this overhead when the parties to a handshake have byte of the compressed value (key) to have a value other than 0x30, since every X.509 certificate starts with this byte. <del> 6. </del>  <del> The following section provides some example specializations. </del>  <del> TLS 1.3 only: </del>  <del> TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and everything else is ordinary TLS 1.3. </del>  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?]] <del> 7. </del>  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 determine whether we need an extension to indicate that cTLS is in use and with which profile. <del> 8. </del>  This document requests that a code point be allocated from the "TLS ContentType registry.  This value must be in the range 0-31

Reviewer comments:
This update aims to bring the template-based optimization to the center and focuses on the certificiate-based authentication exchange. Included in this version is the idea to omit the random values transmitted by the client and the server by hashes of the ephemeral public keys.

Revised text:
Omitting the fields and handshake messages required for preserving backwards-compatibility with earlier TLS versions.  <ins> More compact encodings. </ins>  <ins> A template-based specialization mechanism that allows pre- populating information at both endpoints without the need for negotiation. </ins> For the common (EC)DHE handshake with pre-established certificates, cTLS achieves an overhead of 45 bytes over the minimum required by 3.2.  <ins> The transmission overhead in TLS 1.3 is largely contributed to by two factors, : - the negotiation of algorithm parameters, and extensions, as well as - the exchange of certificates. </ins>  <ins> TLS 1.3 supports different credential types and modes that are impacted differently by a compression 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 with externally configured PSKs or with PSKs established through tickets. </ins>  <ins> 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 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. </ins> Importantly, this process is performed only for the wire encoding but not for the handshake transcript.  The result is that the transcript One way of thinking of this is as if specialization is a stateful compression layer between the handshake and the record layer:  <ins> 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 templates and because multiple compression templates may be available for use in different deployment environments, a client needs to inform the server about the profile it is planning to use.  The profile field in the ClientHello serves this purpose. </ins>  <ins> Although the template-based specialization mechanisms described here are general, we also include specific mechanism for certificate-based exchanges because those are where the most complexity and size reduction can be obtained.  Most of the other exchanges in TLS 1.3 are highly optimized and do not require compression to be used. </ins>  <ins> The compression profile defining the use of algorithms, algorithm parameters, and extensions is specified via a JSON dictionary. </ins> For example, the following specialization describes a protocol with a single fixed version (TLS 1.3) and a single fixed cipher suite ServerHello.cipher_suites, and the supported_versions extensions in the ClientHello and ServerHello would be omitted.  <ins> The following elements are defined: </ins>  <ins> identifies the profile being defined. </ins> indicates that both sides agree to the single TLS version specified by the given integer value (772 == 0x0304 for TLS 1.3). "signature_algorithms" extension consisting solely of this group. indicates that the ClientHello.Random and ServerHello.Random  <ins> values are truncated to the given length.  When the transcript is </ins> 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  <ins> attacks.  The Random length MUST be less than or equal to 32 </ins> bytes. <ins> [[Open Issue: Karthik Bhargavan suggested the idea of hashing ephemeral public keys and to use the result (truncated to 32 bytes) as random values.  Such a change would require a security analysis. ]] indicates whether the client has to be prepared to transmit a Certificate and a CertificateVerify message and whether the server has to transmit a CertificateRequest message. indicates in what order extensions appear in respective messages. This allows to omit sending the type.  If there is only a single extension to be transmitted, then the extension length field can also be omitted.  For example, imagine that only the KeyShare extension needs to be sent in the ClientHello as the only extension.  Then, the following structure is compressed down to (assuming the KeyShare group has been pre- agreed) </ins> Predefined ClientHello extensions, see {predefined-extensions} Predefined ServerHello extensions, see {predefined-extensions} indicates that the Finished value is to be truncated to the given length.  When the transcript is reconstructed, the remainder of  <ins> the Finished value is filled in by the receiving side. </ins>  <ins> [[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.]] 3.2.1. </ins> To be compatible with the specializations described in this section,  <ins> a TLS stack needs to provide the following features: </ins>  <ins> 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. </ins>  <ins> If truncated Random values are to be used, then the TLS stack MUST be configurable to set the remaining bytes of the random values to zero.  This ensures that the reconstructed, padded random value matches the original. </ins>  <ins> If truncated Finished values are to be used, then the TLS stack MUST be configurable so that only the provided bytes of the Finished are verified, or so that the expected remaining values can be computed. </ins>  <ins> 3.2.2. </ins> Extensions used in the ClientHello, ServerHello, EncryptedExtensions, and CertificateRequest messages can be "predefined" in a compression [[OPEN ISSUE: Are there other extensions that would benefit from special treatment, as opposed to hex values.]]  <ins> 3.2.3. </ins> Certificates are a major contributor to the size of a TLS handshake. In order to avoid this overhead when the parties to a handshake have byte of the compressed value (key) to have a value other than 0x30, since every X.509 certificate starts with this byte.  <ins> 3.3. 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 template- based-specialization).  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. [[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. The presence and size of the connection ID field is negotiated as in DTLS. 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. </ins>  <ins> 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 specifying-a-specialization).  When this flag is enabled, the S bit in the configuration octet MUST be cleared. 3.4. 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. 4. In general, we retain the basic structure of each individual TLS handshake message.  However, the following handshake messages have been modified for space reduction and cleaned up to remove pre-TLS 1.3 baggage. 4.1. The cTLS ClientHello is defined as follows. 4.2. We redefine ServerHello in the following way. </ins>  <ins> 4.3. The HelloRetryRequest has the following format. The HelloRetryRequest is the same as the ServerHello above but without the unnecessary sentinel Random value. 5. </ins>  <ins> 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. </ins> 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?]]  <ins> 6. </ins> 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 determine whether we need an extension to indicate that cTLS is in use and with which profile.  <ins> 7. </ins> This document requests that a code point be allocated from the "TLS ContentType registry.  This value must be in the range 0-31