Change:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM

Discussion:
This is equivalent to a placing a literal "signature_algorithms" extension consisting solely of this group in every extensions field <del> where it is permitted to appear. </del> <ins> where it is permitted to appear.  When this element is included, "CertificateVerify.algorithm" is omitted. Static vectors (see static-vectors): * "CertificateVerify.signature", if the "SignatureScheme" output is self-delimiting. </ins> In JSON, the signature algorithm is listed by the code point name in RFC8446, Section 4.2.3. (e.g., ecdsa_secp256r1_sha256).

ascending order by "ExtensionType", and a single "ExtensionType" MUST NOT appear in both lists.  If the "version", "dh_group", or "signature_algorithm" element appears in the template, the <del> corresponding "ExtensionType" MUST NOT appear here. </del> <ins> corresponding "ExtensionType" MUST NOT appear here.  The "pre_shared_key" "ExtensionType" MUST NOT appear in either list. </ins> OPEN ISSUE: Are there other extensions that would benefit from special treatment, as opposed to hex values.

Static vectors (see static-vectors): "Extension.extension_data" for any extension in <del> "expected_extensions" whose value has fixed length.  This applies only to the corresponding message. </del> <ins> "expected_extensions" whose value is self-delimiting (e.g., fixed length).  This applies only to the corresponding message. </ins> The "extensions" field of the corresponding message, if "allow_additional" is false.

Value: "uint8", with 0 indicating "false" and 1 indicating "true". If true, handshake messages MUST be conveyed inside a "Handshake" <del> (RFC8446, Section 4) struct on stream transports, or a "DTLSHandshake" (RFC9147, Section 5.2) struct on datagram transports, and MAY be broken into multiple records as in TLS and DTLS. Otherwise, each handshake message is conveyed in a "CTLSHandshake" or </del> <ins> (RFC8446, Section 4) struct on reliable, ordered transports, or a "DTLSHandshake" (RFC9147, Section 5.2) struct otherwise, and MAY be broken into multiple records as in TLS and DTLS.  If false, each handshake message is conveyed in a "CTLSHandshake" or </ins> "CTLSDatagramHandshake" struct (ctlshandshake), which MUST be the payload of a single record.

byte of the compressed value (key) to have a value other than 0x30, since every X.509 certificate starts with this byte. <ins> This element can be used to compress both client and server certificates.  However, in most deployments where client certificates are used, it would be inefficient to encode all client certificates into a single profile.  Instead, deployments can define a unique profile for each client, distinguished by the profile ID.  Note that the profile ID is sent in cleartext, so this strategy has significant privacy implications. </ins> 2.1.2. Some cTLS template elements imply that certain vectors (as defined in

their definition.  When encoding a "static vector", its length prefix is omitted. <ins> In addition to the static vectors implied by various template elements, "Extension.extension_data" is always static in cTLS if the extension is any type listed in Section 4.2 of RFC8446 except "padding".  cTLS implementations MUST be able to parse any of these extensions that the other party is permitted to send, but no other support is required. </ins> For example, suppose that the cTLS template is: Then, the following structure:

undesirable.  Operators can avoid these concerns by setting "template.handshakeFraming = true". <ins> On unreliable transports, the DTLS 1.3 ACK system is used. </ins> 2.3.2. TLS and DTLS start the handshake with an empty transcript.  cTLS is

represented in TLS "Handshake" messages, as in DTLS 1.3 (RFC9147, Section 5.2), regardless of "template.handshake_framing". <del> To ensure that all parties agree about what protocol is in use, the Cryptographic Label Prefix used for the handshake SHALL be "Sctls " for Stream cTLS and "Dctls " for Datagram cTLS.  (This is similar to the prefix substitution in Section 5.9 of RFC9147). </del> <ins> To ensure that all parties agree about what protocol is in use, and whether records are subject to loss, the Cryptographic Label Prefix used for the handshake SHALL be "Sctls " (for "Stream cTLS") if "Handshake" or "CTLSHandshake" transport was used, and "Dctls " (for "Datagram cTLS") otherwise.  (This is similar to the prefix substitution in Section 5.9 of RFC9147). </ins> 2.3.3.

The HelloRetryRequest is the same as the ServerHello above but without the unnecessary sentinel Random value. <del> OPEN ISSUE: Does "server_hello_extensions" apply to "HelloRetryRequest"? </del> <ins> OPEN ISSUE: Should we define a "hello_retry_request_extensions" template element?  Or is this too far off the happy path to be worth optimizing? </ins> 4.