Change:
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> <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> <del> The following section provides some example specializations. </del> <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> <del> TLS 1.3 only: </del> <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> <del> TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and everything else is ordinary TLS 1.3. </del> <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?]] <del> 7. </del> <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

Discussion:
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.