TCP Use TLS Option
draft-rescorla-tcpinc-tls-option-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Eric Rescorla | ||
| Last updated | 2014-07-03 | ||
| Replaced by | draft-ietf-tcpinc-use-tls | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rescorla-tcpinc-tls-option-00
TCPING E. Rescorla
Internet-Draft Mozilla
Intended status: Standards Track July 3, 2014
Expires: January 4, 2015
TCP Use TLS Option
draft-rescorla-tcpinc-tls-option-00
Abstract
This document defines a TCP option (TCP-TLS) to indicate that TLS
should be negotiated on a given TCP connection.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Rescorla Expires January 4, 2015 [Page 1]
Internet-Draft TCP/TLS Opt July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
4. Transport Integrity . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Options . . . . . . . . . . . . . . . . . . . . 6
6. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. NAT/Firewall considerations . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Rescorla Expires January 4, 2015 [Page 2]
Internet-Draft TCP/TLS Opt July 2014
1. Introduction
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub. Suggested changes should be submitted
as pull requests at https://github.com/ekr/tcpinc-tls. Instructions
are on that page as well.
The TCPINC WG is chartered to define protocols to provide ubiquitous,
transparent security for TCP connections.
While TLS [RFC5246] is by far the most popular mechanism for securing
TCP data, adding it to a given protocol requires some sort of
coordination; if a client just tries to initiate TLS with a non-TLS
server, the server will most likely reject the protocol messages
because they do not conform to its expectations for the application
layer protocol. This coordination can take a number of forms,
including:
o An external signal in the URL that the client should do TLS (e.g.,
"https:")
o Using a separate port for the secure and non-secure versions of
the protocol.
o An extension to the application protocol to negotiate use or non-
use of TLS ("STARTTLS")
While mechanisms of this type are in wide use, they all require
modifications to the application layer and thus do not meet the goals
of TCPINC. This document describes a TCP option which allows a pair
of communicating TCP endpoints to negotiate TLS use automatically
without modifying the application layer protocols, thus allowing for
transparent deployment.
2. Overview
The basic idea behind the TCP-TLS option is simple. The SYN and SYN/
ACK messages carry TCP options indicating the willingness to do TLS
and some basic information about the expected TLS modes. If both
sides want to do TLS and have compatible modes, then the application
data is automatically TLS protected prior to being sent over TCP.
Otherwise, the application data is sent as usual.
Rescorla Expires January 4, 2015 [Page 3]
Internet-Draft TCP/TLS Opt July 2014
Client Server
SYN + TCP-TLS ->
<- SYN/ACK + TCP/TLS
ACK ->
<---------------- TLS Handshake --------------->
<--------- Application Data over TLS ---------->
Figure 1: Negotiating TLS with TCP-TLS
Client Server
SYN + TCP-TLS ->
<- SYN/ACK
ACK ->
<--------- Application Data over TLS ---------->
Figure 2: Fall back to TCP
If use of TLS is negotiated, the data sent over TCP simply is TLS
data in compliance with {{RFC5246}.
3. Extension Definition
The TCP-TLS option is very simple.
+------------+------------+------------+------------+
| Kind=XX | Length | Reserved |
+------------+------------+------------+------------+
| Tiebreaker |
+---------------------------------------------------+
The reserved field MUST be all 0s and is present for alignment. The
tiebreaker field is a 64-bit value which is used to determine the TLS
roles, with the highest value being the TLS client and the lowest
value being the TLS server.
o In client/server applications, the active opener MUST set its
tiebreaker value to all 1s (the maximum value) and the passive
opener MUST set its tiebreaker to all 0s (the minimum value), thus
ensuring that the TLS roles line up with the traditional TLS over
TCP roles.
o In applications which may use simultaneous opens, each side SHOULD
randomly generate its tiebreaker value.
If both sides generate the same tiebreaker value, then TCP-TLS MUST
Rescorla Expires January 4, 2015 [Page 4]
Internet-Draft TCP/TLS Opt July 2014
NOT be used (this has a vanishing probability of happening by
accident.)
If an endpoint sends the TCP-TLS option and receives it from the
other side, it shall immediately negotiate TLS, taking on the role
indicated by the tiebreaker value.
Once the TLS handshake has completed, all application data SHALL be
sent over that negotiated TLS channel. Application data MUST NOT be
sent prior to the TLS handshake.
If the TLS handshake fails for non-cryptographic reasons such as
failure to negotiate a compatible cipher or the like, endpoints
SHOULD behave as if the the TCP-TLS option was not present. This is
obviously not the conventional behavior for TLS failure, but as the
entire idea here is to be opportunistic and the attacker can simply
suppress the TCP-TLS option entirely, this provides the maximum
robustness against broken intermediaries. If the TLS handshake fails
for cryptographic reasons that indicate damage to the datastream
(e.g., a decryption failure or a Finished failure) then the endpoints
SHOULD signal a connection failure, as this suggests that there is a
middlebox modifying the data and there is a reasonable chance that
the state is now corrupted.
4. Transport Integrity
The basic operational mode defined by TCP-TLS protects only the
application layer content, but not the TCP segment metadata. Upon
receiving a packet, implementations MUST first check the TCP checksum
and discard corrupt packets without presenting them to TLS. If the
TCP checksum passes but TLS integrity fails, the connection MUST be
torn down.
Thus, TCP-TLS provides automatic security for the content, but not
protection against DoS-style attacks. For instance, attackers will
be able to inject RST packets, bogus application segments, etc.,
regardless of whether TLS authentication is used. Because the
application data is TLS protected, this will not result in the
application receiving bogus data, but it will constitute a DoS on the
connection.
This attack can be countered by using TCP-TLS in combination with
TCP-AO [RFC5925], as follows:
1. The TLS connection is negotiated using the "tcpao" ALPN
[I-D.ietf-tls-applayerprotoneg] indicator.
Rescorla Expires January 4, 2015 [Page 5]
Internet-Draft TCP/TLS Opt July 2014
2. Upon TLS handshake completion, a TLS Exporter [RFC5705] is used
to generate keying material of appropriate length using exporter
label TBD.
3. Further packets are protected using TCP-AO with the generated
keys.
The Finished messages MUST NOT be protected with AO. The first
application data afterwards MUST be protected with AO. Note that
because of retransmission, non-AO packets may be received after AO
has been engaged; they MUST be ignored.
[[OPEN ISSUE: How do we negotiate the parameters? Do we need a
use_ao option like with RFC 5764? Is ALPN really what we want
here?]]
[[TODO: verify that the state machine matches up here.]]
5. Implementation Options
There are two primary implementation options for TCP-TLS:
o Implement all of TCP-TLS in the operating system kernel.
o Implement just the TCP-TLS negotiation option in the operating
system kernel with an interface to tell the application that TCP-
TLS has been negotiated and therefore that the application must
negotiate TLS.
The former option obviously achieves easier deployment for
applications, which don't have to do anything, but is more effort for
kernel developers and requires a wider interface to the kernel to
configure the TLS stack. The latter option is inherently more
flexible but does not provide as immediate transparent deployment.
It is also possible for systems to offer both options.
6. TLS Profile
Implementations of this specification MUST at minimum support TLS 1.2
[RFC5246] and MUST support cipher suite XXX. Implementations MUST
NOT negotiate versions of TLS prior to TLS 1.2. [[OPEN ISSUE: What
cipher suites? Presumably we require one authenticated and one
anonymous cipher suite, all with GCM.]] [[OPEN ISSUE: If TLS 1.3 is
ready, we may want to require that.]]
Rescorla Expires January 4, 2015 [Page 6]
Internet-Draft TCP/TLS Opt July 2014
7. NAT/Firewall considerations
If use of TLS is negotiated, the data sent over TCP simply is TLS
data in compliance with {{RFC5246}. Thus it is extremely likely to
pass through NATs, firewalls, etc. The only kind of middlebox that
is likely to cause a problem is one which does protocol enforcement
that blocks TLS on arbitrary (non-443) ports but _also_ passes
unknown TCP options. Although no doubt such devices do exist,
because this is a common scenario, a client machine should be able to
probe to determine if it is behind such a device relatively readily.
8. IANA Considerations
IANA [shall register/has registered] the TCP option XX for TCP-TLS.
IANA [shall register/has registered] the ALPN code point "tcpao" to
indicate the use of TCP-TLS with TCP-AO.
9. Security Considerations
The mechanisms in this document are inherently vulnerable to active
attack because an attacker can remove the TCP-TLS option. Thus, even
when TCP-AO is used, all that is being provided is continuity of
authentication from the initial handshake. If some sort of external
authentication mechanism was provided or certificates are used, then
you might get some protection against active attack.
10. References
10.1. Normative References
[I-D.ietf-tls-applayerprotoneg] Friedl, S., Popov, A., Langley, A.,
and S. Emile, "Transport Layer
Security (TLS) Application Layer
Protocol Negotiation Extension",
draft-ietf-tls-applayerprotoneg-05
(work in progress), March 2014.
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246,
August 2008.
Rescorla Expires January 4, 2015 [Page 7]
Internet-Draft TCP/TLS Opt July 2014
[RFC5705] Rescorla, E., "Keying Material
Exporters for Transport Layer
Security (TLS)", RFC 5705,
March 2010.
[RFC5925] Touch, J., Mankin, A., and R.
Bonica, "The TCP Authentication
Option", RFC 5925, June 2010.
10.2. Informative References
[I-D.bittau-tcp-crypt] Bittau, A., Boneh, D., Hamburg, M.,
Handley, M., Mazieres, D., and Q.
Slack, "Cryptographic protection of
TCP Streams (tcpcrypt)",
draft-bittau-tcp-crypt-04 (work in
progress), February 2014.
Author's Address
Eric Rescorla
Mozilla
EMail: ekr@rtfm.com
Rescorla Expires January 4, 2015 [Page 8]