< draft-rescorla-tls-ctls-01.txt   draft-rescorla-tls-ctls-02.txt >
TLS Working Group E. Rescorla TLS Working Group E. Rescorla
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational March 11, 2019 Intended status: Informational R. Barnes
Expires: September 12, 2019 Expires: January 9, 2020 Cisco
July 08, 2019
Compact TLS 1.3 Compact TLS 1.3
draft-rescorla-tls-ctls-01 draft-rescorla-tls-ctls-02
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 aggressive use of defaults isomorphic to TLS 1.3 but saves space by aggressive use of defaults
and tighter encodings. CTLS is not interoperable with TLS 1.3, but and tighter encodings. CTLS is not interoperable with TLS 1.3, but
it should eventually be possible for the server to distinguish TLS it should eventually be possible for the server to distinguish TLS
1.3 and CTLS handshakes. 1.3 and CTLS handshakes.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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 September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 34
4.5. Certificate . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Certificate . . . . . . . . . . . . . . . . . . . . . . . 8
4.5.1. Key IDs . . . . . . . . . . . . . . . . . . . . . . . 9 4.5.1. Key IDs . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.2. CertificateVerify . . . . . . . . . . . . . . . . . . 9 4.5.2. CertificateVerify . . . . . . . . . . . . . . . . . . 9
4.5.3. Finished . . . . . . . . . . . . . . . . . . . . . . 9 4.5.3. Finished . . . . . . . . . . . . . . . . . . . . . . 9
4.5.4. HelloRetryRequest . . . . . . . . . . . . . . . . . . 10 4.5.4. HelloRetryRequest . . . . . . . . . . . . . . . . . . 10
5. Handshake Size Calculations . . . . . . . . . . . . . . . . . 10 5. Handshake Size Calculations . . . . . . . . . . . . . . . . . 10
5.1. ECDHE w/ Signatures . . . . . . . . . . . . . . . . . . . 10 5.1. ECDHE w/ Signatures . . . . . . . . . . . . . . . . . . . 10
5.1.1. Flight 1 (ClientHello) *** . . . . . . . . . . . . . 10 5.1.1. Flight 1 (ClientHello) *** . . . . . . . . . . . . . 10
5.1.2. Flight 2 (ServerHello..Finished) . . . . . . . . . . 10 5.1.2. Flight 2 (ServerHello..Finished) . . . . . . . . . . 10
5.1.3. Flight 3 (Client Certificate..Finished) . . . . . . . 11 5.1.3. Flight 3 (Client Certificate..Finished) . . . . . . . 11
5.2. ECDHE w/ PSK . . . . . . . . . . . . . . . . . . . . . . 12 6. cTLS as Compression Layer [[OPEN ISSUE]] . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
DDISCLAIMER: 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 two basic techniques: The space reduction is achieved by two basic techniques:
o Default values for common configurations, thus avoiding the need o Default values for common configurations, thus avoiding the need
to take up space on the wire. to take up space on the wire.
o More compact encodings, omitting unnecessary values. o More compact encodings, omitting unnecessary values.
For the common (EC)DHE handshake with (EC)DHE and pre-established For the common (EC)DHE handshake with (EC)DHE and pre-established
public keys, CTLS achieves an overhead of [TODO] bytes over the public keys, CTLS achieves an overhead of [TODO] bytes over the
minimum required by the cryptovariables. minimum required by the cryptovariables.
Although isomorphic, CTLS implementations cannot interoperate with Because cTLS is semantically equivalent to TLS, it can be viewed
TLS 1.3 implementations because the packet formats are non- either as a related protocol or as a compression mechanism.
interoperable. It is probably possible to make a TLS 1.3 server Specifically, it can be implemented by a layer between the TLS
switch-hit between CTLS and TLS 1.3 but this specification does not handshake state machine and the record layer. See Section 6 for more
define how. details.
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
skipping to change at page 10, line 11 skipping to change at page 10, line 11
4.5.3. Finished 4.5.3. Finished
Unchanged. Unchanged.
4.5.4. HelloRetryRequest 4.5.4. HelloRetryRequest
[[TODO]] [[TODO]]
5. Handshake Size Calculations 5. Handshake Size Calculations
This section provides the size of cTLS handshakes with various
parameters [[TODO: Fill this out with more options.]]
5.1. ECDHE w/ Signatures 5.1. ECDHE w/ Signatures
We compute the total flight size with X25519 and P-256 signatures, We compute the total flight size with X25519 and P-256 signatures,
thus the keys are 32-bytes long and the signatures 64 bytes, with a thus the keys are 32-bytes long and the signatures 64 bytes, with a
cipher with an 8 byte auth tag, as in AEAD_AES_128_CCM_8. [Note: GCM cipher with an 8 byte auth tag, as in AEAD_AES_128_CCM_8. [Note: GCM
should not be used with a shortened tag.] Overhead estimates marked should not be used with a shortened tag.] Overhead estimates marked
with *** have been verified with Mint. Others are hand calculations with *** have been verified with Mint. Others are hand calculations
and so may prove to be approximate. and so may prove to be approximate.
5.1.1. Flight 1 (ClientHello) *** 5.1.1. Flight 1 (ClientHello) ***
skipping to change at page 12, line 26 skipping to change at page 12, line 30
o MAC: 32 o MAC: 32
o Handshake Overhead: 2 o Handshake Overhead: 2
o Total: 34 o Total: 34
Record Overhead: 1 byte + 8 bytes (auth tag) Record Overhead: 1 byte + 8 bytes (auth tag)
Total: 113 + X bytes Total: 113 + X bytes
5.2. ECDHE w/ PSK 6. cTLS as Compression Layer [[OPEN ISSUE]]
[TODO] The above text treates cTLS as a new protocol; however it is also
possible to view it as a form of compression for TLS, which sits in
between the handshake layer and the record layer, like so:
6. Security Considerations +---------------+---------------+---------------+
| Handshake | Application | Alert |
+---------------+---------------+---------------+
| cTLS Compression Layer |
+---------------+---------------+---------------+
| cTLS Record Layer |
+---------------+---------------+---------------+
This structure does involve one technical difference: because the
handshake message transformation happens below the handshake layer,
the cTLS handshake transcript would be the same as the TLS 1.3
handshake transcript. This has both advantages and disadvantages.
The major advantage is that it makes it possible to reuse all the TLS
security proofs even with very aggressive compression (with suitable
proofs about the bijectiveness of the compression). [Thanks to
Karthik Bhargavan for this point.] This probably also makes it
easier to implement more aggressive compression. For instance, the
above text shrinks the handshake headers but does not elide them
entirely. If the handshake shape (i.e., which messages are sent) is
known in advance, then these headers can be removed, thus trimming
about 20 bytes from the handshake. This is easier to reason about as
a form of compression. With somewhat aggressive parameters,
including predetermined cipher suites, this technique can bring the
handshake (without record overhead) to:
Client's first flight 48
Server's first flight 164
Client's second flight 116
The major potential disadvantage of a compression approach is that it
makes cTLS and TLS handshakes confusable. For instance, an attacker
who obtained the handshake keys might be able to undetectably
transform a cTLS <-> TLS connection into a TLS <-> TLS connection.
This is easily dealt with by modifying the transcript, e.g., by
injecting a cTLS extension in the transcript (though not into cTLS
wire format).
7. 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, modulo use therefore should provide equivalent security guarantees, modulo use
of new features such as KeyID certificate messages. of new features such as KeyID certificate messages.
One piece that is a new TLS 1.3 feature is the addition of the One piece that is a new TLS 1.3 feature is the addition of the
key_id, which definitely requires some analysis, especially as it key_id, which definitely requires some analysis, especially as it
looks like a potential source of identity misbinding. This is looks like a potential source of identity misbinding. This is
entirely separable from the rest of the specification. entirely separable from the rest of the specification. The
compression version would also need further analysis.
[[OPEN ISSUE: One could imagine internally translating CTLS to TLS
1.3 so that the transcript, etc. were the same, but I doubt it's
worth it, and then you might need to worry about cross-protocol
attacks.]]
7. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
8. 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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Acknowledgments Acknowledgments
TODO acknowledge. TODO acknowledge.
Author's Address Authors' Addresses
Eric Rescorla Eric Rescorla
Mozilla Mozilla
Email: ekr@rtfm.com Email: ekr@rtfm.com
Richard Barnes
Cisco
Email: rlb@ipv.sx
 End of changes. 15 change blocks. 
28 lines changed or deleted 68 lines changed or added

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