Change:
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> <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> <del> The HelloRetryRequest has the following format: </del> <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> <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> <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

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.