Draft: draft-rescorla-tls-ctls

Commentary: This is semantically consistent with the code in mint , just with a slightly different syntax .
A specific instantiation 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.]].
For example, the following specialization describes a protocol with a
single fixed version (TLS 1.3) and a single fixed cipher suite
(TLS_AES_128_GCM_SHA256).  On the wire, ClientHello.versions,
ClientHello.cipher_suites, ServerHello.version, and
ServerHello.cipher_suites would be omitted.
indicates that both sides agree to the single TLS version
specified by the given integer value (772 == 0x0304 for TLS 1.3).
The ClientHello.versions field field is omitted and reconstructed
in the transcript as a single-valued list with the specified
value.  The ServerHello.version field is omitted and reconstructed
in the transcript as the specified value.
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.
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.
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.]].
For example, the following specialization describes a protocol with a
single fixed version (TLS 1.3) and a single fixed cipher suite
(TLS_AES_128_GCM_SHA256).  On the wire, ClientHello.cipher_suites,
ServerHello.cipher_suites, and the supported_versions extensions in
the ClientHello and ServerHello would be omitted.
indicates that both sides agree to the single TLS version
specified by the given integer value (772 == 0x0304 for TLS 1.3).
The supported_versions extension is omitted from
ClientHello.extensions and reconstructed in the transcript as a
single-valued list with the specified value.  The
supported_versions extension is omitted from
ClientHello.extensions and reconstructed in the transcript with
the specified value.
specifies a single DH group to use for key establishment.  The
group is listed by the code point name in RFC8446, Section 4.2.7.
(e.g., x25519).  This implies a literal "supported_groups"
extension consisting solely of this group.
specifies a single signature scheme to use for authentication.
The group is listed by the code point name in RFC8446,
Section 4.2.7.  (e.g., x25519).  This implies a literal
"signature_algorithms" extension consisting solely of this group.
a set of extensions which are being specialized, with each one
having its own dictionary entry.  The keys in the dictionary
entries are the extension names specified in the TLS
ExtensionTypeRegistry specified in RFC8446.  Each extension type
may have either a string value indicating the value of the
extension in hex or the value null indicating that the extension
will be present but serialized as described below.  If the special
extension name "..." is not present, then the list of extensions
is exhaustive.  If present, the extension "..." MUST have the
value null.
specifies a single DH group to use for key establishment.  The
group is listed by the code point name in RFC8446, Section 4.2.7.
(e.g., x25519).  This implies a literal "supported_groups"
extension consisting solely of this group and that there is a
KeyShare extension consisting solely of the value of the
KeyShareEntry.key_exchange (without the length bytes).
If an extension has a literal value, then it is not encoded on the
wire at all.  The literal value does not include the type and length
bytes.
If an extension has the value null, then it is serialized directly,
but omitting the extension_type value.  I.e.,
The listed extensions MUST be serialized in extension code point
order (this avoids having to carry the extensions code points on the
wire).
Any other extensions are serialized as usual, using the Extension
structure, and can appear in any order.
All of these are encoded using the usual TLS extension encoding.
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.
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.
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.
Extensions used in the ClientHello, ServerHello, EncryptedExtensions,
and CertificateRequest messages can be "predefined" in a compression
profile, so that they do not have to be sent on the wire.  A
predefined extensions object is a dictionary whose keys are extension
names specified in the TLS ExtensionTypeRegistry specified in
RFC8446.  The corresponding value is a hex-encoded value for the
ExtensionData field of the extension.
If the extensions list in the message is not sorted in ascending
order by extension type, it is an error, because the decompressed
message will not match.
If the ExtensionData of the extension does not match the value
in the dictionary, it is an error, because decompression will
not produce the correct result.
If the ExtensionData matches, then the extension is removed,
and not included in the compressed message.
If there is an extension in the compressed message with a type
that exists in the predefined extensions object, it is an error,
because such an extension would not have been sent by a sender
with a compatible compression profile.
For each entry in the predefined extensions dictionary, an
extension is added to the decompressed message with the specified
type and value.
The resulting vector of extensions MUST be sorted in ascending
order by extension type.
Note that the "version", "dhGroup", and "signatureAlgorithm" fields
in the compression profile are specific instances of this algorithm
for the corresponding extensions.
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
already exchanged certificates, a compression profile can specify a
dictionary of "known certificates" that effectively acts as a
compression dictionary on certificates.
When compressing a Certificate message, the sender examines the
cert_data field of each CertificateEntry.  If the cert_data matches a
value in the known certificates object, then the sender replaces the
cert_data with the corresponding key.  Decompression works the
opposite way, replacing keys with values.
Note that in this scheme, there is no signaling on the wire for
whether a given cert_data value is compressed or uncompressed.  Known
certificates objects should be constructed in such a way as to avoid
a uncompressed object being mistaken for compressed one and
erroneously decompressed.  For X.509, it is sufficient for the first
byte of the compressed value (key) to have a value other than 0x30,
since every X.509 certificate starts with this byte.