idnits 2.17.1 draft-ietf-tls-sni-encryption-09.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 (October 28, 2019) is 1640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-http2-secondary-certs-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-23 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-33 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- 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 (==), 7 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: Informational E. Rescorla 5 Expires: April 30, 2020 RTFM, Inc. 6 October 28, 2019 8 Issues and Requirements for SNI Encryption in TLS 9 draft-ietf-tls-sni-encryption-09 11 Abstract 13 This draft describes the general problem of encrypting the Server 14 Name Identification (SNI) TLS parameter. The proposed solutions hide 15 a Hidden Service behind a fronting service, only disclosing the SNI 16 of the fronting service to external observers. The draft lists known 17 attacks against SNI encryption, discusses the current "co-tenancy 18 fronting" solution, and presents requirements for future TLS layer 19 solutions. 21 In practice, it may well be that no solution can meet every 22 requirement, and that practical solutions will have to make some 23 compromises. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 30, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. History of the TLS SNI extension . . . . . . . . . . . . . . 3 61 2.1. Unanticipated usage of SNI information . . . . . . . . . 4 62 2.2. SNI encryption timeliness . . . . . . . . . . . . . . . . 4 63 2.3. End-to-end alternatives . . . . . . . . . . . . . . . . . 5 64 3. Security and Privacy Requirements for SNI Encryption . . . . 5 65 3.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 6 66 3.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 6 67 3.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 6 68 3.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 7 69 3.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 7 70 3.6. Multi-Party Security Contexts . . . . . . . . . . . . . . 7 71 3.7. Supporting multiple protocols . . . . . . . . . . . . . . 8 72 3.7.1. Hiding the Application Layer Protocol Negotiation . . 8 73 3.7.2. Support other transports than TCP . . . . . . . . . . 9 74 4. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 9 75 4.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 10 76 4.2. Delegation Control . . . . . . . . . . . . . . . . . . . 10 77 4.3. Related work . . . . . . . . . . . . . . . . . . . . . . 11 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 8. Informative References . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 Historically, adversaries have been able to monitor the use of web 87 services through three primary channels: looking at DNS requests, 88 looking at IP addresses in packet headers, and looking at the data 89 stream between user and services. These channels are getting 90 progressively closed. A growing fraction of Internet communication 91 is encrypted, mostly using Transport Layer Security (TLS) [RFC5246]. 92 Progressive deployment of solutions like DNS in TLS [RFC7858] and DNS 93 over HTTPS [RFC8484] mitigates the disclosure of DNS information. 94 More and more services are colocated on multiplexed servers, 95 loosening the relation between IP address and web service. For 96 example, in virtual hosting solutions, multiple services can be 97 hosted as co-tenants on the same server, and the IP address and port 98 do not uniquely identify a service. In cloud or Content Delivery 99 Networks (CDNs) solutions, a given platform hosts the services or 100 servers servers of a lot of organization, and looking up to what 101 netblock an IP address belongs reveals little. However, multiplexed 102 servers rely on the Service Name Information (SNI) TLS extension 103 [RFC6066] to direct connections to the appropriate service 104 implementation. This protocol element is transmitted in clear text. 105 As the other methods of monitoring get blocked, monitoring focuses on 106 the clear text SNI. The purpose of SNI encryption is to prevent that 107 and aid privacy. 109 Replacing clear text SNI transmission by an encrypted variant will 110 improve the privacy and reliability of TLS connections, but the 111 design of proper SNI encryption solutions is difficult. In the past, 112 there have been multiple attempts at defining SNI encryption. These 113 attempts have generally floundered, because the simple designs fail 114 to mitigate several of the attacks listed in Section 3. In the 115 absence of a TLS-level solution, the most popular approach to SNI 116 privacy for web services is HTTP-level fronting, which we discuss in 117 Section 4. 119 This document does not present the design of a solution, but provides 120 guidelines for evaluating proposed solutions. (The review of HTTP- 121 level solutions in Section 4 is not an endorsement of these 122 solutions.) The need for related work on the encryption of the 123 Application Layer Protocol Negotiation (ALPN) parameters of TLS is 124 discussed in Section 3.7.1. 126 2. History of the TLS SNI extension 128 The SNI extension was specified in 2003 in [RFC3546] to facilitate 129 management of "colocation servers", in which multiple services shared 130 the same IP address. A typical example would be multiple web sites 131 served by the same web server. The SNI extension carries the name of 132 a specific server, enabling the TLS connection to be established with 133 the desired server context. The current SNI extension specification 134 can be found in [RFC6066]. 136 The SNI specification allowed for different types of server names, 137 though only the "hostname" variant was specified and deployed. In 138 that variant, the SNI extension carries the domain name of the target 139 server. The SNI extension is carried in clear text in the TLS 140 "ClientHello" message. 142 2.1. Unanticipated usage of SNI information 144 The SNI was defined to facilitate management of servers, but the 145 developers of middleboxes found out that they could take advantage of 146 the information. Many examples of such usage are reviewed in 147 [RFC8404]. Other examples came out during discussions of this draft. 148 They include: 150 o Filtering or censorship of specific services for a variety of 151 reasons. 153 o Content filtering by network operators or ISP blocking specific 154 web sites in order to implement, for example, parental controls, 155 or to prevent access to phishing or other fraudulent web sites. 157 o ISP assigning different QoS profiles to target services, 159 o Firewalls within enterprise networks blocking web sites not deemed 160 appropriate for work, or 162 o Firewalls within enterprise networks exempting specific web sites 163 from Man-In-The-Middle (MITM) inspection, such as healthcare or 164 financial sites for which inspection would intrude on the privacy 165 of employees. 167 The SNI is probably also included in the general collection of 168 metadata by pervasive surveillance actors [RFC7258], for example to 169 identify services used by surveillance targets. 171 2.2. SNI encryption timeliness 173 The clear-text transmission of the SNI was not flagged as a problem 174 in the security consideration sections of [RFC3546], [RFC4366], or 175 [RFC6066]. These specifications did not anticipate the alternative 176 usage described in Section 2.1. One reason may be that, when these 177 RFCs were written, the SNI information was available through a 178 variety of other means, such as tracking IP addresses, DNS names, or 179 server certificates. 181 Many deployments still allocate different IP addresses to different 182 services, so that different services can be identified by their IP 183 addresses. However, CDNs commonly serve a large number of services 184 through a comparatively small number of addresses. 186 The SNI carries the domain name of the server, which is also sent as 187 part of the DNS queries. Most of the SNI usage described in 188 Section 2.1 could also be implemented by monitoring DNS traffic or 189 controlling DNS usage. But this is changing with the advent of DNS 190 resolvers providing services like DNS over TLS [RFC7858] or DNS over 191 HTTPS [RFC8484]. 193 The subjectAltName extension of type dNSName of the server 194 certificate, or in its absence the common name component, expose the 195 same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346], 196 and 1.2 [RFC5246], servers send certificates in clear text, ensuring 197 that there would be limited benefits in hiding the SNI. However, in 198 TLS 1.3 [RFC8446], server certificates are encrypted in transit. 199 Note that encryption alone is insufficient to protect server 200 certificates; see Section 3.1 for details. 202 The decoupling of IP addresses and server names, deployment of DNS 203 privacy, and protection of server certificate transmissions all 204 contribute to user privacy in the face of an [RFC7258]-style 205 adversary. Encrypting the SNI complements this push for privacy and 206 make it harder to censor or otherwise provide differential treatment 207 to specific internet services. 209 2.3. End-to-end alternatives 211 Deploying SNI encryption helps thwart most of the unanticipated SNI 212 usages including censorship and pervasive surveillance, but it also 213 will break or reduce the efficacy of the operational practices and 214 techniques implemented in middle-boxes as described in Section 2.1. 215 Most of these functions can, however, be realized by other means. 216 For example, some DNS service providers offer customers the provision 217 to "opt in" filtering services for parental control and phishing 218 protection. Per-stream QoS could be provided by a combination of 219 packet marking and end-to-end agreements. As SNI encryption becomes 220 common, we can expect more deployment of such "end-to-end" solutions. 222 At the time of this writing, enterprises have the option of 223 installing a firewall performing SNI filtering to prevent connections 224 to certain websites. With SNI encryption this becomes ineffective. 225 Obviously, managers could block usage of SNI encryption in enterprise 226 computers, but this wide-scale blocking would diminish the privacy 227 protection of traffic leaving the enterprise, which may not be 228 desirable. Enterprise managers could rely instead on filtering 229 software and management software deployed on the enterprise's 230 computers. 232 3. Security and Privacy Requirements for SNI Encryption 234 Over the past years, there have been multiple proposals to add an SNI 235 encryption option in TLS. A review of the TLS mailing list archives 236 shows that many of these proposals appeared promising but were 237 rejected after security reviews identified plausible attacks. In 238 this section, we collect a list of these known attacks. 240 3.1. Mitigate Replay Attacks 242 The simplest SNI encryption designs replace in the initial TLS 243 exchange the clear text SNI with an encrypted value, using a key 244 known to the multiplexed server. Regardless of the encryption used, 245 these designs can be broken by a simple replay attack, which works as 246 follows: 248 1- The user starts a TLS connection to the multiplexed server, 249 including an encrypted SNI value. 251 2- The adversary observes the exchange and copies the encrypted SNI 252 parameter. 254 3- The adversary starts its own connection to the multiplexed server, 255 including in its connection parameters the encrypted SNI copied from 256 the observed exchange. 258 4- The multiplexed server establishes the connection to the protected 259 service, thus revealing the identity of the service. 261 One of the goals of SNI encryption is to prevent adversaries from 262 knowing which Hidden Service the client is using. Successful replay 263 attacks break that goal by allowing adversaries to discover that 264 service. 266 3.2. Avoid Widely Shared Secrets 268 It is easy to think of simple schemes in which the SNI is encrypted 269 or hashed using a shared secret. This symmetric key must be known by 270 the multiplexed server, and by every user of the protected services. 271 Such schemes are thus very fragile, since the compromise of a single 272 user would compromise the entire set of users and protected services. 274 3.3. Prevent SNI-based Denial of Service Attacks 276 Encrypting the SNI may create extra load for the multiplexed server. 277 Adversaries may mount denial of service attacks by generating random 278 encrypted SNI values and forcing the multiplexed server to spend 279 resources in useless decryption attempts. 281 It may be argued that this is not an important Denial of Service 282 Attacks (DoS) avenue, as regular TLS connection attempts also require 283 the server to perform a number of cryptographic operations. However, 284 in many cases, the SNI decryption will have to be performed by a 285 front-end component with limited resources, while the TLS operations 286 are performed by the component dedicated to their respective 287 services. SNI-based DoS attacks could target the front-end 288 component. 290 3.4. Do not stick out 292 In some designs, handshakes using SNI encryption can be easily 293 differentiated from "regular" handshakes. For example, some designs 294 require specific extensions in the Client Hello packets, or specific 295 values of the clear text SNI parameter. If adversaries can easily 296 detect the use of SNI encryption, they could block it, or they could 297 flag the users of SNI encryption for special treatment. 299 In the future, it might be possible to assume that a large fraction 300 of TLS handshakes use SNI encryption. If that were the case, the 301 detection of SNI encryption would be a lesser concern. However, we 302 have to assume that in the near future, only a small fraction of TLS 303 connections will use SNI encryption. 305 3.5. Forward Secrecy 307 The general concerns about forward secrecy apply to SNI encryption 308 just as well as to regular TLS sessions. For example, some proposed 309 designs rely on a public key of the multiplexed server to define the 310 SNI encryption key. If the corresponding private key should be 311 compromised, the adversaries would be able to process archival 312 records of past connections, and retrieve the protected SNI used in 313 these connections. These designs failed to maintain forward secrecy 314 of SNI encryption. 316 3.6. Multi-Party Security Contexts 318 We can design solutions in which a fronting service acts as a relay 319 to reach the protected service. Some of those solutions involve just 320 one TLS handshake between the client and the fronting service. The 321 master secret is verified by verifying a certificate provided by the 322 fronting service, but not by the protected service. These solutions 323 expose the client to a Man-In-The-Middle attack by the fronting 324 service. Even if the client has some reasonable trust in this 325 service, the possibility of MITM attack is troubling. 327 There are other classes of solutions in which the master secret is 328 verified by verifying a certificate provided by the protected 329 service. These solutions offer more protection against MITM attack 330 by the fronting service. The downside is that the client will not 331 verify the identity of the fronting service, which enables fronting 332 server spoofing attacks such as the "honeypot" attack discussed 333 below. Overall, end-to-end TLS to the protected service is 334 preferable, but it is important to also provide a way to authenticate 335 the fronting service. 337 The fronting service could be pressured by adversaries. By design, 338 it could be forced to deny access to the protected service, or to 339 divulge which client accessed it. But if MITM is possible, the 340 adversaries would also be able to pressure the fronting service into 341 intercepting or spoofing the communications between client and 342 protected service. 344 Adversaries could also mount an attack by spoofing the fronting 345 service. A spoofed fronting service could act as a "honeypot" for 346 users of hidden services. At a minimum, the fake server could record 347 the IP addresses of these users. If the SNI encryption solution 348 places too much trust on the fronting server, the fake server could 349 also serve fake content of its own choosing, including various forms 350 of malware. 352 There are two main channels by which adversaries can conduct this 353 attack. Adversaries can simply try to mislead users into believing 354 that the honeypot is a valid fronting server, especially if that 355 information is carried by word of mouth or in unprotected DNS 356 records. Adversaries can also attempt to hijack the traffic to the 357 regular fronting server, using, for example, spoofed DNS responses or 358 spoofed IP level routing, combined with a spoofed certificate. 360 3.7. Supporting multiple protocols 362 The SNI encryption requirement does not stop with HTTP over TLS. 363 Multiple other applications currently use TLS, including, for 364 example, SMTP [RFC5246], DNS [RFC7858], IMAP [RFC8314], and XMPP 365 [RFC7590]. These applications, too, will benefit from SNI 366 encryption. HTTP-only methods like those described in Section 4.1 367 would not apply there. In fact, even for the HTTPS case, the HTTPS 368 tunneling service described in Section 4.1 is compatible with HTTP 369 1.0 and HTTP 1.1, but interacts awkwardly with the multiple streams 370 feature of HTTP/2 [RFC7540]. This points to the need for an 371 application-agnostic solution, which would be implemented fully in 372 the TLS layer. 374 3.7.1. Hiding the Application Layer Protocol Negotiation 376 The Application Layer Protocol Negotiation (ALPN) parameters of TLS 377 allow implementations to negotiate the application layer protocol 378 used on a given connection. TLS provides the ALPN values in clear 379 text during the initial handshake. While exposing the ALPN does not 380 create the same privacy issues as exposing the SNI, there is still a 381 risk. For example, some networks may attempt to block applications 382 that they do not understand, or that they wish users would not use. 384 In a sense, ALPN filtering could be very similar to the filtering of 385 specific port numbers exposed in some networks. This filtering by 386 ports has given rise to evasion tactics in which various protocols 387 are tunneled over HTTP in order to use open ports 80 or 443. 388 Filtering by ALPN would probably beget the same responses, in which 389 the applications just move over HTTP, and only the HTTP ALPN values 390 are used. Applications would not need to do that if the ALPN were 391 hidden in the same way as the SNI. 393 In addition to hiding the SNI, it is thus desirable to also hide the 394 ALPN. Of course, this implies engineering trade-offs. Using the 395 same technique for hiding the ALPN and encrypting the SNI may result 396 in excess complexity. It might be preferable to encrypt these 397 independently. 399 3.7.2. Support other transports than TCP 401 The TLS handshake is also used over other transports such as UDP with 402 both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls]. The 403 requirement to encrypt the SNI applies just as well for these 404 transports as for TLS over TCP. 406 This points to a requirement for SNI Encryption mechanisms to also be 407 applicable to non-TCP transports such as DTLS or QUIC. 409 4. HTTP Co-Tenancy Fronting 411 In the absence of TLS-level SNI encryption, many sites rely on an 412 "HTTP Co-Tenancy" solution, often refered to as Domain Fronting 413 [domfront]. The TLS connection is established with the fronting 414 server, and HTTP requests are then sent over that connection to the 415 hidden service. For example, the TLS SNI could be set to 416 "fronting.example.com", the fronting server, and HTTP requests sent 417 over that connection could be directed to "hidden.example.com", 418 accessing the hidden service. This solution works well in practice 419 when the fronting server and the hidden server are "co-tenants" of 420 the same multiplexed server. 422 The HTTP fronting solution can be deployed without modification to 423 the TLS protocol, and does not require using any specific version of 424 TLS. There are, however, a few issues regarding discovery, client 425 implementations, trust, and applicability: 427 o The client has to discover that the hidden service can be accessed 428 through the fronting server. 430 o The client's browser has to be directed to access the hidden 431 service through the fronting service. 433 o Since the TLS connection is established with the fronting service, 434 the client has no cryptographic proof that the content does, in 435 fact, come from the hidden service. The solution does thus not 436 mitigate the context sharing issues described in Section 3.6. 438 o Since this is an HTTP-level solution, it does not protect non-HTTP 439 protocols as discussed in Section 3.7. 441 The discovery issue is common to most SNI encryption solutions. The 442 browser issue was solved in [domfront] by implementing domain 443 fronting as a pluggable transport for the Tor browser. The multi- 444 protocol issue can be mitigated by using implementation of other 445 applications over HTTP, such as for example DNS over HTTPS [RFC8484]. 446 The trust issue, however, requires specific developments. 448 4.1. HTTPS Tunnels 450 The HTTP Fronting solution places a lot of trust in the Fronting 451 Server. This required trust can be reduced by tunnelling HTTPS in 452 HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. 453 In this solution, the client establishes a TLS connection to the 454 Fronting Server, and then issues an HTTP Connect request to the 455 Hidden Server. This will establish an end-to-end HTTPS over TLS 456 connection between the client and the Hidden Server, mitigating the 457 issues described in Section 3.6. 459 The HTTPS in HTTPS solution requires double encryption of every 460 packet. It also requires that the fronting server decrypt and relay 461 messages to the hidden server. Both of these requirements make the 462 implementation onerous. 464 4.2. Delegation Control 466 Clients would see their privacy compromised if they contacted the 467 wrong fronting server to access the hidden service, since this wrong 468 server could disclose their access to adversaries. This requires a 469 controlled way to indicate which fronting server is acceptable by the 470 hidden service. 472 This problem is both similar and different from the "fronting server 473 spoofing" attack described in Section 3.6. Here, the spoofing would 474 be performed by distributing fake advice, such as "to reach 475 hidden.example.com, use fake.example.com as a fronting server", when 476 "fake.example.com" is under the control of an adversary. 478 In practice, this attack is well mitigated when the hidden service is 479 accessed through a specialized application. The name of the fronting 480 server can then be programmed in the code of the application. But 481 the attack is harder to mitigate when the hidden service has to be 482 accessed through general purpose web browsers. 484 There are several proposed solutions to this problem, such as 485 creating a special form of certificate to codify the relation between 486 fronting and hidden server, or obtaining the relation between hidden 487 and fronting service through the DNS, possibly using DNSSEC to avoid 488 spoofing. The experiment described in [domfront] solved the issue by 489 integrating with the Lantern Internet circumvention circumvention 490 tool. 492 We can observe that CDNs have a similar requirement. They need to 493 convince the client that "www.example.com" can be accessed through 494 the seemingly unrelated "cdn-node-xyz.example.net". Most CDNs have 495 deployed DNS-based solutions to this problem. However, the CDN often 496 holds the authoritative certificate of the origin. There is 497 simultaneously verification of a relationship between the origin and 498 the CDN, through the certificate, and a risk that the CDN can spoof 499 the content from the origin. 501 4.3. Related work 503 The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag 504 content provided by the hidden server. Secondary certificate 505 authentication [I-D.ietf-httpbis-http2-secondary-certs] can be used 506 to manage authentication of hidden server content, or to perform 507 client authentication before accessing hidden content. 509 5. Security Considerations 511 This document lists a number of attacks against SNI encryption in 512 Section 3 and also in Section 4.2, and presents a list of 513 requirements to mitigate these attacks. Current HTTP-based solutions 514 described in Section 4 only meet some of these requirements. In 515 practice, it may well be that no solution can meet every requirement, 516 and that practical solutions will have to make some compromises. 518 In particular, the requirement to not stick out presented in 519 Section 3.4 may have to be lifted, especially for proposed solutions 520 that could quickly reach large scale deployments. 522 Replacing clear text SNI transmission by an encrypted variant will 523 break or reduce the efficacy of the operational practices and 524 techniques implemented in middle-boxes as described in Section 2.1. 526 As explained in Section 2.3, alternative solutions will have to be 527 developed. 529 6. IANA Considerations 531 This draft does not require any IANA action. 533 7. Acknowledgements 535 A large part of this draft originates in discussion of SNI encryption 536 on the TLS WG mailing list, including comments after the tunneling 537 approach was first proposed in a message to that list: 538 . 541 Thanks to Daniel Kahn Gillmor for a pretty detailed review of the 542 initial draft. Thanks to Bernard Aboba, Mike Bishop, Alissa Cooper, 543 Roman Danyliw, Stephen Farrell, Warren Kumari, Mirja Kuelewind Barry 544 Leiba, Martin Rex, Adam Roach, Meral Shirazipour, Martin Thomson, 545 Eric Vyncke, and employees of the UK National Cyber Security Centre 546 for their reviews. Thanks to Chris Wood, Ben Kaduk and Sean Turner 547 for helping publish this document. 549 8. Informative References 551 [domfront] 552 Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V. 553 Paxson, "Blocking-resistant communication through domain 554 fronting", DOI 10.1515/popets-2015-0009, 2015, 555 . 557 [I-D.ietf-httpbis-http2-secondary-certs] 558 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 559 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 560 http2-secondary-certs-04 (work in progress), April 2019. 562 [I-D.ietf-quic-tls] 563 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 564 draft-ietf-quic-tls-23 (work in progress), September 2019. 566 [I-D.ietf-tls-dtls13] 567 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 568 Datagram Transport Layer Security (DTLS) Protocol Version 569 1.3", draft-ietf-tls-dtls13-33 (work in progress), October 570 2019. 572 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 573 RFC 2246, DOI 10.17487/RFC2246, January 1999, 574 . 576 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 577 and T. Wright, "Transport Layer Security (TLS) 578 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 579 . 581 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 582 (TLS) Protocol Version 1.1", RFC 4346, 583 DOI 10.17487/RFC4346, April 2006, 584 . 586 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 587 and T. Wright, "Transport Layer Security (TLS) 588 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 589 . 591 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 592 (TLS) Protocol Version 1.2", RFC 5246, 593 DOI 10.17487/RFC5246, August 2008, 594 . 596 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 597 Extensions: Extension Definitions", RFC 6066, 598 DOI 10.17487/RFC6066, January 2011, 599 . 601 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 602 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 603 2014, . 605 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 606 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 607 DOI 10.17487/RFC7540, May 2015, 608 . 610 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 611 Security (TLS) in the Extensible Messaging and Presence 612 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 613 2015, . 615 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 616 and P. Hoffman, "Specification for DNS over Transport 617 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 618 2016, . 620 [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: 621 Use of Transport Layer Security (TLS) for Email Submission 622 and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, 623 . 625 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 626 RFC 8336, DOI 10.17487/RFC8336, March 2018, 627 . 629 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 630 Pervasive Encryption on Operators", RFC 8404, 631 DOI 10.17487/RFC8404, July 2018, 632 . 634 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 635 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 636 . 638 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 639 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 640 . 642 Authors' Addresses 644 Christian Huitema 645 Private Octopus Inc. 646 Friday Harbor WA 98250 647 U.S.A 649 Email: huitema@huitema.net 651 Eric Rescorla 652 RTFM, Inc. 653 U.S.A 655 Email: ekr@rtfm.com