Draft: draft-ietf-tls-ctls

Commentary: 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 .
More compact encodings, omitting unnecessary values.
A template-based specialization mechanism that allows for the
creation of application specific versions of TLS that omit
unnecessary values.
More compact encodings.
A template-based specialization mechanism that allows pre-
populating information at both endpoints without the need for
negotiation.
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.
The cTLS ClientHello is as follows.
It is the same as the ServerHello above but without the unnecessary
sentinel Random value.
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.
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.
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.
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.
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.]].
By assuming that out-of-band agreements took place already prior to
the start of the cTLS protocol exchange, the amount of data exchanged
can be radically reduced.  Because different clients may use
different compression templates and because multiple compression
templates may be available for use in different deployment
environments, a client needs to inform the server about the profile
it is planning to use.  The profile field in the ClientHello serves
this purpose.
Although the template-based specialization mechanisms described here
are general, we also include specific mechanism for certificate-based
exchanges because those are where the most complexity and size
reduction can be obtained.  Most of the other exchanges in TLS 1.3
are highly optimized and do not require compression to be used.
The compression profile defining the use of algorithms, algorithm
parameters, and extensions is specified via a JSON dictionary.
The identifier for this profile, to be sent in the "profile_id"
field of CTLSPlaintext records.  This value MUST NOT be zero.  If
this value is not present, the default "profile_id" is 1.
If present and set to true, the sequence number field is omitted
from encrypted record headers.
identifies the profile being defined.
indicates that the ClientHello.Random and ServerHello.Random
values are truncated to the given values.  When the transcript is
reconstructed, the Random is padded to the right with 0s and the
anti-downgrade mechanism in RFC8446), Section 4.1.3 is disabled.
IMPORTANT: Using short Random values can lead to potential
attacks.  When Random values are shorter than 8 bytes, PSK-only
modes MUST NOT be used, and each side MUST use fresh DH
ephemerals.  The Random length MUST be less than or equal to 32
bytes.
indicates that the ClientHello.Random and ServerHello.Random
values are truncated to the given length.  When the transcript is
reconstructed, the Random is padded to the right with 0s and the
anti-downgrade mechanism in RFC8446), Section 4.1.3 is disabled.
IMPORTANT: Using short Random values can lead to potential
attacks.  The Random length MUST be less than or equal to 32
bytes.
indicates whether the client has to be prepared to transmit a
Certificate and a CertificateVerify message and whether the server
has to transmit a CertificateRequest message.
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, or so that the expected remaining values can be computed.
indicates that the Finished value is to be truncated to the given
length.  When the transcript is reconstructed, the remainder of
the Finished value is filled in by the receiving side.
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, or so that the expected remaining values
can be computed.
The following section provides some example specializations.
TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and
everything else is ordinary TLS 1.3.
The length field is omitted.
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.
The cTLS ClientHello is defined as follows.
We redefine ServerHello in the following way.
The HelloRetryRequest has the following format.
The HelloRetryRequest is the same as the ServerHello above but
without the unnecessary sentinel Random value.
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.