idnits 2.17.1 draft-huitema-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 (July 3, 2017) is 2489 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 (-28) exists of draft-ietf-tls-tls13-20 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: January 4, 2018 RTFM, Inc. 6 July 3, 2017 8 SNI Encryption in TLS Through Tunneling 9 draft-huitema-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 http://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 January 4, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 6 67 2.7. Fronting Server Spoofing . . . . . . . . . . . . . . . . 6 68 3. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 7 69 3.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2. Delegation Token . . . . . . . . . . . . . . . . . . . . 8 71 4. SNI Encapsulation Specification . . . . . . . . . . . . . . . 9 72 4.1. Tunneling TLS in TLS . . . . . . . . . . . . . . . . . . 9 73 4.2. Tunneling design issues . . . . . . . . . . . . . . . . . 12 74 4.2.1. Gateway logic . . . . . . . . . . . . . . . . . . . . 13 75 4.2.2. Early data . . . . . . . . . . . . . . . . . . . . . 13 76 4.2.3. Client requirements . . . . . . . . . . . . . . . . . 14 77 5. SNI encryption with combined tickets . . . . . . . . . . . . 14 78 5.1. Session resumption with combined tickets . . . . . . . . 14 79 5.2. New Combined Session Ticket . . . . . . . . . . . . . . . 16 80 5.3. First session . . . . . . . . . . . . . . . . . . . . . . 18 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 6.1. Replay attacks and side channels . . . . . . . . . . . . 19 83 6.2. Sticking out . . . . . . . . . . . . . . . . . . . . . . 20 84 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 89 9.2. Informative References . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 Historically, adversaries have been able to monitor the use of web 95 services through three channels: looking at DNS requests, looking at 96 IP addresses in packet headers, and looking at the data stream 97 between user and services. These channels are getting progressively 98 closed. A growing fraction of Internet communication is encrypted, 99 mostly using Transport Layer Security (TLS) [RFC5246]. Progressive 100 deployment of solutions like DNS in TLS [RFC7858] mitigates the 101 disclosure of DNS information. More and more services are colocated 102 on multiplexed servers, loosening the relation between IP address and 103 web service. However, multiplexed servers rely on the Service Name 104 Information (SNI) to direct TLS connections to the appropriate 105 service implementation. This protocol element is transmitted in 106 clear text. As the other methods of monitoring get blocked, 107 monitoring focuses on the clear text SNI. The purpose of SNI 108 encryption is to prevent that. 110 In the past, there have been multiple attempts at defining SNI 111 encryption. These attempts have generally floundered, because the 112 simple designs fail to mitigate several of the attacks listed in 113 Section 2. In the absence of a TLS level solution, the most popular 114 approach to SNI privacy is HTTP level fronting, which we discuss in 115 Section 3. 117 The current draft proposes two designs for SNI Encryption in TLS. 118 Both designs hide a "Hidden Service" behind a "Fronting Service". To 119 an external observer, the TLS connections will appear to be directed 120 towards the Fronting Service. The cleartext SNI parameter will 121 document the Fronting Service. A second SNI parameter will be 122 transmitted in an encrypted form to the Fronting Service, and will 123 allow that service to redirect the connection towards the Hidden 124 Service. 126 The first design relies on tunneling TLS in TLS, as explained in 127 Section 4. It does not require TLS extensions, but relies on 128 conventions in the implementation of TLS 1.3 [I-D.ietf-tls-tls13] by 129 the Client and the Fronting Server. 131 The second design, presented in Section 5 removes the requirement for 132 tunneling, on simply relies on Combined Tickets. It uses the 133 extension process for session tickets already defined in 134 [I-D.ietf-tls-tls13]. 136 This draft is presented as is to trigger discussions. It is expected 137 that as the draft progresses, only one of the two proposed solutions 138 will be retained. 140 1.1. Key Words 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 2. Security and Privacy Requirements for SNI Encryption 148 Over the past years, there have been multiple proposals to add an SNI 149 encryption option in TLS. Many of these proposals appeared 150 promising, but were rejected after security reviews pointed plausible 151 attacks. In this section, we collect a list of these known attacks. 153 2.1. Mitigate Replay Attacks 155 The simplest SNI encryption designs replace in the initial TLS 156 exchange the clear text SNI with an encrypted value, using a key 157 known to the multiplexed server. Regardless of the encryption used, 158 these designs can be broken by a simple replay attack, which works as 159 follow: 161 1- The user starts a TLS connection to the multiplexed server, 162 including an encrypted SNI value. 164 2- The adversary observes the exchange and copies the encrypted SNI 165 parameter. 167 3- The adversary starts its own connection to the multiplexed server, 168 including in its connection parameters the encrypted SNI copied from 169 the observed exchange. 171 4- The multiplexed server establishes the connection to the protected 172 service, thus revealing the identity of the service. 174 One of the goals of SNI encryption is to prevent adversaries from 175 knowing which Hidden Service the client is using. Successful replay 176 attacks breaks that goal by allowing adversaries to discover that 177 service. 179 SNI encryption designs MUST mitigate this attack. 181 2.2. Avoid Widely Shared Secrets 183 It is easy to think of simple schemes in which the SNI is encrypted 184 or hashed using a shared secret. This symmetric key must be known by 185 the multiplexed server, and by every users of the protected services. 186 Such schemes are thus very fragile, since the compromise of a single 187 user would compromise the entire set of users and protected services. 189 SNI encryption designs MUST NOT rely on widely shared secrets. 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 SNI encryption designs MUST mitigate the risk of denial of service 207 attacks through forced SNI decryption. 209 2.4. Do not stick out 211 In some designs, handshakes using SNI encryption can be easily 212 differentiated from "regular" handshakes. For example, some designs 213 require specific extensions in the Client Hello packets, or specific 214 values of the clear text SNI parameter. If adversaries can easily 215 detect the use of SNI encryption, they could block it, or they could 216 flag the users of SNI encryption for special treatment. 218 In the future, it might be possible to assume that a large fraction 219 of TLS handshakes use SNI encryption. If that was the case, the 220 detection of SNI encryption would be a lesser concern. However, we 221 have to assume that in the near future, only a small fraction of TLS 222 connections will use SNI encryption. 224 SNI encryption designs MUST minimize the observable differences 225 between the TLS handshakes that use SNI encryption and those that 226 don't. 228 2.5. Forward Secrecy 230 The general concerns about forward secrecy apply to SNI encryption 231 just as well as to regular TLS sessions. For example, some proposed 232 designs rely on a public key of the multiplexed server to define the 233 SNI encryption key. If the corresponding public key was compromised, 234 the adversaries would be able to process archival records of past 235 connections, and retrieve the protected SNI used in these 236 connections. These designs failed to maintain forward secrecy of SNI 237 encryption. 239 SNI encryption designs SHOULD provide forward secrecy for the 240 protected SNI. However, this may be very hard to achieve in 241 practice. Designs MAY compromise there, if they have other good 242 properties. 244 2.6. Proper Security Context 246 We can design solutions in which the multiplexed server or a fronting 247 service act as a relay to reach the protected service. Some of those 248 solutions involve just one TLS handshake between the client and the 249 multiplexed server, or between the client and the fronting service. 250 The master secret is verified by verifying a certificate provided by 251 either of these entities, but not by the protected service. 253 These solutions expose the client to a Man-In-The-Middle attack by 254 the multiplexed server or by the fronting service. Even if the 255 client has some reasonable trust in these services, the possibility 256 of MITM attack is troubling. 258 The multiplexed server or the fronting services could be pressured by 259 adversaries. By design, they could be forced to deny access to the 260 protected service, or to divulge which client accessed it. But if 261 MITM is possible, the adversaries would also be able to pressure them 262 into intercepting or spoofing the communications between client and 263 protected service. 265 SNI encryption designs MUST ensure that the master secret are 266 negotiated and verified "end to end", between client and protected 267 service. 269 2.7. Fronting Server Spoofing 271 Adversaries could mount an attack by spoofing the Fronting Service. 272 A spoofed Fronting Service could act as a "honeypot" for users of 273 hidden services. At a minimum, the fake server could record the IP 274 addresses of these users. If the SNI encryption solution places too 275 much trust on the fronting server, the fake server could also serve 276 fake content of its own choosing, including various forms of malware. 278 There are two main channels by which adversaries can conduct this 279 attack. Adversaries can simply try to mislead users into believing 280 that the honeypot is a valid Fronting Server, especially if that 281 information is carried by word of mouth or in unprotected DNS 282 records. Adversaries can also attempt to hijack the traffic to the 283 regular Fronting Server, using for example spoofed DNS responses or 284 spoofed IP level routing, combined with a spoofed certificate. 286 To mitigate this class of attacks, SNI encryption implementations 287 MUST ensure that the Fronting Servers are properly authenticated, and 288 SHOULD ensure that the relation between Hidden Services and Fronting 289 Services is obtained in a trustworthy manner. 291 3. HTTP Co-Tenancy Fronting 293 In the absence of TLS level SNI encryption, many sites rely on an 294 "HTTP Co-Tenancy" solution. The TLS connection is established with 295 the fronting server, and HTTP requests are then sent over that 296 connection to the hidden service. For example, the TLS SNI could be 297 set to "fronting.example.com", the fronting server, and HTTP requests 298 sent over that connection could be directed to "hidden.example.com/ 299 some-content", accessing the hidden service. This solution works 300 well in practice when the fronting server and the hidden server are 301 'co-tenant" of the same multiplexed server. 303 The HTTP fronting solution can be deployed without modification to 304 the TLS protocol, and does not require using and specific version of 305 TLS. There are however a few issues regarding discovery, client 306 implementations, trust, and applicability: 308 o The client has to discover that the hidden service can be accessed 309 through the fronting server. 311 o The client browser's has to be directed to access the hidden 312 service through the fronting service. 314 o Since the TLS connection is established with the fronting service, 315 the client has no proof that the content does in fact come from 316 the hidden service. The solution does thus not mitigate the 317 context sharing issues described in Section 2.6. 319 o Since this is an HTTP level solution, it would not protected non 320 HTTP protocols such as DNS over TLS [RFC7858] or IMAP over TLS 321 [RFC2595]. 323 The discovery issue is common to pretty much every SNI encryption 324 solution, and is also discussed in Section 4.2.3 and Section 5.3. 325 The browser issue may be solved by developing a browser extension 326 that support HTTP Fronting, and manages the list of fronting services 327 associated with the hidden services that the client uses. The multi- 328 protocol issue can be mitigated by using implementation of other 329 applications over HTTP, such as for example DNS over HTTPS 330 [I-D.hoffman-dns-over-https]. The trust issue, however, requires 331 specific developments such as HTTP tunnels or Delegation Tokens. 333 3.1. HTTPS Tunnels 335 The HTTP Fronting solution places a lot of trust in the Fronting 336 Server. This required trust can be reduced by tunnelling HTTPS in 337 HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. 338 In this solution, the client establishes a TLS connection to the 339 Fronting Server, and then issues an HTTP Connect request to the 340 Hidden Server. This will establish an end-to-end HTTPS over TLS 341 connection between the client and the Hidden Server, mitigating the 342 issues described in Section 2.6. 344 The HTTPS in HTTPS solution requires double encryption of every 345 packet. It also requires that the fronting server decrypts and relay 346 messages to the hidden server. Both of these requirements make the 347 implementation onerous. 349 3.2. Delegation Token 351 Clients would see their privacy compromised if they contacted the 352 wrong fronting server to access the hidden service, since this wrong 353 server could disclose their access to adversaries. This can possibly 354 be mitigated by recording the relation between fronting server and 355 hidden server in a Delegation Token. 357 The delegation token would be a form of certificate, signed by the 358 hidden service. It would have the following components: 360 o The DNS name of the fronting service 362 o TTL (i.e. expiration date) 364 o An indication of the type of access that would be used, such as 365 direct fronting in which the hidden content is directly served by 366 the fronting server, or HTTPS in HTTPS, or one of the TLS level 367 solutions discussed in Section 4 and Section 5 369 o Triple authentication, to make the barrier to setting up a 370 honeypot extremely high 372 1. Cert chain for hidden server certificate (e.g., 373 hidden.example.com) up to CA. 375 2. Certificate transparency proof of the hidden service 376 certificate (hidden.example.com) from a popular log, with a 377 requirement that the browser checks the proof before 378 connecting. 380 3. A TLSA record for hidden service domain name 381 (hidden.example.com), with full DNSSEC chain (also mandatory 382 to check) 384 o Possibly, a list of valid addresses of the fronting service. 386 o Some extension mechanism for other bits 388 If N multiple domains on a CDN are acceptable fronts, then we may 389 want some way to indicate this without publishing and maintaining N 390 separate tokens. 392 Delegation tokens could be published by the fronting server, in 393 response for example to a specific query by a client. The client 394 would then examine whether one of the Delegation Tokens matches the 395 hidden service that it wants to access. 397 QUESTION: Do we need a revocation mechanism? What if a fronting 398 service obtains a delegation token, and then becomes untrustable for 399 some other reason? Or is it sufficient to just use short TTL? 401 4. SNI Encapsulation Specification 403 We propose to provide SNI Privacy by using a form of TLS 404 encapsulation. The big advantage of this design compared to previous 405 attempts is that it requires effectively no changes to TLS 1.3. It 406 only requires a way to signal to the Gateway server that the 407 encrypted application data is actually a ClientHello which is 408 intended for the hidden service. Once the tunneled session is 409 established, encrypted packets will be forwarded to the Hidden 410 Service without requiring encryption or decryption by the Fronting 411 Service. 413 4.1. Tunneling TLS in TLS 415 The proposed design is to encapsulate a second Client Hello in the 416 early data of a TLS connection to the Fronting Service. To the 417 outside, it just appears that the client is resuming a session with 418 the fronting service. 420 Client Fronting Service Hidden Service 422 ClientHello 424 + early_data 426 + key_share* 427 + psk_key_exchange_modes 429 + pre_shared_key 431 + SNI = fronting 433 ( 435 //Application data 437 ClientHello#2 439 + KeyShare 441 + signature_algorithms* 443 + psk_key_exchange_modes* 445 + pre_shared_key* 447 + SNI = hidden 449 ) 451 --------> 453 ClientHello#2 455 + KeyShare 457 + signature_algorithms* 459 + psk_key_exchange_modes* 461 + pre_shared_key* 463 + SNI = hidden ----> 465 467 --------------------> 469 ServerHello 471 + pre_shared_key 472 + key_share* 474 {EncryptedExtensions} 476 {CertificateRequest*} 478 {Certificate*} 480 {CertificateVerify*} 482 {Finished} 484 <-------------------- 486 {Certificate*} 488 {CertificateVerify*} 490 {Finished} --------------------- 492 [Application Data] <-------------------> [Application Data] 494 Key to brackets: 496 * optional messages, not present in all scenarios 498 () encrypted with Client->Fronting 0-RTT key 500 <> encrypted with Client->Hidden 0-RTT key 502 {} encrypted with Client->Hidden 1-RTT handshake 504 [] encrypted with Client->Hidden 1-RTT key 506 The way this works is that the Gateway decrypts the _data_ in the 507 client's first flight, which is actually ClientHello#2 from the 508 client, containing the true SNI and then passes it on to the Hidden 509 server. However, the Hidden server responds with its own ServerHello 510 which the Gateway just passes unchanged, because it's actually the 511 response to ClientHello#2 rather than to ClientHello#1. As long as 512 ClientHello#1 and ClientHello#2 are similar (e.g., differing only in 513 the client's actual share (though of course it must be in the same 514 group)), SNI, and maybe EarlyDataIndication), then an attacker should 515 not be able to distinguish these cases. 517 4.2. Tunneling design issues 519 The big advantage of this design is that it requires effectively no 520 changes to TLS. It only requires a way to signal to the Fronting 521 Server that the encrypted application data is actually a ClientHello 522 which is intended for the hidden service. 524 The major disadvantage of this overall design strategy (however it's 525 signaled) is that it's somewhat harder to implement in the co- 526 tenanted cases than the most trivial "RealSNI" scheme. That means 527 that it's somewhat less likely that servers will implement it "by 528 default" and more likely that they will have to take explicit effort 529 to allow Encrypted SNI. Conversely, however, these modes (aside from 530 a server with a single wildcard or multi-SAN cert) involve more 531 changes to TLS to deal with issues like "what is the server cert that 532 is digested into the keys", and that requires more analysis, so there 533 is an advantage to deferring that. If we have EncryptedExtensions in 534 the client's first flight it would be possible to add RealSNI later 535 if/when we had clearer analysis for that case. 537 Notes on several obvious technical issues: 539 1. How does the Fronting Server distinguish this case from where the 540 initial flight is actual application data? See Section 4.2.1 for 541 some thoughts on this. 543 2. Can we make this work with 0-RTT data from the client to the 544 Hidden server? The answer is probably yes, as discussed in 545 Section 4.2.2. 547 3. What happens if the Fronting Server doesn't gateway, e.g., 548 because it has forgotten the ServerConfiguration? In that case, 549 the client gets a handshake with the Gateway, which it will have 550 to determine via trial decryption. At this point the Gateway 551 supplies a ServerConfiguration and the client can reconnect as 552 above. 554 4. What happens if the client does 0-RTT inside 0-RTT (as in #2 555 above) and the Hidden server doesn't recognize the 556 ServerConfiguration in ClientHello#2? In this case, the client 557 gets a 0-RTT rejection and it needs to do trial decryption to 558 know whether the rejection was from the Gateway or the Hidden 559 server. 561 The client part of that logic, including the handling of question #3 562 above, is discussed in Section 4.2.3. 564 4.2.1. Gateway logic 566 The big advantage of this design is that it requires effectively no 567 changes to TLS. It only requires a way to signal to the Fronting 568 Server that the encrypted application data is actually a ClientHello 569 which is intended for the hidden service. The two most obvious 570 designs are: 572 o Have an EncryptedExtension which indicates that the inner data is 573 tunnelled. 575 o Have a "tunnelled" TLS content type. 577 EncryptedExtensions would be the most natural, but they were removed 578 from the ClientHello during the TLS standardization. In Section 4.1 579 we assume that the second ClientHello is just transmitted as 0-RTT 580 data, and that the servers use some form of pattern matching to 581 differentiate between this second ClientHello and other application 582 messages. 584 4.2.2. Early data 586 In the proposed design, the second ClientHello is sent to the 587 Fronting Server as early data, encrypted with Client->Fronting 0-RTT 588 key. If the Client follows the second ClientHello with 0-RTT data, 589 that data could in theory be sent in two ways: 591 1. The client could use double encryption. The data is first 592 encrypted with the Client->Hidden 0-RTT key, then wrapped and 593 encrypted with the Client->Fronting 0-RTT key. The Fronting 594 server would decrypt, unwrap and relay. 596 2. The client could just encrypt the data with the Client->Hidden 597 0-RTT key, and ask the server to blindly relay it. 599 Each of these ways has its issues. The double encryption scenario 600 would requires two end of early data messages, one double encrypted 601 and relayed by the Fronting Server to the Hidden Server, and another 602 sent from Client to Fronting Server, to delimitate the end of these 603 double encrypted stream, and also to ensure that the stream of 604 messages is not distinguishable from simply sending 0-RTT data to the 605 Fronting server. The blind relaying is simpler, and is the scenario 606 described in the diagram of Section 4.1. In that scenario, the 607 Fronting server switches to relaying mode immediately after 608 unwrapping and forwarding the second ClientHello. 610 4.2.3. Client requirements 612 In order to use the tunneling service, the client needs to identify 613 the Fronting Service willing to tunnel to the Hidden Service. We can 614 assume that the client will learn the identity of suitable Fronting 615 Services from the Hidden Service itself. 617 In order to tunnel the second ClientHello as 0-RTT data, the client 618 needs to have a shared secret with the Fronting Service. To avoid 619 the trap of "well known shared secrets" described in Section 2.2, 620 this should be a pair wise secret. The most practical solution is to 621 use a session resumption ticket. This requires that prior to the 622 tunneling attempt, the client establishes regular connections with 623 the fronting service and obtains one or several session resumption 624 tickets. 626 5. SNI encryption with combined tickets 628 EDITOR'S NOTE: This section is an alternative design to Section 4. 629 As the draft progresses, only one of the alternatives will be 630 selected, and the text corresponding to the other alternative will be 631 deleted. 633 We propose to provide SNI Privacy by relying solely on "combined 634 tickets". The big advantage of this design compared to previous 635 attempts is that it requires only minimal changes to implementations 636 of TLS 1.3. These changes are confined to the handling of the 637 combined ticket by Fronting and Hidden service, and to the signaling 638 of the Fronting SNI to the client by the Hidden service. 640 5.1. Session resumption with combined tickets 642 In this example, the client obtains a combined session resumption 643 ticket during a previous connection to the hidden service, and has 644 learned the SNI of the fronting service. The session resumption will 645 happen as follow: 647 Client Fronting Service Hidden Service 649 ClientHello 651 + early_data 652 + key_share* 654 + psk_key_exchange_modes 656 + pre_shared_key 658 + SNI = fronting 660 --------> 662 // Decode the ticket 664 // Forwards to hidden 666 ClientHello -------> 668 (Application Data*) ----------------------> 670 ServerHello 672 + pre_shared_key 674 + key_share* 676 {EncryptedExtensions} 678 + early_data* 680 {Finished} 682 <---------------------- [Application Data] 684 (EndOfEarlyData) 686 {Finished} ----------------------> 688 [Application Data] <---------------------> [Application Data] 690 + Indicates noteworthy extensions sent in the 692 previously noted message. 694 * Indicates optional or situation-dependent 696 messages/extensions that are not always sent. 698 () encrypted with Client->Hidden 0-RTT key 700 {} encrypted with Client->Hidden 1-RTT handshake 702 [] encrypted with Client->Hidden 1-RTT key 704 The Fronting server that receives the Client Hello will find the 705 combined ticket in the pre_shared_key extensions, just as it would in 706 a regular session resumption attempt. When parsing the ticket, the 707 Fronting server will discover that the session really is meant to be 708 resumed with the Hidden server. It will arrange for all the 709 connection data to be forwarded to the Hidden server, including 710 forwarding a copy of the initial Client Hello. 712 The Hidden server will receive the Client Hello. It will obtain the 713 identity of the Fronting service from the SNI parameter. It will 714 then parse the session resumption ticket, and proceed with the 715 resumption of the session. 717 In this design, the Client Hello message is relayed unchanged from 718 Fronting server to hidden server. This ensures that code changes are 719 confined to the interpretation of the message parameters. The 720 construction of handshake contexts is left unchanged. 722 5.2. New Combined Session Ticket 724 In normal TLS 1.3 operations, the server can send New Session Ticket 725 messages at any time after the receiving the Client Finished message. 726 The ticket structure is defined in TLS 1.3 as: 728 struct { 730 uint32 ticket_lifetime; 732 uint32 ticket_age_add; 734 opaque ticket_nonce<1..255>; 736 opaque ticket<1..2^16-1>; 738 Extension extensions<0..2^16-2>; 740 } NewSessionTicket; 742 When SNI encryption is enabled, tickets will carry a "Fronting SNI" 743 extension, and the ticket value itself will be negotiated between 744 Fronting Service and Hidden Service, as in: 746 Client Fronting Service Hidden Service 748 <======= 750 Combined Ticket =======> 752 [New Session Ticket 754 <------------------------ + SNI Extension] 756 <==> sent on connection between Hidden and Fronting service 758 <> encrypted with Fronting<->Hidden key 760 [] encrypted with Client->Hidden 1-RTT key 762 In theory, the actual format of the ticket could be set by mutual 763 agreement between Fronting Service and Hidden Service. In practice, 764 it is probably better to provide guidance, as the ticket must meet 765 three of requirements: 767 o The Fronting Server must understand enough of the combined ticket 768 to relay the connection towards the Hidden Server; 770 o The Hidden Server must understand enough of the combined ticket to 771 resume the session with the client; 773 o Third parties must not be able to deduce the name of the Hidden 774 Service from the value of the ticket. 776 There are two plausible designs, a stateful design and an shared key 777 design. (There is also a design in which the Hidden Server encrypts 778 the tickets with the public key of the Fronting Server, but that does 779 not seem very practical.) In the stateful design, the ticket are 780 just random numbers that the Fronting server associates with the 781 Hidden server, and the Hidden server associates with the session 782 context. The shared key design would work as follow: 784 o the hidden server and the fronting server share a symmetric key 785 K_sni. 787 o the "clear text" ticket includes a nonce, the ordinary ticket used 788 for session resumption by the hidden service, and the id of the 789 Hidden service for the Fronting Service. 791 o the ticket will be encrypted with AEAD, using the nonce as an IV. 793 o When the client reconnects to the fronting server, it decrypts the 794 ticket using K_sni and if it succeeds, then it just forwards the 795 CH to the hidden server indicated in id-hidden-service (which of 796 course has to know to ignore SNI). Otherwise, it terminates the 797 connection itself with its own SNI. 799 The hidden server can just refresh the ticket any time it pleases, as 800 usual. 802 This design allows the Hidden Service to hides behind many Fronting 803 Services, each using a different key. The Client Hello received by 804 the Hidden Server carries the SNI of the Frinting Service, which the 805 Hidden Server can use to select the appropriate K_sni. 807 5.3. First session 809 The previous sections present how sessions can be resumed with the 810 combined ticket. Clients have that have never contacted the Hidden 811 Server will need to obtain a first ticket during a first session. 812 The most plausible option is to have the client directly connects to 813 the Hidden Service, and then asks for a combined ticket. The obvious 814 issue is that the SNI will not be encrypted for this first 815 connection, which exposes clients to surveillance and censorship. 817 The client may also learn about the relation between Fronting Service 818 and Hidden Service through an out of band channel, such as DNS 819 service, or word of mouth. However, it is difficult to establish a 820 combined ticket completely out of band, since the ticket must be 821 associated to two shared secrets, one shared with the Fronting 822 service so the second Client Hello can be sent as 0-RTT data, and the 823 other shared with the Hidden service to ensure protection against 824 replay attacks. 826 An alternative may be to use the TLS-in-TLS service described in 827 Section 4.1 for the first contact. There will be some overhead due 828 to tunnelling, but as we discussed in Section 4.2.3 the tunneling 829 solution allows for safe first contact. Yet another way would be to 830 use the HTTPS in HTTPS tunneling described in Section 3.1. 832 6. Security Considerations 834 The encapsulation protocol proposed in this draft mitigates the known 835 attacks listed in Section 2. For example, the encapsulation design 836 uses pairwise security contexts, and is not dependent on the widely 837 shared secrets described in Section 2.2. The design also does not 838 rely on additional public key operations by the multiplexed server or 839 by the fronting server, and thus does not open the attack surface for 840 denial of service discussed in Section 2.3. The session keys are 841 negotiated end to end between the client and the protected service, 842 as required in Section 2.6. 844 The combined ticket solution also mitigates the known attacks. The 845 design also uses pairwise security contexts, and is not dependent on 846 the widely shared secrets described in Section 2.2. The design also 847 does not rely on additional public key operations by the multiplexed 848 server or by the fronting server, and thus does not open the attack 849 surface for denial of service discussed in Section 2.3. The session 850 keys are negotiated end to end between the client and the protected 851 service, as required in Section 2.6. 853 However, in some cases, proper mitigation depends on careful 854 implementation. 856 6.1. Replay attacks and side channels 858 Both solutions mitigate the replay attacks described in Section 2.1 859 because adversaries cannot receive the replies intended for the 860 client. However, the connection from the fronting service to the 861 hidden service can be observed through side channels. 863 To give an obvious example, suppose that the fronting service merely 864 relays the data by establishing a TCP connection to the hidden 865 service. Adversaries can associate the arrival of an encrypted 866 message to the fronting service and the setting of a connection to 867 the hidden service, and deduce which hidden service the user 868 accessed. 870 The mitigation of this attack relies on proper implementation of the 871 fronting service. This may require cooperation from the multiplexed 872 server. 874 6.2. Sticking out 876 The TLS encapsulation protocol mostly fulfills the requirements to 877 "not stick out" expressed in Section 2.4. The initial messages will 878 be sent as 0-RTT data, and will be encrypted using the 0-RTT key 879 negotiated with the fronting service. Adversaries cannot tell 880 whether the client is using TLS encapsulation or some other 0-RTT 881 service. However, this is only true if the fronting service 882 regularly uses 0-RTT data. 884 The combined token solution almost perfectly fulfills the 885 requirements to "not stick out" expressed in Section 2.4, as the 886 observable flow of message is almost exactly the same as a regular 887 TLS connection. However, adversaries could observe the values of the 888 PSK Identifier that contains the combined ticket. The proposed 889 ticket structure is designed to thwart analysis of the ticket, but if 890 implementations are not careful the size of the combined ticket can 891 be used as a side channel allowing adversaries to distinguish between 892 different Hidden Services located behind the same Fronting Service. 894 6.3. Forward Secrecy 896 In the TLS encapsulation protocol, the encapsulated Client Hello is 897 encrypted using the session resumption key. If this key is revealed, 898 the Client Hello data will also be revealed. The mitigation there is 899 to not use the same session resumption key multiple time. 901 The most common implementations of TLS tickets have the server using 902 Session Ticket Encryption Keys (STEKs) to create an encrypted copy of 903 the session parameters which is then stored by the client. When the 904 client resumes, it supplies this encrypted copy, the server decrypts 905 it, and has the parameters it needs to resume. The server need only 906 remember the STEK. If a STEK is disclosed to an adversary, then all 907 of the data encrypted by sessions protected by the STEK may be 908 decrypted by an adversary. 910 To mitigate this attack, server implementations of the TLS 911 encapsulation protocol SHOULD use stateful tickets instead of STEK 912 protected TLS tickets. If they do rely on STEK protected tickets, 913 they MUST ensure that the K_sni keys used to encrypt these tickets 914 are rotated frequently. 916 7. IANA Considerations 918 Do we need to register an extension point? Or is it just OK to use 919 early data? 921 8. Acknowledgements 923 A large part of this draft originates in discussion of SNI encryption 924 on the TLS WG mailing list, including comments after the tunneling 925 approach was first proposed in a message to that list: 926 . 929 During the discussion of SNI Encryption in Yokohama, Deb Cooley 930 argued that rather than messing with TLS to allow SNI encryption, we 931 should just tunnel TLS in TLS. A number of people objected to this 932 on the grounds of the performance cost for the gateway because it has 933 to encrypt and decrypt everything. 935 After the meeting, Martin Thomson suggested a modification to the 936 tunnelling proposal that removes this cost. The key observation is 937 that if we think of the 0-RTT flight as a separate message attached 938 to the handshake, then we can tunnel a second first flight in it. 940 The combined ticket approach was first proposed by Cedric Fournet and 941 Antoine Delignaut-Lavaud. 943 The delegation token design comes from many people, including Ben 944 Schwartz, Brian Sniffen and Rich Salz. 946 9. References 948 9.1. Normative References 950 [I-D.ietf-tls-tls13] 951 Rescorla, E., "The Transport Layer Security (TLS) Protocol 952 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 953 April 2017. 955 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 956 Requirement Levels", BCP 14, RFC 2119, 957 DOI 10.17487/RFC2119, March 1997, 958 . 960 9.2. Informative References 962 [I-D.hoffman-dns-over-https] 963 Hoffman, P. and P. McManus, "DNS Queries over HTTPS", 964 draft-hoffman-dns-over-https-01 (work in progress), June 965 2017. 967 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 968 RFC 2595, DOI 10.17487/RFC2595, June 1999, 969 . 971 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 972 (TLS) Protocol Version 1.2", RFC 5246, 973 DOI 10.17487/RFC5246, August 2008, 974 . 976 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 977 and P. Hoffman, "Specification for DNS over Transport 978 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 979 2016, . 981 Authors' Addresses 983 Christian Huitema 984 Private Octopus Inc. 985 Friday Harbor WA 98250 986 U.S.A 988 Email: huitema@huitema.net 990 Eric Rescorla 991 RTFM, Inc. 992 U.S.A 994 Email: ekr@rtfm.com