idnits 2.17.1 draft-ietf-tls-sni-encryption-02.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 date (March 1, 2018) is 2248 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) == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-09 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-22 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-24 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Standards Track E. Rescorla 5 Expires: September 2, 2018 RTFM, Inc. 6 March 1, 2018 8 SNI Encryption in TLS Through Tunneling 9 draft-ietf-tls-sni-encryption-02 11 Abstract 13 This draft describes the general problem of encryption of the Server 14 Name Identification (SNI) parameter. The proposed solutions hide a 15 Hidden Service behind a Fronting Service, only disclosing the SNI of 16 the Fronting Service to external observers. The draft starts by 17 listing known attacks against SNI encryption, discusses the current 18 "co-tenancy fronting" solution, and then presents two potential TLS 19 layer solutions that might mitigate these attacks. 20 The first solution is based on TLS in TLS "quasi tunneling", and the 21 second solution is based on "combined tickets". These solutions only 22 require minimal extensions to the TLS protocol. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 2, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Security and Privacy Requirements for SNI Encryption . . . . 4 61 2.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 4 62 2.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 4 63 2.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 5 64 2.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 5 65 2.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 5 66 2.6. Proper Security Context . . . . . . . . . . . . . . . . . 5 67 2.7. Fronting Server Spoofing . . . . . . . . . . . . . . . . 6 68 2.8. Supporting multiple protocols . . . . . . . . . . . . . . 6 69 2.8.1. Hiding the Application Layer Protocol Negotiation . . 7 70 2.8.2. Support other transports than HTTP . . . . . . . . . 7 71 2.9. Fail to fronting . . . . . . . . . . . . . . . . . . . . 7 72 3. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 8 73 3.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2. Delegation Token . . . . . . . . . . . . . . . . . . . . 9 75 4. SNI Encapsulation Specification . . . . . . . . . . . . . . . 10 76 4.1. Tunneling TLS in TLS . . . . . . . . . . . . . . . . . . 10 77 4.2. Tunneling design issues . . . . . . . . . . . . . . . . . 12 78 4.2.1. Fronting Server logic . . . . . . . . . . . . . . . . 13 79 4.2.2. Early data . . . . . . . . . . . . . . . . . . . . . 13 80 4.2.3. Client requirements . . . . . . . . . . . . . . . . . 14 81 5. SNI encryption with combined tickets . . . . . . . . . . . . 14 82 5.1. Session resumption with combined tickets . . . . . . . . 14 83 5.2. New Combined Session Ticket . . . . . . . . . . . . . . . 16 84 5.3. First session . . . . . . . . . . . . . . . . . . . . . . 17 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 6.1. Replay attacks and side channels . . . . . . . . . . . . 18 87 6.2. Sticking out . . . . . . . . . . . . . . . . . . . . . . 19 88 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 19 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 9.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 Historically, adversaries have been able to monitor the use of web 99 services through three channels: looking at DNS requests, looking at 100 IP addresses in packet headers, and looking at the data stream 101 between user and services. These channels are getting progressively 102 closed. A growing fraction of Internet communication is encrypted, 103 mostly using Transport Layer Security (TLS) [RFC5246]. Progressive 104 deployment of solutions like DNS in TLS [RFC7858] mitigates the 105 disclosure of DNS information. More and more services are colocated 106 on multiplexed servers, loosening the relation between IP address and 107 web service. However, multiplexed servers rely on the Service Name 108 Information (SNI) to direct TLS connections to the appropriate 109 service implementation. This protocol element is transmitted in 110 clear text. As the other methods of monitoring get blocked, 111 monitoring focuses on the clear text SNI. The purpose of SNI 112 encryption is to prevent that. 114 In the past, there have been multiple attempts at defining SNI 115 encryption. These attempts have generally floundered, because the 116 simple designs fail to mitigate several of the attacks listed in 117 Section 2. In the absence of a TLS level solution, the most popular 118 approach to SNI privacy is HTTP level fronting, which we discuss in 119 Section 3. 121 The current draft proposes two designs for SNI Encryption in TLS. 122 Both designs hide a "Hidden Service" behind a "Fronting Service". To 123 an external observer, the TLS connections will appear to be directed 124 towards the Fronting Service. The cleartext SNI parameter will 125 document the Fronting Service. A second SNI parameter will be 126 transmitted in an encrypted form to the Fronting Service, and will 127 allow that service to redirect the connection towards the Hidden 128 Service. 130 The first design relies on tunneling TLS in TLS, as explained in 131 Section 4. It does not require TLS extensions, but relies on 132 conventions in the implementation of TLS 1.3 [I-D.ietf-tls-tls13] by 133 the Client and the Fronting Server. 135 The second design, presented in Section 5 removes the requirement for 136 tunneling, on simply relies on Combined Tickets. It uses the 137 extension process for session tickets already defined in 138 [I-D.ietf-tls-tls13]. 140 This draft is presented as is to trigger discussions. It is expected 141 that as the draft progresses, only one of the two proposed solutions 142 will be retained. 144 1.1. Key Words 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 2. Security and Privacy Requirements for SNI Encryption 152 Over the past years, there have been multiple proposals to add an SNI 153 encryption option in TLS. Many of these proposals appeared 154 promising, but were rejected after security reviews pointed plausible 155 attacks. In this section, we collect a list of these known attacks. 157 2.1. Mitigate Replay Attacks 159 The simplest SNI encryption designs replace in the initial TLS 160 exchange the clear text SNI with an encrypted value, using a key 161 known to the multiplexed server. Regardless of the encryption used, 162 these designs can be broken by a simple replay attack, which works as 163 follow: 165 1- The user starts a TLS connection to the multiplexed server, 166 including an encrypted SNI value. 168 2- The adversary observes the exchange and copies the encrypted SNI 169 parameter. 171 3- The adversary starts its own connection to the multiplexed server, 172 including in its connection parameters the encrypted SNI copied from 173 the observed exchange. 175 4- The multiplexed server establishes the connection to the protected 176 service, thus revealing the identity of the service. 178 One of the goals of SNI encryption is to prevent adversaries from 179 knowing which Hidden Service the client is using. Successful replay 180 attacks breaks that goal by allowing adversaries to discover that 181 service. 183 2.2. Avoid Widely Shared Secrets 185 It is easy to think of simple schemes in which the SNI is encrypted 186 or hashed using a shared secret. This symmetric key must be known by 187 the multiplexed server, and by every users of the protected services. 188 Such schemes are thus very fragile, since the compromise of a single 189 user would compromise the entire set of users and protected services. 191 2.3. Prevent SNI-based Denial of Service Attacks 193 Encrypting the SNI may create extra load for the multiplexed server. 194 Adversaries may mount denial of service attacks by generating random 195 encrypted SNI values and forcing the multiplexed server to spend 196 resources in useless decryption attempts. 198 It may be argued that this is not an important DOS avenue, as regular 199 TLS connection attempts also require the server to perform a number 200 of cryptographic operations. However, in many cases, the SNI 201 decryption will have to be performed by a front end component with 202 limited resources, while the TLS operations are performed by the 203 component dedicated to their respective services. SNI based DOS 204 attacks could target the front end component. 206 2.4. Do not stick out 208 In some designs, handshakes using SNI encryption can be easily 209 differentiated from "regular" handshakes. For example, some designs 210 require specific extensions in the Client Hello packets, or specific 211 values of the clear text SNI parameter. If adversaries can easily 212 detect the use of SNI encryption, they could block it, or they could 213 flag the users of SNI encryption for special treatment. 215 In the future, it might be possible to assume that a large fraction 216 of TLS handshakes use SNI encryption. If that was the case, the 217 detection of SNI encryption would be a lesser concern. However, we 218 have to assume that in the near future, only a small fraction of TLS 219 connections will use SNI encryption. 221 2.5. Forward Secrecy 223 The general concerns about forward secrecy apply to SNI encryption 224 just as well as to regular TLS sessions. For example, some proposed 225 designs rely on a public key of the multiplexed server to define the 226 SNI encryption key. If the corresponding private key was 227 compromised, the adversaries would be able to process archival 228 records of past connections, and retrieve the protected SNI used in 229 these connections. These designs failed to maintain forward secrecy 230 of SNI encryption. 232 2.6. Proper Security Context 234 We can design solutions in which the multiplexed server or a fronting 235 service act as a relay to reach the protected service. Some of those 236 solutions involve just one TLS handshake between the client and the 237 multiplexed server, or between the client and the fronting service. 239 The master secret is verified by verifying a certificate provided by 240 either of these entities, but not by the protected service. 242 These solutions expose the client to a Man-In-The-Middle attack by 243 the multiplexed server or by the fronting service. Even if the 244 client has some reasonable trust in these services, the possibility 245 of MITM attack is troubling. 247 The multiplexed server or the fronting services could be pressured by 248 adversaries. By design, they could be forced to deny access to the 249 protected service, or to divulge which client accessed it. But if 250 MITM is possible, the adversaries would also be able to pressure them 251 into intercepting or spoofing the communications between client and 252 protected service. 254 2.7. Fronting Server Spoofing 256 Adversaries could mount an attack by spoofing the Fronting Service. 257 A spoofed Fronting Service could act as a "honeypot" for users of 258 hidden services. At a minimum, the fake server could record the IP 259 addresses of these users. If the SNI encryption solution places too 260 much trust on the fronting server, the fake server could also serve 261 fake content of its own choosing, including various forms of malware. 263 There are two main channels by which adversaries can conduct this 264 attack. Adversaries can simply try to mislead users into believing 265 that the honeypot is a valid Fronting Server, especially if that 266 information is carried by word of mouth or in unprotected DNS 267 records. Adversaries can also attempt to hijack the traffic to the 268 regular Fronting Server, using for example spoofed DNS responses or 269 spoofed IP level routing, combined with a spoofed certificate. 271 2.8. Supporting multiple protocols 273 The SNI encryption requirement do not stop with HTTP over TLS. 274 Multiple other applications currently use TLS, including for example 275 SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. These applications 276 too will benefit of SNI encryption. HTTP only methods like those 277 described in Section 3.1 would not apply there. In fact, even for 278 the HTTPS case, the HTTPS tunneling service described in Section 3.1 279 is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly 280 with the multiple streams feature of HTTP 2.0 [RFC7540]. This points 281 to the need of an application agnostic solution, that would be 282 implemented fully in the TLS layer. 284 2.8.1. Hiding the Application Layer Protocol Negotiation 286 The Application Layer Protocol Negotiation (ALPN) parameters of TLS 287 allow implementations to negotiate the application layer protocol 288 used on a given connection. TLS provides the ALPN values in clear 289 text during the initial handshake. While exposing the ALPN does not 290 create the same privacy issues as exposing the SNI, there is still a 291 risk. For example, some networks may attempt to block applications 292 that they do not understand, or that they wish users would not use. 294 In a sense, ALPN filtering could be very similar to the filtering of 295 specific port numbers exposed in some network. This filtering by 296 ports has given rise to evasion tactics in which various protocols 297 are tunneled over HTTP in order to use open ports 80 or 443. 298 Filtering by ALPN would probably beget the same responses, in which 299 the applications just move over HTTP, and only the HTTP ALPN values 300 are used. Applications would not need to do that if the ALPN was 301 hidden in the same way as the SNI. 303 It is thus desirable that SNI Encryption mechanisms be also able hide 304 the ALPN. 306 2.8.2. Support other transports than HTTP 308 The TLS handshake is also used over other transports such as UDP with 309 both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls]. The 310 requirement to encrypt the SNI apply just as well for these 311 transports as for TLS over TCP. 313 This points to a requirement for SNI Encryption mechanisms to also be 314 applicable to non-TCP transports such as DTLS or QUIC. 316 2.9. Fail to fronting 318 It is easy to imagine designs in which the client sends some client 319 hello extension that points to a secret shared by client and hidden 320 server. If that secret is incorporated into the handshake secret, 321 the exchange will only succeeds if the connection truly ends at the 322 hidden server. The exchange will fail if the extension is stripped 323 by an MITM, and the exchange will also fail if an adversary replays 324 the extension in a Client Hello. 326 The problem with that approach is clear. Adversaries that replay the 327 extension can test whether the client truly wanted to access the 328 fronting server, or was simply using that fronting server as an 329 access gateway to something else. The adversaries will not know what 330 hidden service the client was trying to reach, but they can guess. 332 They can also start directly interrogate the user, or other 333 unpleasant alternatives. 335 When designing SNI encryption schemes, we have to take into account 336 attacks that strip parameters from the Client Hello, or replay 337 attacks. In both cases, the desired behavior is to fall back to a 338 connection with the fronting server, so there is no visble difference 339 between a regular connection to that server and an atempt to reach 340 the hidden server. 342 3. HTTP Co-Tenancy Fronting 344 In the absence of TLS level SNI encryption, many sites rely on an 345 "HTTP Co-Tenancy" solution. The TLS connection is established with 346 the fronting server, and HTTP requests are then sent over that 347 connection to the hidden service. For example, the TLS SNI could be 348 set to "fronting.example.com", the fronting server, and HTTP requests 349 sent over that connection could be directed to "hidden.example.com/ 350 some-content", accessing the hidden service. This solution works 351 well in practice when the fronting server and the hidden server are 352 'co-tenant" of the same multiplexed server. 354 The HTTP fronting solution can be deployed without modification to 355 the TLS protocol, and does not require using and specific version of 356 TLS. There are however a few issues regarding discovery, client 357 implementations, trust, and applicability: 359 o The client has to discover that the hidden service can be accessed 360 through the fronting server. 362 o The client browser's has to be directed to access the hidden 363 service through the fronting service. 365 o Since the TLS connection is established with the fronting service, 366 the client has no proof that the content does in fact come from 367 the hidden service. The solution does thus not mitigate the 368 context sharing issues described in Section 2.6. 370 o Since this is an HTTP level solution, it would not protected non 371 HTTP protocols such as DNS over TLS [RFC7858] or IMAP over TLS 372 [RFC2595]. 374 The discovery issue is common to pretty much every SNI encryption 375 solution, and is also discussed in Section 4.2.3 and Section 5.3. 376 The browser issue may be solved by developing a browser extension 377 that support HTTP Fronting, and manages the list of fronting services 378 associated with the hidden services that the client uses. The multi- 379 protocol issue can be mitigated by using implementation of other 380 applications over HTTP, such as for example DNS over HTTPS 381 [I-D.hoffman-dns-over-https]. The trust issue, however, requires 382 specific developments. 384 3.1. HTTPS Tunnels 386 The HTTP Fronting solution places a lot of trust in the Fronting 387 Server. This required trust can be reduced by tunnelling HTTPS in 388 HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. 389 In this solution, the client establishes a TLS connection to the 390 Fronting Server, and then issues an HTTP Connect request to the 391 Hidden Server. This will establish an end-to-end HTTPS over TLS 392 connection between the client and the Hidden Server, mitigating the 393 issues described in Section 2.6. 395 The HTTPS in HTTPS solution requires double encryption of every 396 packet. It also requires that the fronting server decrypts and relay 397 messages to the hidden server. Both of these requirements make the 398 implementation onerous. 400 3.2. Delegation Token 402 Clients would see their privacy compromised if they contacted the 403 wrong fronting server to access the hidden service, since this wrong 404 server could disclose their access to adversaries. This can possibly 405 be mitigated by recording the relation between fronting server and 406 hidden server in a Delegation Token. 408 The delegation token would be a form of certificate, signed by the 409 hidden service. It would have the following components: 411 o The DNS name of the fronting service 413 o TTL (i.e. expiration date) 415 o An indication of the type of access that would be used, such as 416 direct fronting in which the hidden content is directly served by 417 the fronting server, or HTTPS in HTTPS, or one of the TLS level 418 solutions discussed in Section 4 and Section 5 420 o Triple authentication, to make the barrier to setting up a 421 honeypot extremely high 423 1. Cert chain for hidden server certificate (e.g., 424 hidden.example.com) up to CA. 426 2. Certificate transparency proof of the hidden service 427 certificate (hidden.example.com) from a popular log, with a 428 requirement that the browser checks the proof before 429 connecting. 431 3. A TLSA record for hidden service domain name 432 (hidden.example.com), with full DNSSEC chain (also mandatory 433 to check) 435 o Possibly, a list of valid addresses of the fronting service. 437 o Some extension mechanism for other bits 439 If N multiple domains on a CDN are acceptable fronts, then we may 440 want some way to indicate this without publishing and maintaining N 441 separate tokens. 443 Delegation tokens could be published by the fronting server, in 444 response for example to a specific query by a client. The client 445 would then examine whether one of the Delegation Tokens matches the 446 hidden service that it wants to access. 448 QUESTION: Do we need a revocation mechanism? What if a fronting 449 service obtains a delegation token, and then becomes untrustable for 450 some other reason? Or is it sufficient to just use short TTL? 452 4. SNI Encapsulation Specification 454 We propose to provide SNI Privacy by using a form of TLS 455 encapsulation. The big advantage of this design compared to previous 456 attempts is that it requires effectively no changes to TLS 1.3. It 457 only requires a way to signal to the Fronting Server server that the 458 encrypted application data is actually a ClientHello which is 459 intended for the hidden service. Once the tunneled session is 460 established, encrypted packets will be forwarded to the Hidden 461 Service without requiring encryption or decryption by the Fronting 462 Service. 464 4.1. Tunneling TLS in TLS 466 The proposed design is to encapsulate a second Client Hello in the 467 early data of a TLS connection to the Fronting Service. To the 468 outside, it just appears that the client is resuming a session with 469 the fronting service. 471 Client Fronting Service Hidden Service 472 ClientHello 473 + early_data 474 + key_share* 475 + psk_key_exchange_modes 476 + pre_shared_key 477 + SNI = fronting 478 ( 479 //Application data 480 ClientHello#2 481 + KeyShare 482 + signature_algorithms* 483 + psk_key_exchange_modes* 484 + pre_shared_key* 485 + SNI = hidden 486 ) 487 --------> 488 ClientHello#2 489 + KeyShare 490 + signature_algorithms* 491 + psk_key_exchange_modes* 492 + pre_shared_key* 493 + SNI = hidden ----> 495 496 --------------------> 497 ServerHello 498 + pre_shared_key 499 + key_share* 500 {EncryptedExtensions} 501 {CertificateRequest*} 502 {Certificate*} 503 {CertificateVerify*} 504 {Finished} 505 <-------------------- 506 {Certificate*} 507 {CertificateVerify*} 508 {Finished} --------------------- 510 [Application Data] <-------------------> [Application Data] 512 Key to brackets: 514 * optional messages, not present in all scenarios 515 () encrypted with Client->Fronting 0-RTT key 516 <> encrypted with Client->Hidden 0-RTT key 517 {} encrypted with Client->Hidden 1-RTT handshake 518 [] encrypted with Client->Hidden 1-RTT key 520 The way this works is that the Fronting Server decrypts the _data_ in 521 the client's first flight, which is actually ClientHello#2 from the 522 client, containing the true SNI and then passes it on to the Hidden 523 server. However, the Hidden Server responds with its own ServerHello 524 which the Fronting Server just passes unchanged, because it's 525 actually the response to ClientHello#2 rather than to ClientHello#1. 526 As long as ClientHello#1 and ClientHello#2 are similar (e.g., 527 differing only in the client's actual share (though of course it must 528 be in the same group)), SNI, and maybe EarlyDataIndication), then an 529 attacker should not be able to distinguish these cases -- although 530 there may be possible attacks through timing analysis, or by 531 observing traffic between the Fronting Server and Hidden Server if 532 they are not colocated. 534 4.2. Tunneling design issues 536 The big advantage of this design is that it requires effectively no 537 changes to TLS. It only requires a way to signal to the Fronting 538 Server that the encrypted application data is actually a ClientHello 539 which is intended for the hidden service. 541 The major disadvantage of this overall design strategy (however it's 542 signaled) is that it's somewhat harder to implement in the co- 543 tenanted cases than the simple schemes that carry the "real SNI" in 544 an encrypted parameter of the Client Hello. That means that it's 545 somewhat less likely that servers will implement it "by default" and 546 more likely that they will have to take explicit effort to allow 547 Encrypted SNI. Conversely, however, these schemes (aside from a 548 server with a single wildcard or multi-SAN cert) involve more changes 549 to TLS to deal with issues like "what is the server cert that is 550 digested into the keys", and that requires more analysis, so there is 551 an advantage to deferring that. If we have EncryptedExtensions in 552 the client's first flight it would be possible to define a "Real SNI" 553 extension later if/when we had clearer analysis for that case. 555 Notes on several obvious technical issues: 557 1. How does the Fronting Server distinguish this case from where the 558 initial flight is actual application data? See Section 4.2.1 for 559 some thoughts on this. 561 2. Can we make this work with 0-RTT data from the client to the 562 Hidden server? The answer is probably yes, as discussed in 563 Section 4.2.2. 565 3. What happens if the Fronting Server doesn't gateway, e.g., 566 because it has forgotten the ServerConfiguration? In that case, 567 the client gets a handshake with the Fronting Server, which it 568 will have to determine via trial decryption. At this point the 569 Fronting Server supplies a ServerConfiguration and the client can 570 reconnect as above. 572 4. What happens if the client does 0-RTT inside 0-RTT (as in #2 573 above) and the Hidden server doesn't recognize the 574 ServerConfiguration in ClientHello#2? In this case, the client 575 gets a 0-RTT rejection and it needs to do trial decryption to 576 know whether the rejection was from the Fronting Server or the 577 Hidden server. 579 5. What happens if the Fronting Server is under a DOS attack, and 580 chooses to refuse all 0-RTT data? 582 The client part of that logic, including the handling of question #3 583 above, is discussed in Section 4.2.3. 585 4.2.1. Fronting Server logic 587 The big advantage of this design is that it requires effectively no 588 changes to TLS. It only requires a way to signal to the Fronting 589 Server that the encrypted application data is actually a ClientHello 590 which is intended for the hidden service. The two most obvious 591 designs are: 593 o Have an EncryptedExtension which indicates that the inner data is 594 tunnelled. 596 o Have a "tunnelled" TLS content type. 598 EncryptedExtensions would be the most natural, but they were removed 599 from the ClientHello during the TLS standardization. In Section 4.1 600 we assume that the second ClientHello is just transmitted as 0-RTT 601 data, and that the servers use some form of pattern matching to 602 differentiate between this second ClientHello and other application 603 messages. 605 4.2.2. Early data 607 In the proposed design, the second ClientHello is sent to the 608 Fronting Server as early data, encrypted with Client->Fronting 0-RTT 609 key. If the Client follows the second ClientHello with 0-RTT data, 610 that data could in theory be sent in two ways: 612 1. The client could use double encryption. The data is first 613 encrypted with the Client->Hidden 0-RTT key, then wrapped and 614 encrypted with the Client->Fronting 0-RTT key. The Fronting 615 server would decrypt, unwrap and relay. 617 2. The client could just encrypt the data with the Client->Hidden 618 0-RTT key, and ask the server to blindly relay it. 620 Each of these ways has its issues. The double encryption scenario 621 would require two end of early data messages, one double encrypted 622 and relayed by the Fronting Server to the Hidden Server, and another 623 sent from Client to Fronting Server, to delimit the end of the double 624 encrypted stream, and also to ensure that the stream of messages is 625 not distinguishable from simply sending 0-RTT data to the Fronting 626 server. The blind relaying is simpler, and is the scenario described 627 in the diagram of Section 4.1. In that scenario, the Fronting server 628 switches to relaying mode immediately after unwrapping and forwarding 629 the second ClientHello. However, the blind relaying requires the 630 ClientHello to be isolated to a single record. 632 4.2.3. Client requirements 634 In order to use the tunneling service, the client needs to identify 635 the Fronting Service willing to tunnel to the Hidden Service. We can 636 assume that the client will learn the identity of suitable Fronting 637 Services from the Hidden Service itself. 639 In order to tunnel the second ClientHello as 0-RTT data, the client 640 needs to have a shared secret with the Fronting Service. To avoid 641 the trap of "well known shared secrets" described in Section 2.2, 642 this should be a pair wise secret. The most practical solution is to 643 use a session resumption ticket. This requires that prior to the 644 tunneling attempt, the client establishes regular connections with 645 the fronting service and obtains one or several session resumption 646 tickets. 648 5. SNI encryption with combined tickets 650 EDITOR'S NOTE: This section is an alternative design to Section 4. 651 As the draft progresses, only one of the alternatives will be 652 selected, and the text corresponding to the other alternative will be 653 deleted. 655 We propose to provide SNI Privacy by relying solely on "combined 656 tickets". The big advantage of this design compared to previous 657 attempts is that it requires only minimal changes to implementations 658 of TLS 1.3. These changes are confined to the handling of the 659 combined ticket by Fronting and Hidden service, and to the signaling 660 of the Fronting SNI to the client by the Hidden service. 662 5.1. Session resumption with combined tickets 664 In this example, the client obtains a combined session resumption 665 ticket during a previous connection to the hidden service, and has 666 learned the SNI of the fronting service. The session resumption will 667 happen as follows: 669 Client Fronting Service Hidden Service 670 ClientHello 671 + early_data 672 + key_share* 673 + psk_key_exchange_modes 674 + pre_shared_key 675 + SNI = fronting 676 --------> 677 // Decode the ticket 678 // Forwards to hidden 679 ClientHello -------> 681 (Application Data*) ----------------------> 682 ServerHello 683 + pre_shared_key 684 + key_share* 685 {EncryptedExtensions} 686 + early_data* 687 {Finished} 688 <---------------------- [Application Data] 689 (EndOfEarlyData) 690 {Finished} ----------------------> 692 [Application Data] <---------------------> [Application Data] 694 + Indicates noteworthy extensions sent in the 695 previously noted message. 696 * Indicates optional or situation-dependent 697 messages/extensions that are not always sent. 698 () encrypted with Client->Hidden 0-RTT key 699 {} encrypted with Client->Hidden 1-RTT handshake 700 [] encrypted with Client->Hidden 1-RTT key 702 The Fronting server that receives the Client Hello will find the 703 combined ticket in the pre_shared_key extensions, just as it would in 704 a regular session resumption attempt. When parsing the ticket, the 705 Fronting server will discover that the session really is meant to be 706 resumed with the Hidden server. It will arrange for all the 707 connection data to be forwarded to the Hidden server, including 708 forwarding a copy of the initial Client Hello. 710 The Hidden server will receive the Client Hello. It will obtain the 711 identity of the Fronting service from the SNI parameter. It will 712 then parse the session resumption ticket, and proceed with the 713 resumption of the session. 715 In this design, the Client Hello message is relayed unchanged from 716 Fronting server to hidden server. This ensures that code changes are 717 confined to the interpretation of the message parameters. The 718 construction of handshake contexts is left unchanged. 720 5.2. New Combined Session Ticket 722 In normal TLS 1.3 operations, the server can send New Session Ticket 723 messages at any time after the receiving the Client Finished message. 724 The ticket structure is defined in TLS 1.3 as: 726 struct { 727 uint32 ticket_lifetime; 728 uint32 ticket_age_add; 729 opaque ticket_nonce<1..255>; 730 opaque ticket<1..2^16-1>; 731 Extension extensions<0..2^16-2>; 732 } NewSessionTicket; 734 When SNI encryption is enabled, tickets will carry a "Fronting SNI" 735 extension, and the ticket value itself will be negotiated between 736 Fronting Service and Hidden Service, as in: 738 Client Fronting Service Hidden Service 740 <======= 741 Combined Ticket =======> 742 [New Session Ticket 743 <------------------------ + SNI Extension] 745 <==> sent on connection between Hidden and Fronting service 746 <> encrypted with Fronting<->Hidden key 747 [] encrypted with Client->Hidden 1-RTT key 749 In theory, the actual format of the ticket could be set by mutual 750 agreement between Fronting Service and Hidden Service. In practice, 751 it is probably better to provide guidance, as the ticket must meet 752 three requirements: 754 o The Fronting Server must understand enough of the combined ticket 755 to relay the connection towards the Hidden Server; 757 o The Hidden Server must understand enough of the combined ticket to 758 resume the session with the client; 760 o Third parties must not be able to deduce the name of the Hidden 761 Service from the value of the ticket. 763 There are three plausible designs, a stateful design, a shared key 764 design, and a 765 In the stateful design, the ticket are just random numbers that the 766 Fronting server associates with the Hidden server, and the Hidden 767 server associates with the session context. The shared key design 768 would work as follow: 770 o the hidden server and the fronting server share a symmetric key 771 K_sni. 773 o the "clear text" ticket includes a nonce, the ordinary ticket used 774 for session resumption by the hidden service, and the id of the 775 Hidden service for the Fronting Service. 777 o the ticket will be encrypted with AEAD, using the nonce as an IV. 779 o When the client reconnects to the fronting server, it decrypts the 780 ticket using K_sni and if it succeeds, then it just forwards the 781 Client Hello to the hidden server indicated in id-hidden-service 782 (which of course has to know to ignore SNI). Otherwise, it 783 terminates the connection itself with its own SNI. 785 The hidden server can just refresh the ticket any time it pleases, as 786 usual. 788 This design allows the Hidden Service to hide behind many Fronting 789 Services, each using a different key. The Client Hello received by 790 the Hidden Server carries the SNI of the Fronting Service, which the 791 Hidden Server can use to select the appropriate K_sni. 793 In the public key design, the Hidden Server encrypts the tickets with 794 a public key of the Fronting Server. The ticket itself would be 795 similar to what is used in the shared key design. The compute cost 796 for a single decryption may be higher, but the Fronting Server would 797 not need to blindly try multiple decryption keys associated with 798 multiple Hidden Servers. The Hidden Server would not be able to 799 decrypt the ession Tickets, which means that it would have to rely on 800 some kind of stateful storage. 802 5.3. First session 804 The previous sections present how sessions can be resumed with the 805 combined ticket. Clients have that have never contacted the Hidden 806 Server will need to obtain a first ticket during a first session. 807 The most plausible option is to have the client directly connect to 808 the Hidden Service, and then ask for a combined ticket. The obvious 809 issue is that the SNI will not be encrypted for this first 810 connection, which exposes the client to surveillance and censorship. 812 The client may also learn about the relation between Fronting Service 813 and Hidden Service through an out of band channel, such as DNS 814 service, or word of mouth. However, it is difficult to establish a 815 combined ticket completely out of band, since the ticket must be 816 associated to two shared secrets, one understood by the Fronting 817 service and the other shared with the Hidden service to ensure 818 protection against replay attacks. 820 An alternative may be to use the TLS-in-TLS service described in 821 Section 4.1 for the first contact. There will be some overhead due 822 to tunnelling, but as we discussed in Section 4.2.3 the tunneling 823 solution allows for safe first contact. Yet another way would be to 824 use the HTTPS in HTTPS tunneling described in Section 3.1. 826 6. Security Considerations 828 The encapsulation protocol proposed in this draft mitigates the known 829 attacks listed in Section 2. For example, the encapsulation design 830 uses pairwise security contexts, and is not dependent on the widely 831 shared secrets described in Section 2.2. The design also does not 832 rely on additional public key operations by the multiplexed server or 833 by the fronting server, and thus does not open the attack surface for 834 denial of service discussed in Section 2.3. The session keys are 835 negotiated end to end between the client and the protected service, 836 as required in Section 2.6. 838 The combined ticket solution also mitigates the known attacks. The 839 design also uses pairwise security contexts, and is not dependent on 840 the widely shared secrets described in Section 2.2. The design also 841 does not rely on additional public key operations by the multiplexed 842 server or by the fronting server, and thus does not open the attack 843 surface for denial of service discussed in Section 2.3. The session 844 keys are negotiated end to end between the client and the protected 845 service, as required in Section 2.6. 847 However, in some cases, proper mitigation depends on careful 848 implementation. 850 6.1. Replay attacks and side channels 852 Both solutions mitigate the replay attacks described in Section 2.1 853 because adversaries cannot decrypt the replies intended for the 854 client. However, the connection from the fronting service to the 855 hidden service can be observed through side channels. 857 To give an obvious example, suppose that the fronting service merely 858 relays the data by establishing a TCP connection to the hidden 859 service. An adversary capable of observing all network traffic at 860 the fronting server can associate the arrival of an encrypted message 861 to the fronting service and the TCP handshake between the fronting 862 server and the hidden service, and deduce which hidden service the 863 user accessed. 865 The mitigation of this attack relies on proper implementation of the 866 fronting service. This may require cooperation from the multiplexed 867 server. 869 6.2. Sticking out 871 The TLS encapsulation protocol mostly fulfills the requirements to 872 "not stick out" expressed in Section 2.4. The initial messages will 873 be sent as 0-RTT data, and will be encrypted using the 0-RTT key 874 negotiated with the fronting service. Adversaries cannot tell 875 whether the client is using TLS encapsulation or some other 0-RTT 876 service. However, this is only true if the fronting service 877 regularly uses 0-RTT data. 879 The combined token solution almost perfectly fulfills the 880 requirements to "not stick out" expressed in Section 2.4, as the 881 observable flow of message is almost exactly the same as a regular 882 TLS connection. However, adversaries could observe the values of the 883 PSK Identifier that contains the combined ticket. The proposed 884 ticket structure is designed to thwart analysis of the ticket, but if 885 implementations are not careful the size of the combined ticket can 886 be used as a side channel allowing adversaries to distinguish between 887 different Hidden Services located behind the same Fronting Service. 889 6.3. Forward Secrecy 891 In the TLS encapsulation protocol, the encapsulated Client Hello is 892 encrypted using the session resumption key. If this key is revealed, 893 the Client Hello data will also be revealed. The mitigation there is 894 to not use the same session resumption key multiple time. 896 The most common implementations of TLS tickets have the server using 897 Session Ticket Encryption Keys (STEKs) to create an encrypted copy of 898 the session parameters which is then stored by the client. When the 899 client resumes, it supplies this encrypted copy, the server decrypts 900 it, and has the parameters it needs to resume. The server need only 901 remember the STEK. If a STEK is disclosed to an adversary, then all 902 of the data encrypted by sessions protected by the STEK may be 903 decrypted by an adversary. 905 To mitigate this attack, server implementations of the combined 906 ticket protocol SHOULD use stateful tickets instead of STEK protected 907 TLS tickets. If they do rely on STEK protected tickets, they MUST 908 ensure that the K_sni keys used to encrypt these tickets are rotated 909 frequently. 911 7. IANA Considerations 913 Do we need to register an extension point? Or is it just OK to use 914 early data? 916 8. Acknowledgements 918 A large part of this draft originates in discussion of SNI encryption 919 on the TLS WG mailing list, including comments after the tunneling 920 approach was first proposed in a message to that list: 921 . 924 During the discussion of SNI Encryption in Yokohama, Deb Cooley 925 argued that rather than messing with TLS to allow SNI encryption, we 926 should just tunnel TLS in TLS. A number of people objected to this 927 on the grounds of the performance cost for the Fronting Server 928 because it has to encrypt and decrypt everything. 930 After the meeting, Martin Thomson suggested a modification to the 931 tunnelling proposal that removes this cost. The key observation is 932 that if we think of the 0-RTT flight as a separate message attached 933 to the handshake, then we can tunnel a second first flight in it. 935 The combined ticket approach was first proposed by Cedric Fournet and 936 Antoine Delignaut-Lavaud. 938 The delegation token design comes from many people, including Ben 939 Schwartz, Brian Sniffen and Rich Salz. 941 Thanks to Daniel Kahn Gillmor for a pretty detailed review of the 942 initial draft. 944 9. References 946 9.1. Normative References 948 [I-D.ietf-quic-tls] 949 Thomson, M. and S. Turner, "Using Transport Layer Security 950 (TLS) to Secure QUIC", draft-ietf-quic-tls-09 (work in 951 progress), January 2018. 953 [I-D.ietf-tls-dtls13] 954 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 955 Datagram Transport Layer Security (DTLS) Protocol Version 956 1.3", draft-ietf-tls-dtls13-22 (work in progress), 957 November 2017. 959 [I-D.ietf-tls-tls13] 960 Rescorla, E., "The Transport Layer Security (TLS) Protocol 961 Version 1.3", draft-ietf-tls-tls13-24 (work in progress), 962 February 2018. 964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 965 Requirement Levels", BCP 14, RFC 2119, 966 DOI 10.17487/RFC2119, March 1997, 967 . 969 9.2. Informative References 971 [I-D.hoffman-dns-over-https] 972 Hoffman, P. and P. McManus, "DNS Queries over HTTPS", 973 draft-hoffman-dns-over-https-01 (work in progress), June 974 2017. 976 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 977 RFC 2595, DOI 10.17487/RFC2595, June 1999, 978 . 980 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 981 (TLS) Protocol Version 1.2", RFC 5246, 982 DOI 10.17487/RFC5246, August 2008, 983 . 985 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 986 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 987 DOI 10.17487/RFC7540, May 2015, 988 . 990 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 991 Security (TLS) in the Extensible Messaging and Presence 992 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 993 2015, . 995 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 996 and P. Hoffman, "Specification for DNS over Transport 997 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 998 2016, . 1000 Authors' Addresses 1002 Christian Huitema 1003 Private Octopus Inc. 1004 Friday Harbor WA 98250 1005 U.S.A 1007 Email: huitema@huitema.net 1009 Eric Rescorla 1010 RTFM, Inc. 1011 U.S.A 1013 Email: ekr@rtfm.com