Draft: draft-ietf-tls-ctls

Commentary: Ping . This is the last thing blocking a refreshed cTLS draft . 
 Just missed this . LGTM
This is equivalent to a placing a literal "signature_algorithms"
extension consisting solely of this group in every extensions field
where it is permitted to appear.
This is equivalent to a placing a literal "signature_algorithms"
extension consisting solely of this group in every extensions field
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.
"predefined_extensions" and "expected_extensions" MUST be in strictly
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
corresponding "ExtensionType" MUST NOT appear here.
"predefined_extensions" and "expected_extensions" MUST be in strictly
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
corresponding "ExtensionType" MUST NOT appear here.  The
"pre_shared_key" "ExtensionType" MUST NOT appear in either list.
"Extension.extension_data" for any extension in
"expected_extensions" whose value has fixed length.  This applies
only to the corresponding message.
"Extension.extension_data" for any extension in
"expected_extensions" whose value is self-delimiting (e.g., fixed
length).  This applies only to the corresponding message.
Value: "uint8", with 0 indicating "false" and 1 indicating "true".
If true, handshake messages MUST be conveyed inside a "Handshake"
(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
"CTLSDatagramHandshake" struct (ctlshandshake), which MUST be the
payload of a single record.
Value: "uint8", with 0 indicating "false" and 1 indicating "true".
If true, handshake messages MUST be conveyed inside a "Handshake"
(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
"CTLSDatagramHandshake" struct (ctlshandshake), which MUST be the
payload of a single record.
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.
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.
On unreliable transports, the DTLS 1.3 ACK system is used.
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).
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).
OPEN ISSUE: Does "server_hello_extensions" apply to
"HelloRetryRequest"?
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?