draft-ietf-tls-ctls-03.txt   draft-ietf-tls-ctls-04.txt 
TLS Working Group E. Rescorla TLS Working Group E. Rescorla
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track R. Barnes Intended status: Standards Track R. Barnes
Expires: January 13, 2022 Cisco Expires: 28 April 2022 Cisco
H. Tschofenig H. Tschofenig
Arm Limited Arm Limited
July 12, 2021 25 October 2021
Compact TLS 1.3 Compact TLS 1.3
draft-ietf-tls-ctls-03 draft-ietf-tls-ctls-04
Abstract Abstract
This document specifies a "compact" version of TLS 1.3. It is This document specifies a "compact" version of TLS 1.3. It is
isomorphic to TLS 1.3 but saves space by trimming obsolete material, isomorphic to TLS 1.3 but saves space by trimming obsolete material,
tighter encoding, and a template-based specialization technique. cTLS tighter encoding, a template-based specialization technique, and
is not directly interoperable with TLS 1.3, but it should eventually alternative cryptographic techniques. cTLS is not directly
be possible for a cTLS/TLS 1.3 server to exist and successfully interoperable with TLS 1.3, but it should eventually be possible for
interoperate. a cTLS/TLS 1.3 server to exist and successfully interoperate.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2022. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Common Primitives . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Template-based Specialization . . . . . . . . . . . . . . 3
3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Requirements on TLS Implementations . . . . . . . . . 6
3.2. Template-based Specialization . . . . . . . . . . . . . . 4 2.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 7
3.2.1. Requirements on TLS Implementations . . . . . . . . . 8 2.1.3. Known Certificates . . . . . . . . . . . . . . . . . 8
3.2.2. Predefined Extensions . . . . . . . . . . . . . . . . 8 2.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Known Certificates . . . . . . . . . . . . . . . . . 9 2.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 10
3.3. Record Layer . . . . . . . . . . . . . . . . . . . . . . 10 3. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 11
3.4. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 11 3.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 11
4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 12 3.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 12
4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 12 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Normative References . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 14 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet
seen significant security analysis, so could contain major errors. seen significant security analysis, so could contain major errors.
It should not be used as a basis for building production systems. It should not be used as a basis for building production systems.
This document specifies a "compact" version of TLS 1.3 [RFC8446]. It This document specifies a "compact" version of TLS 1.3 [RFC8446]. It
is isomorphic to TLS 1.3 but designed to take up minimal bandwidth. is isomorphic to TLS 1.3 but designed to take up minimal bandwidth.
The space reduction is achieved by four basic techniques: The space reduction is achieved by five basic techniques:
o Omitting unnecessary values that are a holdover from previous * Omitting unnecessary values that are a holdover from previous
versions of TLS. versions of TLS.
o Omitting the fields and handshake messages required for preserving * Omitting the fields and handshake messages required for preserving
backwards-compatibility with earlier TLS versions. backwards-compatibility with earlier TLS versions.
o More compact encodings. * More compact encodings, for example point compression.
o A template-based specialization mechanism that allows pre- * A template-based specialization mechanism that allows pre-
populating information at both endpoints without the need for populating information at both endpoints without the need for
negotiation. negotiation.
* Alternative cryptographic techniques, such as semi-static Diffie-
Hellman.
For the common (EC)DHE handshake with pre-established certificates, For the common (EC)DHE handshake with pre-established certificates,
cTLS achieves an overhead of 45 bytes over the minimum required by cTLS achieves an overhead of 45 bytes over the minimum required by
the cryptovariables. For a PSK handshake, the overhead is 21 bytes. the cryptovariables. For a PSK handshake, the overhead is 21 bytes.
Annotated handshake transcripts for these cases can be found in Annotated handshake transcripts for these cases can be found in
Appendix A. Appendix A.
Because cTLS is semantically equivalent to TLS, it can be viewed Because cTLS is semantically equivalent to TLS, it can be viewed
either as a related protocol or as a compression mechanism. either as a related protocol or as a compression mechanism.
Specifically, it can be implemented by a layer between the TLS Specifically, it can be implemented by a layer between the TLS
handshake state machine and the record layer. handshake state machine and the record layer.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Structure definitions listed below override TLS 1.3 definitions; any Structure definitions listed below override TLS 1.3 definitions; any
PDU not internally defined is taken from TLS 1.3 except for replacing PDU not internally defined is taken from TLS 1.3.
integers with varints.
3. Common Primitives
3.1. Varints
cTLS makes use of variable-length integers in order to allow a wide
integer range while still providing for a minimal encoding. The
width of the integer is encoded in the first two bits of the field as
follows, with xs indicating bits that form part of the integer.
+----------------------------+----------------+
| Bit pattern | Length (bytes) |
+----------------------------+----------------+
| 0xxxxxxx | 1 |
| | |
| | |
| | |
| 10xxxxxx xxxxxxxx | 2 |
| | |
| | |
| | |
| 11xxxxxx xxxxxxxx xxxxxxxx | 3 |
+----------------------------+----------------+
Thus, one byte can be used to carry values up to 127.
In the TLS syntax variable integers are denoted as "varint" and a
vector with a top range of a varint is denoted as:
opaque foo<1..V>;
cTLS uses the varint encoding for all multi-byte integers in TLS,
including:
o Values of type uint16, uint24, uint32, uint64
o Array and vector entries of these types
o Encoded lengths for vectors that allow more than 255 entries
o Enums that allow more than 255 entries
Values of type uint8, opaque values, and one-byte enums are not
affected. We do not show the structures which only change in this
way.
3.2. Template-based Specialization 2.1. Template-based Specialization
The transmission overhead in TLS 1.3 is largely contributed to by two A significant transmission overhead in TLS 1.3 is contributed to by
factors, : - the negotiation of algorithm parameters, and extensions, two factors, : - the negotiation of algorithm parameters, and
as well as - the exchange of certificates. extensions, as well as - the exchange of certificates.
TLS 1.3 supports different credential types and modes that are TLS 1.3 supports different credential types and modes that are
impacted differently by a compression scheme. For example, TLS impacted differently by a compression scheme. For example, TLS
supports certificate-based authentication, raw public key-based supports certificate-based authentication, raw public key-based
authentication as well as pre-shared key (PSK)-based authentication. authentication as well as pre-shared key (PSK)-based authentication.
PSK-based authentication can be used with externally configured PSKs PSK-based authentication can be used with externally configured PSKs
or with PSKs established through tickets. or with PSKs established through tickets.
The basic idea of template-based specialization is that we start with 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 the basic TLS 1.3 handshake, which is fully general and then remove
skipping to change at page 6, line 33 skipping to change at page 5, line 24
cipherSuite (string): indicates that both sides agree to the single cipherSuite (string): indicates that both sides agree to the single
named cipher suite, using the "TLS_AEAD_HASH" syntax defined in named cipher suite, using the "TLS_AEAD_HASH" syntax defined in
[RFC8446], Section 8.4. The ClientHello.cipher_suites field is [RFC8446], Section 8.4. The ClientHello.cipher_suites field is
omitted and reconstructed in the transcript as a single-valued omitted and reconstructed in the transcript as a single-valued
list with the specified value. The server_hello.cipher_suite list with the specified value. The server_hello.cipher_suite
field is omitted and reconstructed in the transcript as the field is omitted and reconstructed in the transcript as the
specified value. specified value.
dhGroup (string): specifies a single DH group to use for key dhGroup (string): specifies a single DH group to use for key
establishment. The group is listed by the code point name in establishment. The group is listed by the code point name in
[RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal [RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal
"supported_groups" extension consisting solely of this group. "supported_groups" extension consisting solely of this group.
signatureAlgorithm (string): specifies a single signature scheme to signatureAlgorithm (string): specifies a single signature scheme to
use for authentication. The group is listed by the code point use for authentication. The group is listed by the code point
name in [RFC8446], Section 4.2.7. (e.g., ed25519). This implies name in [RFC8446], Section 4.2.7. (e.g., ed25519). This implies a
a literal "signature_algorithms" extension consisting solely of literal "signature_algorithms" extension consisting solely of this
this group. group.
random (integer): indicates that the ClientHello.Random and random (integer): indicates that the ClientHello.Random and
ServerHello.Random values are truncated to the given length. When ServerHello.Random values are truncated to the given length. When
the transcript is reconstructed, the Random is padded to the right the transcript is reconstructed, the Random is padded to the right
with 0s and the anti-downgrade mechanism in [RFC8446], with 0s and the anti-downgrade mechanism in [RFC8446],
Section 4.1.3 is disabled. IMPORTANT: Using short Random values Section 4.1.3 is disabled. IMPORTANT: Using short Random values
can lead to potential attacks. The Random length MUST be less can lead to potential attacks. The Random length MUST be less
than or equal to 32 bytes. than or equal to 32 bytes.
[[Open Issue: Karthik Bhargavan suggested the idea of hashing [[Open Issue: Karthik Bhargavan suggested the idea of hashing
skipping to change at page 8, line 11 skipping to change at page 6, line 49
truncated to the given length. When the transcript is truncated to the given length. When the transcript is
reconstructed, the remainder of the Finished value is filled in by reconstructed, the remainder of the Finished value is filled in by
the receiving side. the receiving side.
[[OPEN ISSUE: How short should we allow this to be? TLS 1.3 uses the [[OPEN ISSUE: How short should we allow this to be? TLS 1.3 uses the
native hash and TLS 1.2 used 12 bytes. More analysis is needed to native hash and TLS 1.2 used 12 bytes. More analysis is needed to
know the minimum safe Finished size. See [RFC8446]; Section E.1 for know the minimum safe Finished size. See [RFC8446]; Section E.1 for
more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/
TugB5ddJu3nYg7chcyeIyUqWSbA.]] TugB5ddJu3nYg7chcyeIyUqWSbA.]]
3.2.1. Requirements on TLS Implementations 2.1.1. Requirements on TLS Implementations
To be compatible with the specializations described in this section, To be compatible with the specializations described in this section,
a TLS stack needs to provide the following features: a TLS stack needs to provide the following features:
o If specialization of extensions is to be used, then the TLS stack * If specialization of extensions is to be used, then the TLS stack
MUST order each vector of Extension values in ascending order MUST order each vector of Extension values in ascending order
according to the ExtensionType. This allows for a deterministic according to the ExtensionType. This allows for a deterministic
reconstruction of the extension list. reconstruction of the extension list.
o If truncated Random values are to be used, then the TLS stack MUST * 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 be configurable to set the remaining bytes of the random values to
zero. This ensures that the reconstructed, padded random value zero. This ensures that the reconstructed, padded random value
matches the original. matches the original.
o If truncated Finished values are to be used, then the TLS stack * If truncated Finished values are to be used, then the TLS stack
MUST be configurable so that only the provided bytes of the MUST be configurable so that only the provided bytes of the
Finished are verified, or so that the expected remaining values Finished are verified, or so that the expected remaining values
can be computed. can be computed.
3.2.2. Predefined Extensions 2.1.2. Predefined Extensions
Extensions used in the ClientHello, ServerHello, EncryptedExtensions, Extensions used in the ClientHello, ServerHello, EncryptedExtensions,
and CertificateRequest messages can be "predefined" in a compression and CertificateRequest messages can be "predefined" in a compression
profile, so that they do not have to be sent on the wire. A profile, so that they do not have to be sent on the wire. A
predefined extensions object is a dictionary whose keys are extension predefined extensions object is a dictionary whose keys are extension
names specified in the TLS ExtensionTypeRegistry specified in names specified in the TLS ExtensionTypeRegistry specified in
[RFC8446]. The corresponding value is a hex-encoded value for the [RFC8446]. The corresponding value is a hex-encoded value for the
ExtensionData field of the extension. ExtensionData field of the extension.
When compressing a handshake message, the sender compares the When compressing a handshake message, the sender compares the
extensions in the message being compressed to the predefined extensions in the message being compressed to the predefined
extensions object, applying the following rules: extensions object, applying the following rules:
o If the extensions list in the message is not sorted in ascending * If the extensions list in the message is not sorted in ascending
order by extension type, it is an error, because the decompressed order by extension type, it is an error, because the decompressed
message will not match. message will not match.
o If there is no entry in the predefined extensions object for the * If there is no entry in the predefined extensions object for the
type of the extension, then the extension is included in the type of the extension, then the extension is included in the
compressed message compressed message
o If there is an entry: * If there is an entry:
* If the ExtensionData of the extension does not match the value - If the ExtensionData of the extension does not match the value
in the dictionary, it is an error, because decompression will in the dictionary, it is an error, because decompression will
not produce the correct result. not produce the correct result.
* If the ExtensionData matches, then the extension is removed, - If the ExtensionData matches, then the extension is removed,
and not included in the compressed message. and not included in the compressed message.
When decompressing a handshake message the receiver reconstitutes the When decompressing a handshake message the receiver reconstitutes the
original extensions list using the predefined extensions: original extensions list using the predefined extensions:
o If there is an extension in the compressed message with a type * If there is an extension in the compressed message with a type
that exists in the predefined extensions object, it is an error, that exists in the predefined extensions object, it is an error,
because such an extension would not have been sent by a sender because such an extension would not have been sent by a sender
with a compatible compression profile. with a compatible compression profile.
o For each entry in the predefined extensions dictionary, an * For each entry in the predefined extensions dictionary, an
extension is added to the decompressed message with the specified extension is added to the decompressed message with the specified
type and value. type and value.
o The resulting vector of extensions MUST be sorted in ascending * The resulting vector of extensions MUST be sorted in ascending
order by extension type. order by extension type.
Note that the "version", "dhGroup", and "signatureAlgorithm" fields Note that the "version", "dhGroup", and "signatureAlgorithm" fields
in the compression profile are specific instances of this algorithm in the compression profile are specific instances of this algorithm
for the corresponding extensions. for the corresponding extensions.
[[OPEN ISSUE: Are there other extensions that would benefit from [[OPEN ISSUE: Are there other extensions that would benefit from
special treatment, as opposed to hex values.]] special treatment, as opposed to hex values.]]
3.2.3. Known Certificates 2.1.3. Known Certificates
Certificates are a major contributor to the size of a TLS handshake. 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 In order to avoid this overhead when the parties to a handshake have
already exchanged certificates, a compression profile can specify a already exchanged certificates, a compression profile can specify a
dictionary of "known certificates" that effectively acts as a dictionary of "known certificates" that effectively acts as a
compression dictionary on certificates. compression dictionary on certificates.
A known certificates object is a JSON dictionary whose keys are A known certificates object is a JSON dictionary whose keys are
strings containing hex-encoded compressed values. The corresponding strings containing hex-encoded compressed values. The corresponding
values are hex-encoded strings representing the uncompressed values. values are hex-encoded strings representing the uncompressed values.
skipping to change at page 10, line 18 skipping to change at page 9, line 13
opposite way, replacing keys with values. opposite way, replacing keys with values.
Note that in this scheme, there is no signaling on the wire for Note that in this scheme, there is no signaling on the wire for
whether a given cert_data value is compressed or uncompressed. Known whether a given cert_data value is compressed or uncompressed. Known
certificates objects SHOULD be constructed in such a way as to avoid certificates objects SHOULD be constructed in such a way as to avoid
a uncompressed object being mistaken for compressed one and a uncompressed object being mistaken for compressed one and
erroneously decompressed. For X.509, it is sufficient for the first erroneously decompressed. For X.509, it is sufficient for the first
byte of the compressed value (key) to have a value other than 0x30, byte of the compressed value (key) to have a value other than 0x30,
since every X.509 certificate starts with this byte. since every X.509 certificate starts with this byte.
3.3. Record Layer 2.2. Record Layer
The only cTLS records that are sent in plaintext are handshake The only cTLS records that are sent in plaintext are handshake
records (ClientHello and ServerHello/HRR). The content type is records (ClientHello and ServerHello/HRR). The content type is
therefore constant (it is always "handshake"), so we instead set the therefore constant (it is always handshake), so we instead set the
"content_type" field to a fixed cTLS-specific value to distinguish content_type field to a fixed cTLS-specific value to distinguish cTLS
cTLS plaintext records from encrypted records, TLS/DTLS records, and plaintext records from encrypted records, TLS/DTLS records, and other
other protocols using the same 5-tuple. protocols using the same 5-tuple.
The "profile_id" field allows the client and server to agree on which The profile_id field allows the client and server to agree on which
compression profile should be used for this session (see compression profile should be used for this session (see
Section 3.2). This field MUST be set to zero if and only if no Section 2.1). This field MUST be set to zero if and only if no
compression profile is used. Non-zero values are negotiated out of compression profile is used. Non-zero values are negotiated out of
band between the client and server, as part of the specification of band between the client and server, as part of the specification of
the compression profile. the compression profile.
struct { struct {
ContentType content_type = ctls_handshake; ContentType content_type = ctls_handshake;
varint profile_id; opaque profile_id<0..2^8-1>;
opaque fragment<0..V>; opaque fragment<0..V>;
} CTLSPlaintext; } CTLSPlaintext;
[[OPEN ISSUE: The profile_id is needed in the ClientHello to inform [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform
the server what compression profile to use. For a ServerHello this the server what compression profile to use. For a ServerHello this
field is not required. Should we make this field optional?]] field is not required. Should we make this field optional?]]
Encrypted records use DTLS 1.3 record framing, comprising a Encrypted records use DTLS 1.3 record framing, comprising a
configuration octet followed by optional connection ID, sequence configuration octet followed by optional connection ID, sequence
number, and length fields. number, and length fields.
skipping to change at page 11, line 41 skipping to change at page 10, line 41
which means that the record consumes the entire rest of the data in 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 the lower level transport. In this case it is not possible to have
multiple DTLSCiphertext format records without length fields in the multiple DTLSCiphertext format records without length fields in the
same datagram. In stream-oriented transports (e.g., TCP), the length same datagram. In stream-oriented transports (e.g., TCP), the length
field MUST be present. For use over other transports length field MUST be present. For use over other transports length
information may be inferred from the underlying layer. information may be inferred from the underlying layer.
Normal DTLS does not provide a mechanism for suppressing the sequence Normal DTLS does not provide a mechanism for suppressing the sequence
number field entirely. In cases where a sequence number is not number field entirely. In cases where a sequence number is not
required (e.g., when a reliable transport is in use), a cTLS required (e.g., when a reliable transport is in use), a cTLS
implementation may suppress it by setting the implementation may suppress it by setting the suppressSequenceNumber
"suppressSequenceNumber" flag in the compression profile being used flag in the compression profile being used (see Section 2.1). When
(see Section 3.2). When this flag is enabled, the S bit in the this flag is enabled, the S bit in the configuration octet MUST be
configuration octet MUST be cleared. cleared.
3.4. Handshake Layer 2.3. Handshake Layer
The cTLS handshake framing is same as the TLS 1.3 handshake framing, The cTLS handshake framing is same as the TLS 1.3 handshake framing,
except for two changes: except for two changes:
o The length field is omitted. * The length field is omitted.
o The HelloRetryRequest message is a true handshake message instead * The HelloRetryRequest message is a true handshake message instead
of a specialization of ServerHello. of a specialization of ServerHello.
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case end_of_early_data: EndOfEarlyData; case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions; case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate: Certificate; case certificate: Certificate;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case new_session_ticket: NewSessionTicket; case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate; case key_update: KeyUpdate;
}; };
} Handshake; } Handshake;
4. Handshake Messages 3. Handshake Messages
In general, we retain the basic structure of each individual TLS In general, we retain the basic structure of each individual TLS
handshake message. However, the following handshake messages have handshake message. However, the following handshake messages have
been modified for space reduction and cleaned up to remove pre-TLS been modified for space reduction and cleaned up to remove pre-TLS
1.3 baggage. 1.3 baggage.
4.1. ClientHello 3.1. ClientHello
The cTLS ClientHello is defined as follows. The cTLS ClientHello is defined as follows.
opaque Random[RandomLength]; // variable length opaque Random[RandomLength]; // variable length
struct { struct {
Random random; Random random;
CipherSuite cipher_suites<1..V>; CipherSuite cipher_suites<1..V>;
Extension extensions<1..V>; Extension extensions<1..V>;
} ClientHello; } ClientHello;
4.2. ServerHello 3.2. ServerHello
We redefine ServerHello in the following way. We redefine ServerHello in the following way.
struct { struct {
Random random; Random random;
CipherSuite cipher_suite; CipherSuite cipher_suite;
Extension extensions<1..V>; Extension extensions<1..V>;
} ServerHello; } ServerHello;
4.3. HelloRetryRequest 3.3. HelloRetryRequest
The HelloRetryRequest has the following format. The HelloRetryRequest has the following format.
struct { struct {
CipherSuite cipher_suite; CipherSuite cipher_suite;
Extension extensions<2..V>; Extension extensions<2..V>;
} HelloRetryRequest; } HelloRetryRequest;
The HelloRetryRequest is the same as the ServerHello above but The HelloRetryRequest is the same as the ServerHello above but
without the unnecessary sentinel Random value. without the unnecessary sentinel Random value.
5. Examples 4. Examples
This section provides some example specializations. This section provides some example specializations.
For this example we use TLS 1.3 only with AES_GCM, X25519, ALPN h2, 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. short random values, and everything else is ordinary TLS 1.3.
{ {
"Version" : 0x0304 "Version" : 0x0304
"Profile" : 1, "Profile" : 1,
"Version" : 772, "Version" : 772,
skipping to change at page 13, line 43 skipping to change at page 12, line 43
"application_layer_protocol_negotiation" : "030016832", "application_layer_protocol_negotiation" : "030016832",
"..." : null "..." : null
} }
} }
Version 772 corresponds to the hex representation 0x0304, named group Version 772 corresponds to the hex representation 0x0304, named group
"29" (0x001D) represents X25519. "29" (0x001D) represents X25519.
[[OPEN ISSUE: Should we have a registry of well-known profiles?]] [[OPEN ISSUE: Should we have a registry of well-known profiles?]]
6. Security Considerations 5. Security Considerations
WARNING: This document is effectively brand new and has seen no WARNING: This document is effectively brand new and has seen no
analysis. The idea here is that cTLS is isomorphic to TLS 1.3, and analysis. The idea here is that cTLS is isomorphic to TLS 1.3, and
therefore should provide equivalent security guarantees. therefore should provide equivalent security guarantees.
The use of key ids is a new feature introduced in this document, The use of key ids is a new feature introduced in this document,
which requires some analysis, especially as it looks like a potential which requires some analysis, especially as it looks like a potential
source of identity misbinding. This is, however, entirely separable source of identity misbinding. This is, however, entirely separable
from the rest of the specification. from the rest of the specification.
Transcript expansion also needs some analysis and we need to Transcript expansion also needs some analysis and we need to
determine whether we need an extension to indicate that cTLS is in determine whether we need an extension to indicate that cTLS is in
use and with which profile. use and with which profile.
7. IANA Considerations 6. IANA Considerations
This document requests that a code point be allocated from the "TLS This document requests that a code point be allocated from the "TLS
ContentType registry. This value must be in the range 0-31 ContentType registry. This value must be in the range 0-31
(inclusive). The row to be added in the registry has the following (inclusive). The row to be added in the registry has the following
form: form:
+-------+-------------+---------+-----------+ +=======+=============+=========+===========+
| Value | Description | DTLS-OK | Reference | | Value | Description | DTLS-OK | Reference |
+-------+-------------+---------+-----------+ +=======+=============+=========+===========+
| TBD | ctls | N | RFCXXXX | | TBD | ctls | N | RFCXXXX |
+-------+-------------+---------+-----------+ +-------+-------------+---------+-----------+
Table 1
[[ RFC EDITOR: Please replace the value TBD with the value assigned [[ RFC EDITOR: Please replace the value TBD with the value assigned
by IANA, and the value XXXX to the RFC number assigned for this by IANA, and the value XXXX to the RFC number assigned for this
document. ]] document. ]]
[[OPEN ISSUE: Should we require standards action for all profile IDs [[OPEN ISSUE: Should we require standards action for all profile IDs
that would fit in 2 octets.]] that would fit in 2 octets.]]
8. Normative References 7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 End of changes. 53 change blocks. 
133 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/