draft-ietf-tls-ctls-00.txt   draft-ietf-tls-ctls-01.txt 
TLS Working Group E. Rescorla TLS Working Group E. Rescorla
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational R. Barnes Intended status: Informational R. Barnes
Expires: 28 October 2020 Cisco Expires: 6 May 2021 Cisco
H. Tschofenig H. Tschofenig
Arm Limited Arm Limited
26 April 2020 2 November 2020
Compact TLS 1.3 Compact TLS 1.3
draft-ietf-tls-ctls-00 draft-ietf-tls-ctls-01
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, and a template-based specialization technique. cTLS
is not directly interoperable with TLS 1.3, but it should eventually is not directly interoperable with TLS 1.3, but it should eventually
be possible for a cTLS/TLS 1.3 server to exist and successfully be possible for a cTLS/TLS 1.3 server to exist and successfully
interoperate. interoperate.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 28 October 2020. This Internet-Draft will expire on 6 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 14 skipping to change at page 2, line 14
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as 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 3. Common Primitives . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 5 3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 6
4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 6 4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 7
4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 7 4.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 7
5. Template-Based Specialization . . . . . . . . . . . . . . . . 7 5. Template-Based Specialization . . . . . . . . . . . . . . . . 8
5.1. Specifying a Specialization . . . . . . . . . . . . . . . 8 5.1. Specifying a Specialization . . . . . . . . . . . . . . . 8
5.1.1. Requirements on the TLS Implementation . . . . . . . 10 5.1.1. Requirements on the TLS Implementation . . . . . . . 10
5.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 10 5.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 11
5.1.3. Known Certificates . . . . . . . . . . . . . . . . . 11 5.1.3. Known Certificates . . . . . . . . . . . . . . . . . 12
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Sample Transcripts . . . . . . . . . . . . . . . . . 13 Appendix A. Sample Transcripts . . . . . . . . . . . . . . . . . 15
A.1. ECDHE and Mutual Certificate-based Authentication . . . . 14 A.1. ECDHE and Mutual Certificate-based Authentication . . . . 15
A.2. PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.2. PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 four basic techniques:
skipping to change at page 4, line 5 skipping to change at page 4, line 5
3. Common Primitives 3. Common Primitives
3.1. Varints 3.1. Varints
cTLS makes use of variable-length integers in order to allow a wide cTLS makes use of variable-length integers in order to allow a wide
integer range while still providing for a minimal encoding. The 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 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. follows, with xs indicating bits that form part of the integer.
+----------------------------+----------------+ +============================+================+
| Bit pattern | Length (bytes) | | Bit pattern | Length (bytes) |
+============================+================+ +============================+================+
| 0xxxxxxx | 1 | | 0xxxxxxx | 1 |
+----------------------------+----------------+ +----------------------------+----------------+
+----------------------------+----------------+ +----------------------------+----------------+
| 10xxxxxx xxxxxxxx | 2 | | 10xxxxxx xxxxxxxx | 2 |
+----------------------------+----------------+ +----------------------------+----------------+
+----------------------------+----------------+ +----------------------------+----------------+
| 11xxxxxx xxxxxxxx xxxxxxxx | 3 | | 11xxxxxx xxxxxxxx xxxxxxxx | 3 |
+----------------------------+----------------+ +----------------------------+----------------+
Table 1 Table 1
Thus, one byte can be used to carry values up to 127. Thus, one byte can be used to carry values up to 127.
In the TLS syntax variable integers are denoted as "varint" and a In the TLS syntax variable integers are denoted as "varint" and a
vector with a top range of a varint is denoted as: vector with a top range of a varint is denoted as:
opaque foo<1..V>; opaque foo<1..V>;
cTLS replaces all integers in TLS with varints, including: cTLS uses the varint encoding for all multi-byte integers in TLS,
including:
* Values of uint8, uint16, uint24, uint32, and uint64
* Vector length prefixes * Values of type uint16, uint24, uint32, uint64
* Enum / code point values * Array and vector entries of these types
We do not show the structures which only change in this way. * Encoded lengths for vectors that allow more than 255 entries
This allows implementations' encoding and decoding logic to implement * Enums that allow more than 255 entries
cTLS simply by having a mode in which integers always use the varint
encoding. Note that if implementations treat opaque data in the same
way as "uint8" values, they MUST NOT convert the bytes of an opaque
value to varints.
As an example, suppose we are given the following struct: 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.
struct { 3.2. Record Layer
uint32 FieldA;
opaque FieldB<0..2^16-1>;
} ExampleStruct;
Encoding a value of this type with values FieldA=0x0A and The only cTLS records that are sent in plaintext are handshake
FieldB=0x0B0B0B0B0B would result in the following octet strings in records (ClientHello and ServerHello/HRR). The content type is
"normal" (RFC 8446) and "compact" modes, respectively: therefore constant (it is always "handshake"), so we instead set the
"content_type" field to a fixed cTLS-specific value to distinguish
cTLS plaintext records from encrypted records, TLS/DTLS records, and
other protocols using the same 5-tuple.
Normal: 0000000A00050B0B0B0B0B The "profile_id" field allows the client and server to agree on which
Compact: 0A050B0B0B0B0B compression profile should be used for this session (see Section 5).
This field MUST be set to zero if and only if no compression profile
is used. Non-zero values are negotiated out of band between the
client and server, as part of the specification of the compression
profile.
3.2. Record Layer struct {
ContentType content_type = ctls_handshake;
varint profile_id;
opaque fragment<0..V>;
} CTLSPlaintext;
The cTLS Record Layer assumes that records are externally framed [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform
(i.e., that the length is already known because it is carried in a the server what compression profile to use. For a ServerHello this
UDP datagram or the like). Depending on how this was carried, you field is not required. Should we make this field optional?]]
might need another byte or two for that framing. Thus, only the type
byte need be carried and TLSPlaintext becomes:
struct { Encrypted records use DTLS 1.3 record framing, comprising a
ContentType type; configuration octet followed by optional connection ID, sequence
opaque fragment[TLSPlaintext.length]; number, and length fields.
} TLSPlaintext;
In addition, because the epoch is known in advance, the dummy content 0 1 2 3 4 5 6 7
type is not needed for the ciphertext, so TLSCiphertext becomes: +-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+
| Connection ID | Legend:
| (if any, |
/ length as / C - Connection ID (CID) present
| negotiated) | S - Sequence number length
+-+-+-+-+-+-+-+-+ L - Length present
| 8 or 16 bit | E - Epoch
|Sequence Number|
| (if present) |
+-+-+-+-+-+-+-+-+
| 16 bit Length |
| (if present) |
+-+-+-+-+-+-+-+-+
struct { struct {
opaque content[TLSPlaintext.length]; opaque unified_hdr[variable];
ContentType type; opaque encrypted_record[length];
uint8 zeros[length_of_padding]; } CTLSCiphertext;
} TLSInnerPlaintext;
struct { The presence and size of the connection ID field is negotiated as in
opaque encrypted_record[TLSCiphertext.length]; DTLS.
} TLSCiphertext;
Note: The user is responsible for ensuring that the sequence numbers/ As with DTLS, the length field MAY be omitted by clearing the L bit,
nonces are handled in the usual fashion. 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
multiple DTLSCiphertext format records without length fields in the
same datagram. In stream-oriented transports (e.g., TCP), the length
field MUST be present. For use over other transports length
information may be inferred from the underlying layer.
Normal DTLS does not provide a mechanism for suppressing the sequence
number field entirely. In cases where a sequence number is not
required (e.g., when a reliable transport is in use), a cTLS
implementation may suppress it by setting the
"suppressSequenceNumber" flag in the compression profile being used
(see Section 5.1). When this flag is enabled, the S bit in the
configuration octet MUST be cleared.
3.3. Handshake Layer 3.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:
1. The length field is omitted 1. The length field is omitted
2. The HelloRetryRequest message is a true handshake message instead 2. The HelloRetryRequest message is a true handshake message instead
of a specialization of ServerHello. of a specialization of ServerHello.
skipping to change at page 8, line 4 skipping to change at page 8, line 36
One way of thinking of this is as if specialization is a stateful One way of thinking of this is as if specialization is a stateful
compression layer between the handshake and the record layer: compression layer between the handshake and the record layer:
+---------------+---------------+---------------+ +---------------+---------------+---------------+
| Handshake | Application | Alert | | Handshake | Application | Alert |
+---------------+---------------+---------------+ +---------+ +---------------+---------------+---------------+ +---------+
| cTLS Compression Layer |<---| Profile | | cTLS Compression Layer |<---| Profile |
+---------------+---------------+---------------+ +---------+ +---------------+---------------+---------------+ +---------+
| cTLS Record Layer / Application | | cTLS Record Layer / Application |
+---------------+---------------+---------------+ +---------------+---------------+---------------+
Specializations are defined by a "compression profile" that specifies Specializations are defined by a "compression profile" that specifies
what features are to be optimized out of the handshake. In the what features are to be optimized out of the handshake. In the
following subsections, we define the structure of these profiles, and following subsections, we define the structure of these profiles, and
how they are used in compressing and decompressing handshake how they are used in compressing and decompressing handshake
messages. messages.
[[OPEN ISSUE: Do we want to have an explicit cTLS extension
indicating that cTLS is in use and which specialization is in use?
This goes back to whether we want the use of cTLS to be explicit.]]
5.1. Specifying a Specialization 5.1. Specifying a Specialization
A compression profile defining of a specialized version of TLS is A compression profile defining of a specialized version of TLS is
defined using a JSON dictionary. Each axis of specialization is a defined using a JSON dictionary. Each axis of specialization is a
key in the dictionary. [[OPEN ISSUE: If we ever want to serialize key in the dictionary. [[OPEN ISSUE: If we ever want to serialize
this, we'll want to use a list instead.]]. this, we'll want to use a list instead.]].
For example, the following specialization describes a protocol with a For example, the following specialization describes a protocol with a
single fixed version (TLS 1.3) and a single fixed cipher suite single fixed version (TLS 1.3) and a single fixed cipher suite
(TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites, (TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites,
ServerHello.cipher_suites, and the supported_versions extensions in ServerHello.cipher_suites, and the supported_versions extensions in
the ClientHello and ServerHello would be omitted. the ClientHello and ServerHello would be omitted.
{ {
"profileID": 33,
"version" : 772, "version" : 772,
"cipherSuite" : "TLS_AES_128_GCM_SHA256" "cipherSuite" : "TLS_AES_128_GCM_SHA256"
} }
cTLS allows specialization along the following axes: cTLS allows specialization along the following axes:
profileID (integer): 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.
suppressSequenceNumber (boolean): If present and set to true, the
sequence number field is omitted from encrypted record headers.
version (integer): indicates that both sides agree to the single TLS version (integer): indicates that both sides agree to the single TLS
version specified by the given integer value (772 == 0x0304 for version specified by the given integer value (772 == 0x0304 for
TLS 1.3). The supported_versions extension is omitted from TLS 1.3). The supported_versions extension is omitted from
ClientHello.extensions and reconstructed in the transcript as a ClientHello.extensions and reconstructed in the transcript as a
single-valued list with the specified value. The single-valued list with the specified value. The
supported_versions extension is omitted from supported_versions extension is omitted from
ClientHello.extensions and reconstructed in the transcript with ClientHello.extensions and reconstructed in the transcript with
the specified value. the specified value.
cipherSuite (string): indicates that both sides agree to the single cipherSuite (string): indicates that both sides agree to the single
skipping to change at page 12, line 20 skipping to change at page 13, line 20
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.
6. Examples 6. Examples
The following section provides some example specializations. The following section provides some example specializations.
TLS 1.3 only: TLS 1.3 only:
{ {
"Version" : 0x0304 "version" : 0x0304
} }
TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and
everything else is ordinary TLS 1.3. everything else is ordinary TLS 1.3.
{ {
"Version" : 772, "version" : 772,
"Random": 16, "randomSize": 16,
"CipherSuite" : "TLS_AES_128_GCM_SHA256", "cipherSuite" : "TLS_AES_128_GCM_SHA256",
"DHGroup": "X25519", "dhGroup": "X25519",
"Extensions": { "clientHelloExtensions": {
"named_groups": 29, "named_groups": 29,
"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?]]
skipping to change at page 13, line 11 skipping to change at page 14, line 11
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.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document requests that a code point be allocated from the "TLS
ContentType registry. This value must be in the range 0-31
(inclusive). The row to be added in the registry has the following
form:
+=======+=============+=========+===========+
| Value | Description | DTLS-OK | Reference |
+=======+=============+=========+===========+
| TBD | ctls | N | RFCXXXX |
+-------+-------------+---------+-----------+
Table 2
[[ RFC EDITOR: Please replace the value TBD with the value assigned
by IANA, and the value XXXX to the RFC number assigned for this
document. ]]
[[OPEN ISSUE: Should we require standards action for all profile IDs
that would fit in 2 octets.]]
9. Normative References 9. 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,
skipping to change at page 15, line 29 skipping to change at page 17, line 17
00 // CertificateRequestContext.length 00 // CertificateRequestContext.length
00 // Extensions.length 00 // Extensions.length
0b // Certificate 0b // Certificate
00 // CertificateRequestContext 00 // CertificateRequestContext
03 // CertificateList 03 // CertificateList
01 // CertData.length 01 // CertData.length
61 // CertData = 'a' 61 // CertData = 'a'
00 // Extensions.length 00 // Extensions.length
0f // CertificateVerify 0f // CertificateVerify
0403 // SignatureAlgorithm 0403 // SignatureAlgorithm
4047 3045...10ce // Signature 4047 // Signature.length
3045...f60e // Signature
14 // Finished 14 // Finished
bfc9d66715bb2b04 // VerifyData bfc9d66715bb2b04 // VerifyData
Client Flight: 91 bytes = SIG(71) + MAC(8) + CERTID(1) + Overhead(11) Client Flight: 91 bytes = SIG(71) + MAC(8) + CERTID(1) + Overhead(11)
0b // Certificate 0b // Certificate
00 // CertificateRequestContext 00 // CertificateRequestContext
03 // CertificateList 03 // CertificateList
01 // CertData.length 01 // CertData.length
62 // CertData = 'b' 62 // CertData = 'b'
00 // Extensions.length 00 // Extensions.length
0f // CertificateVerify 0f // CertificateVerify
0403 // SignatureAlgorithm 0403 // SignatureAlgorithm
4047 3045...f60e // Signature.length 4047 // Signature.length
3045...f60e // Signature
14 // Finished 14 // Finished
35e9c34eec2c5dc1 // VerifyData 35e9c34eec2c5dc1 // VerifyData
A.2. PSK A.2. PSK
Compression Profile: Compression Profile:
{ {
"version": 772, "version": 772,
"cipherSuite": "TLS_AES_128_CCM_8_SHA256", "cipherSuite": "TLS_AES_128_CCM_8_SHA256",
 End of changes. 33 change blocks. 
77 lines changed or deleted 130 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/