idnits 2.17.1 draft-rescorla-tcpinc-tls-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 3, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'I-D.bittau-tcp-crypt' is defined on line 303, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPING E. Rescorla 3 Internet-Draft Mozilla 4 Intended status: Standards Track July 3, 2014 5 Expires: January 4, 2015 7 TCP Use TLS Option 8 draft-rescorla-tcpinc-tls-option-00 10 Abstract 12 This document defines a TCP option (TCP-TLS) to indicate that TLS 13 should be negotiated on a given TCP connection. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 4, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4 52 4. Transport Integrity . . . . . . . . . . . . . . . . . . . . . . 5 53 5. Implementation Options . . . . . . . . . . . . . . . . . . . . 6 54 6. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 7. NAT/Firewall considerations . . . . . . . . . . . . . . . . . . 7 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 60 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 65 draft is maintained in GitHub. Suggested changes should be submitted 66 as pull requests at https://github.com/ekr/tcpinc-tls. Instructions 67 are on that page as well. 69 The TCPINC WG is chartered to define protocols to provide ubiquitous, 70 transparent security for TCP connections. 72 While TLS [RFC5246] is by far the most popular mechanism for securing 73 TCP data, adding it to a given protocol requires some sort of 74 coordination; if a client just tries to initiate TLS with a non-TLS 75 server, the server will most likely reject the protocol messages 76 because they do not conform to its expectations for the application 77 layer protocol. This coordination can take a number of forms, 78 including: 80 o An external signal in the URL that the client should do TLS (e.g., 81 "https:") 83 o Using a separate port for the secure and non-secure versions of 84 the protocol. 86 o An extension to the application protocol to negotiate use or non- 87 use of TLS ("STARTTLS") 89 While mechanisms of this type are in wide use, they all require 90 modifications to the application layer and thus do not meet the goals 91 of TCPINC. This document describes a TCP option which allows a pair 92 of communicating TCP endpoints to negotiate TLS use automatically 93 without modifying the application layer protocols, thus allowing for 94 transparent deployment. 96 2. Overview 98 The basic idea behind the TCP-TLS option is simple. The SYN and SYN/ 99 ACK messages carry TCP options indicating the willingness to do TLS 100 and some basic information about the expected TLS modes. If both 101 sides want to do TLS and have compatible modes, then the application 102 data is automatically TLS protected prior to being sent over TCP. 103 Otherwise, the application data is sent as usual. 105 Client Server 107 SYN + TCP-TLS -> 108 <- SYN/ACK + TCP/TLS 109 ACK -> 110 <---------------- TLS Handshake ---------------> 111 <--------- Application Data over TLS ----------> 113 Figure 1: Negotiating TLS with TCP-TLS 115 Client Server 117 SYN + TCP-TLS -> 118 <- SYN/ACK 119 ACK -> 120 <--------- Application Data over TLS ----------> 122 Figure 2: Fall back to TCP 124 If use of TLS is negotiated, the data sent over TCP simply is TLS 125 data in compliance with {{RFC5246}. 127 3. Extension Definition 129 The TCP-TLS option is very simple. 131 +------------+------------+------------+------------+ 132 | Kind=XX | Length | Reserved | 133 +------------+------------+------------+------------+ 134 | Tiebreaker | 135 +---------------------------------------------------+ 137 The reserved field MUST be all 0s and is present for alignment. The 138 tiebreaker field is a 64-bit value which is used to determine the TLS 139 roles, with the highest value being the TLS client and the lowest 140 value being the TLS server. 142 o In client/server applications, the active opener MUST set its 143 tiebreaker value to all 1s (the maximum value) and the passive 144 opener MUST set its tiebreaker to all 0s (the minimum value), thus 145 ensuring that the TLS roles line up with the traditional TLS over 146 TCP roles. 148 o In applications which may use simultaneous opens, each side SHOULD 149 randomly generate its tiebreaker value. 151 If both sides generate the same tiebreaker value, then TCP-TLS MUST 152 NOT be used (this has a vanishing probability of happening by 153 accident.) 155 If an endpoint sends the TCP-TLS option and receives it from the 156 other side, it shall immediately negotiate TLS, taking on the role 157 indicated by the tiebreaker value. 159 Once the TLS handshake has completed, all application data SHALL be 160 sent over that negotiated TLS channel. Application data MUST NOT be 161 sent prior to the TLS handshake. 163 If the TLS handshake fails for non-cryptographic reasons such as 164 failure to negotiate a compatible cipher or the like, endpoints 165 SHOULD behave as if the the TCP-TLS option was not present. This is 166 obviously not the conventional behavior for TLS failure, but as the 167 entire idea here is to be opportunistic and the attacker can simply 168 suppress the TCP-TLS option entirely, this provides the maximum 169 robustness against broken intermediaries. If the TLS handshake fails 170 for cryptographic reasons that indicate damage to the datastream 171 (e.g., a decryption failure or a Finished failure) then the endpoints 172 SHOULD signal a connection failure, as this suggests that there is a 173 middlebox modifying the data and there is a reasonable chance that 174 the state is now corrupted. 176 4. Transport Integrity 178 The basic operational mode defined by TCP-TLS protects only the 179 application layer content, but not the TCP segment metadata. Upon 180 receiving a packet, implementations MUST first check the TCP checksum 181 and discard corrupt packets without presenting them to TLS. If the 182 TCP checksum passes but TLS integrity fails, the connection MUST be 183 torn down. 185 Thus, TCP-TLS provides automatic security for the content, but not 186 protection against DoS-style attacks. For instance, attackers will 187 be able to inject RST packets, bogus application segments, etc., 188 regardless of whether TLS authentication is used. Because the 189 application data is TLS protected, this will not result in the 190 application receiving bogus data, but it will constitute a DoS on the 191 connection. 193 This attack can be countered by using TCP-TLS in combination with 194 TCP-AO [RFC5925], as follows: 196 1. The TLS connection is negotiated using the "tcpao" ALPN 197 [I-D.ietf-tls-applayerprotoneg] indicator. 199 2. Upon TLS handshake completion, a TLS Exporter [RFC5705] is used 200 to generate keying material of appropriate length using exporter 201 label TBD. 203 3. Further packets are protected using TCP-AO with the generated 204 keys. 206 The Finished messages MUST NOT be protected with AO. The first 207 application data afterwards MUST be protected with AO. Note that 208 because of retransmission, non-AO packets may be received after AO 209 has been engaged; they MUST be ignored. 211 [[OPEN ISSUE: How do we negotiate the parameters? Do we need a 212 use_ao option like with RFC 5764? Is ALPN really what we want 213 here?]] 215 [[TODO: verify that the state machine matches up here.]] 217 5. Implementation Options 219 There are two primary implementation options for TCP-TLS: 221 o Implement all of TCP-TLS in the operating system kernel. 223 o Implement just the TCP-TLS negotiation option in the operating 224 system kernel with an interface to tell the application that TCP- 225 TLS has been negotiated and therefore that the application must 226 negotiate TLS. 228 The former option obviously achieves easier deployment for 229 applications, which don't have to do anything, but is more effort for 230 kernel developers and requires a wider interface to the kernel to 231 configure the TLS stack. The latter option is inherently more 232 flexible but does not provide as immediate transparent deployment. 233 It is also possible for systems to offer both options. 235 6. TLS Profile 237 Implementations of this specification MUST at minimum support TLS 1.2 238 [RFC5246] and MUST support cipher suite XXX. Implementations MUST 239 NOT negotiate versions of TLS prior to TLS 1.2. [[OPEN ISSUE: What 240 cipher suites? Presumably we require one authenticated and one 241 anonymous cipher suite, all with GCM.]] [[OPEN ISSUE: If TLS 1.3 is 242 ready, we may want to require that.]] 244 7. NAT/Firewall considerations 246 If use of TLS is negotiated, the data sent over TCP simply is TLS 247 data in compliance with {{RFC5246}. Thus it is extremely likely to 248 pass through NATs, firewalls, etc. The only kind of middlebox that 249 is likely to cause a problem is one which does protocol enforcement 250 that blocks TLS on arbitrary (non-443) ports but _also_ passes 251 unknown TCP options. Although no doubt such devices do exist, 252 because this is a common scenario, a client machine should be able to 253 probe to determine if it is behind such a device relatively readily. 255 8. IANA Considerations 257 IANA [shall register/has registered] the TCP option XX for TCP-TLS. 259 IANA [shall register/has registered] the ALPN code point "tcpao" to 260 indicate the use of TCP-TLS with TCP-AO. 262 9. Security Considerations 264 The mechanisms in this document are inherently vulnerable to active 265 attack because an attacker can remove the TCP-TLS option. Thus, even 266 when TCP-AO is used, all that is being provided is continuity of 267 authentication from the initial handshake. If some sort of external 268 authentication mechanism was provided or certificates are used, then 269 you might get some protection against active attack. 271 10. References 273 10.1. Normative References 275 [I-D.ietf-tls-applayerprotoneg] Friedl, S., Popov, A., Langley, A., 276 and S. Emile, "Transport Layer 277 Security (TLS) Application Layer 278 Protocol Negotiation Extension", 279 draft-ietf-tls-applayerprotoneg-05 280 (work in progress), March 2014. 282 [RFC2119] Bradner, S., "Key words for use in 283 RFCs to Indicate Requirement 284 Levels", BCP 14, RFC 2119, 285 March 1997. 287 [RFC5246] Dierks, T. and E. Rescorla, "The 288 Transport Layer Security (TLS) 289 Protocol Version 1.2", RFC 5246, 290 August 2008. 292 [RFC5705] Rescorla, E., "Keying Material 293 Exporters for Transport Layer 294 Security (TLS)", RFC 5705, 295 March 2010. 297 [RFC5925] Touch, J., Mankin, A., and R. 298 Bonica, "The TCP Authentication 299 Option", RFC 5925, June 2010. 301 10.2. Informative References 303 [I-D.bittau-tcp-crypt] Bittau, A., Boneh, D., Hamburg, M., 304 Handley, M., Mazieres, D., and Q. 305 Slack, "Cryptographic protection of 306 TCP Streams (tcpcrypt)", 307 draft-bittau-tcp-crypt-04 (work in 308 progress), February 2014. 310 Author's Address 312 Eric Rescorla 313 Mozilla 315 EMail: ekr@rtfm.com