idnits 2.17.1 draft-ietf-tls-sni-encryption-07.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 (September 23, 2019) is 1676 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3552' is defined on line 576, but no explicit reference was found in the text == 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-32 -- 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 (~~), 5 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: March 26, 2020 RTFM, Inc. 6 September 23, 2019 8 Issues and Requirements for SNI Encryption in TLS 9 draft-ietf-tls-sni-encryption-07 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 March 26, 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 . . . . . . . . . 3 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 and privacy is to 107 prevent that. 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 need for related 121 work on the encryption of the Application Layer Protocol Negotiation 122 (ALPN) parameters of TLS is discussed in Section 3.7.1. 124 2. History of the TLS SNI extension 126 The SNI extension was specified in 2003 in [RFC3546] to facilitate 127 management of "colocation servers", in which multiple services shared 128 the same IP address. A typical example would be multiple web sites 129 served by the same web server. The SNI extension carries the name of 130 a specific server, enabling the TLS connection to be established with 131 the desired server context. The current SNI extension specification 132 can be found in [RFC6066]. 134 The SNI specification allowed for different types of server names, 135 though only the "hostname" variant was specified and deployed. In 136 that variant, the SNI extension carries the domain name of the target 137 server. The SNI extension is carried in clear text in the TLS 138 "ClientHello" message. 140 2.1. Unanticipated usage of SNI information 142 The SNI was defined to facilitate management of servers, but the 143 developers of middleboxes found out that they could take advantage of 144 the information. Many examples of such usage are reviewed in 146 [RFC8404]. Other examples came out during discussions of this draft. 147 They include: 149 o Filtering or censorship of specific services for a variety of 150 reasons. 152 o Content filtering by network operators or ISP blocking specific 153 web sites in order to implement, for example, parental controls, 154 or to prevent access to phishing or other fraudulent web sites. 156 o ISP assigning different QoS profiles to target services, 158 o Firewalls within enterprise networks blocking web sites not deemed 159 appropriate for work, or 161 o Firewalls within enterprise networks exempting specific web sites 162 from Man-In-The-Middle (MITM) inspection, such as healthcare or 163 financial sites for which inspection would intrude on the privacy 164 of employees. 166 The SNI is probably also included in the general collection of 167 metadata by pervasive surveillance actors, for example to identify 168 services used by surveillance targets. 170 2.2. SNI encryption timeliness 172 The clear-text transmission of the SNI was not flagged as a problem 173 in the security consideration sections of [RFC3546], [RFC4366], or 174 [RFC6066]. These specifications did not anticipate the alternative 175 usage described in Section 2.1. One reason may be that, when these 176 RFCs were written, the SNI information was available through a 177 variety of other means, such as tracking IP addresses, DNS names, or 178 server certificates. 180 Many deployments still allocate different IP addresses to different 181 services, so that different services can be identified by their IP 182 addresses. However, CDNs commonly serve a large number of services 183 through a comparatively small number of addresses. 185 The SNI carries the domain name of the server, which is also sent as 186 part of the DNS queries. Most of the SNI usage described in 187 Section 2.1 could also be implemented by monitoring DNS traffic or 188 controlling DNS usage. But this is changing with the advent of DNS 189 resolvers providing services like DNS over TLS [RFC7858] or DNS over 190 HTTPS [RFC8484]. 192 The subjectAltName extension of type dNSName of the server 193 certificate, or in its absence the common name component, expose the 194 same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346], 195 and 1.2 [RFC5246], servers send certificates in clear text, ensuring 196 that there would be limited benefits in hiding the SNI. However, in 197 TLS 1.3 [RFC8446], server certificates are encrypted in transit. 198 Note that encryption alone is insufficient to protect server 199 certificates; see Section 3.1 for details. 201 The decoupling of IP addresses and server names, deployment of DNS 202 privacy, and protection of server certificate transmissions all 203 contribute to user privacy in the face of an [RFC3552]-style 204 adversary. Encrypting the SNI completes this push for privacy and 205 make it harder to censor or otherwise provide differential treatment 206 to specific internet services. 208 2.3. End-to-end alternatives 210 Deploying SNI encryption helps thwart most of the unanticipated SNI 211 usages including censorship and pervasive surveillance, but it also 212 will break or reduce the efficacy of the operational practices and 213 techniques implemented in middle-boxes as described in Section 2.1. 214 Most of these functions can, however, be realized by other means. 215 For example, some DNS service providers offer customers the provision 216 to "opt in" filtering services for parental control and phishing 217 protection. Per-stream QoS could be provided by a combination of 218 packet marking and end-to-end agreements. As SNI encryption becomes 219 common, we can expect more deployment of such "end-to-end" solutions. 221 At the time of this writing, enterprises have the option of 222 installing a firewall performing SNI filtering to prevent connections 223 to certain websites. With SNI encryption this becomes ineffective. 224 Obviously, managers could block usage of SNI encryption in enterprise 225 computers, but this wide-scale blocking would diminish the privacy 226 protection of traffic leaving the enterprise, which may not be 227 desirable. Enterprise managers could rely instead on filtering 228 software and management software deployed on the enterprise's 229 computers. 231 3. Security and Privacy Requirements for SNI Encryption 233 Over the past years, there have been multiple proposals to add an SNI 234 encryption option in TLS. A review of the TLS mailing list archives 235 shows that many of these proposals appeared promising but were 236 rejected after security reviews identified plausible attacks. In 237 this section, we collect a list of these known attacks. 239 3.1. Mitigate Replay Attacks 241 The simplest SNI encryption designs replace in the initial TLS 242 exchange the clear text SNI with an encrypted value, using a key 243 known to the multiplexed server. Regardless of the encryption used, 244 these designs can be broken by a simple replay attack, which works as 245 follows: 247 1- The user starts a TLS connection to the multiplexed server, 248 including an encrypted SNI value. 250 2- The adversary observes the exchange and copies the encrypted SNI 251 parameter. 253 3- The adversary starts its own connection to the multiplexed server, 254 including in its connection parameters the encrypted SNI copied from 255 the observed exchange. 257 4- The multiplexed server establishes the connection to the protected 258 service, thus revealing the identity of the service. 260 One of the goals of SNI encryption is to prevent adversaries from 261 knowing which Hidden Service the client is using. Successful replay 262 attacks break that goal by allowing adversaries to discover that 263 service. 265 3.2. Avoid Widely Shared Secrets 267 It is easy to think of simple schemes in which the SNI is encrypted 268 or hashed using a shared secret. This symmetric key must be known by 269 the multiplexed server, and by every user of the protected services. 270 Such schemes are thus very fragile, since the compromise of a single 271 user would compromise the entire set of users and protected services. 273 3.3. Prevent SNI-based Denial of Service Attacks 275 Encrypting the SNI may create extra load for the multiplexed server. 276 Adversaries may mount denial of service attacks by generating random 277 encrypted SNI values and forcing the multiplexed server to spend 278 resources in useless decryption attempts. 280 It may be argued that this is not an important Denial of Service 281 Attacks (DoS) avenue, as regular TLS connection attempts also require 282 the server to perform a number of cryptographic operations. However, 283 in many cases, the SNI decryption will have to be performed by a 284 front-end component with limited resources, while the TLS operations 285 are performed by the component dedicated to their respective 286 services. SNI-based DoS attacks could target the front-end 287 component. 289 3.4. Do not stick out 291 In some designs, handshakes using SNI encryption can be easily 292 differentiated from "regular" handshakes. For example, some designs 293 require specific extensions in the Client Hello packets, or specific 294 values of the clear text SNI parameter. If adversaries can easily 295 detect the use of SNI encryption, they could block it, or they could 296 flag the users of SNI encryption for special treatment. 298 In the future, it might be possible to assume that a large fraction 299 of TLS handshakes use SNI encryption. If that were the case, the 300 detection of SNI encryption would be a lesser concern. However, we 301 have to assume that in the near future, only a small fraction of TLS 302 connections will use SNI encryption. 304 3.5. Forward Secrecy 306 The general concerns about forward secrecy apply to SNI encryption 307 just as well as to regular TLS sessions. For example, some proposed 308 designs rely on a public key of the multiplexed server to define the 309 SNI encryption key. If the corresponding private key should be 310 compromised, the adversaries would be able to process archival 311 records of past connections, and retrieve the protected SNI used in 312 these connections. These designs failed to maintain forward secrecy 313 of SNI encryption. 315 3.6. Multi-Party Security Contexts 317 We can design solutions in which a fronting service acts as a relay 318 to reach the protected service. Some of those solutions involve just 319 one TLS handshake between the client and the fronting service. The 320 master secret is verified by verifying a certificate provided by the 321 fronting service, but not by the protected service. These solutions 322 expose the client to a Man-In-The-Middle attack by the fronting 323 service. Even if the client has some reasonable trust in this 324 service, the possibility of MITM attack is troubling. 326 There are other classes of solutions in which the master secret is 327 verified by verifying a certificate provided by the protected 328 service. These solutions offer more protection against MITM attack 329 by the fronting service. The downside is that the client will not 330 verify the identity of the fronting service, which enables fronting 331 server spoofing attacks such as the "honeypot" attack discussed 332 below. Overall, end-to-end TLS to the protected service is 333 preferable, but it is important to also provide a way to authenticate 334 the fronting service. 336 The fronting service could be pressured by adversaries. By design, 337 it could be forced to deny access to the protected service, or to 338 divulge which client accessed it. But if MITM is possible, the 339 adversaries would also be able to pressure the fronting service into 340 intercepting or spoofing the communications between client and 341 protected service. 343 Adversaries could also mount an attack by spoofing the fronting 344 service. A spoofed fronting service could act as a "honeypot" for 345 users of hidden services. At a minimum, the fake server could record 346 the IP addresses of these users. If the SNI encryption solution 347 places too much trust on the fronting server, the fake server could 348 also serve fake content of its own choosing, including various forms 349 of malware. 351 There are two main channels by which adversaries can conduct this 352 attack. Adversaries can simply try to mislead users into believing 353 that the honeypot is a valid fronting server, especially if that 354 information is carried by word of mouth or in unprotected DNS 355 records. Adversaries can also attempt to hijack the traffic to the 356 regular fronting server, using, for example, spoofed DNS responses or 357 spoofed IP level routing, combined with a spoofed certificate. 359 3.7. Supporting multiple protocols 361 The SNI encryption requirement does not stop with HTTP over TLS. 362 Multiple other applications currently use TLS, including, for 363 example, SMTP [RFC5246], DNS [RFC7858], IMAP [RFC8314], and XMPP 364 [RFC7590]. These applications, too, will benefit from SNI 365 encryption. HTTP-only methods like those described in Section 4.1 366 would not apply there. In fact, even for the HTTPS case, the HTTPS 367 tunneling service described in Section 4.1 is compatible with HTTP 368 1.0 and HTTP 1.1, but interacts awkwardly with the multiple streams 369 feature of HTTP/2 [RFC7540]. This points to the need for an 370 application-agnostic solution, which would be implemented fully in 371 the TLS layer. 373 3.7.1. Hiding the Application Layer Protocol Negotiation 375 The Application Layer Protocol Negotiation (ALPN) parameters of TLS 376 allow implementations to negotiate the application layer protocol 377 used on a given connection. TLS provides the ALPN values in clear 378 text during the initial handshake. While exposing the ALPN does not 379 create the same privacy issues as exposing the SNI, there is still a 380 risk. For example, some networks may attempt to block applications 381 that they do not understand, or that they wish users would not use. 383 In a sense, ALPN filtering could be very similar to the filtering of 384 specific port numbers exposed in some networks. This filtering by 385 ports has given rise to evasion tactics in which various protocols 386 are tunneled over HTTP in order to use open ports 80 or 443. 387 Filtering by ALPN would probably beget the same responses, in which 388 the applications just move over HTTP, and only the HTTP ALPN values 389 are used. Applications would not need to do that if the ALPN were 390 hidden in the same way as the SNI. 392 In addition to hiding the SNI, it is thus desirable to also hide the 393 ALPN. Of course, this implies engineering trade-offs. Using the 394 same technique for hiding the ALPN and encrypting the SNI may result 395 in excess complexity. It might be preferable to encrypt these 396 independently. 398 3.7.2. Support other transports than TCP 400 The TLS handshake is also used over other transports such as UDP with 401 both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls]. The 402 requirement to encrypt the SNI applies just as well for these 403 transports as for TLS over TCP. 405 This points to a requirement for SNI Encryption mechanisms to also be 406 applicable to non-TCP transports such as DTLS or QUIC. 408 4. HTTP Co-Tenancy Fronting 410 In the absence of TLS-level SNI encryption, many sites rely on an 411 "HTTP Co-Tenancy" solution, often refered to as Domain Fronting 412 [domfront]. The TLS connection is established with the fronting 413 server, and HTTP requests are then sent over that connection to the 414 hidden service. For example, the TLS SNI could be set to 415 "fronting.example.com", the fronting server, and HTTP requests sent 416 over that connection could be directed to "hidden.example.com", 417 accessing the hidden service. This solution works well in practice 418 when the fronting server and the hidden server are "co-tenants" of 419 the same multiplexed server. 421 The HTTP fronting solution can be deployed without modification to 422 the TLS protocol, and does not require using any specific version of 423 TLS. There are, however, a few issues regarding discovery, client 424 implementations, trust, and applicability: 426 o The client has to discover that the hidden service can be accessed 427 through the fronting server. 429 o The client's browser has to be directed to access the hidden 430 service through the fronting service. 432 o Since the TLS connection is established with the fronting service, 433 the client has no cryptographic proof that the content does, in 434 fact, come from the hidden service. The solution does thus not 435 mitigate the context sharing issues described in Section 3.6. 437 o Since this is an HTTP-level solution, it does not protect non-HTTP 438 protocols as discussed in Section 3.7. 440 The discovery issue is common to most SNI encryption solutions. The 441 browser issue was solved in [domfront] by implementing domain 442 fronting as a pluggable transport for the Tor browser. The multi- 443 protocol issue can be mitigated by using implementation of other 444 applications over HTTP, such as for example DNS over HTTPS [RFC8484]. 445 The trust issue, however, requires specific developments. 447 4.1. HTTPS Tunnels 449 The HTTP Fronting solution places a lot of trust in the Fronting 450 Server. This required trust can be reduced by tunnelling HTTPS in 451 HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. 452 In this solution, the client establishes a TLS connection to the 453 Fronting Server, and then issues an HTTP Connect request to the 454 Hidden Server. This will establish an end-to-end HTTPS over TLS 455 connection between the client and the Hidden Server, mitigating the 456 issues described in Section 3.6. 458 The HTTPS in HTTPS solution requires double encryption of every 459 packet. It also requires that the fronting server decrypt and relay 460 messages to the hidden server. Both of these requirements make the 461 implementation onerous. 463 4.2. Delegation Control 465 Clients would see their privacy compromised if they contacted the 466 wrong fronting server to access the hidden service, since this wrong 467 server could disclose their access to adversaries. This requires a 468 controlled way to indicate which fronting server is acceptable by the 469 hidden service. 471 This problem is both similar and different from the "fronting server 472 spoofing" attack described in Section 3.6. Here, the spoofing would 473 be performed by distributing fake advice, such as "to reach 474 hidden.example.com, use fake.example.com as a fronting server", when 475 "fake.example.com" is under the control of an adversary. 477 In practice, this attack is well mitigated when the hidden service is 478 accessed through a specialized application. The name of the fronting 479 server can then be programmed in the code of the application. But 480 the attack is harder to mitigate when the hidden service has to be 481 accessed through general purpose web browsers. 483 There are several proposed solutions to this problem, such as 484 creating a special form of certificate to codify the relation between 485 fronting and hidden server, or obtaining the relation between hidden 486 and fronting service through the DNS, possibly using DNSSEC to avoid 487 spoofing. The experiment described in [domfront] solved the issue by 488 integrating with the Lantern Internet circumvention circumvention 489 tool. 491 We can observe that CDNs have a similar requirement. They need to 492 convince the client that "www.example.com" can be accessed through 493 the seemingly unrelated "cdn-node-xyz.example.net". Most CDNs have 494 deployed DNS-based solutions to this problem. However, the CDN often 495 holds the authoritative certificate of the origin. There is 496 simultaneously verification of a relationship between the origin and 497 the CDN, through the certificate, and a risk that the CDN can spoof 498 the content from the origin. 500 4.3. Related work 502 The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag 503 content provided by the hidden server. Secondary certificate 504 authentication [I-D.ietf-httpbis-http2-secondary-certs] can be used 505 to manage authentication of hidden server content, or to perform 506 client authentication before accessing hidden content. 508 5. Security Considerations 510 This document lists a number of attacks against SNI encryption in 511 Section 3, and also in Section 4.2, and presents a list of 512 requirements to mitigate these attacks. Current HTTP-based solutions 513 described in Section 4 only meet some of these requirements. In 514 practice, it may well be that no solution can meet every requirement, 515 and that practical solutions will have to make some compromises. 517 In particular, the requirement to not stick out presented in 518 Section 3.4 may have to be lifted, especially for proposed solutions 519 that could quickly reach large scale deployments. 521 Replacing clear text SNI transmission by an encrypted variant will 522 also thwart MITM interferences that are sometimes described as 523 legitimate. As explained in Section 2.3, alternative solutions will 524 have to be developed. 526 6. IANA Considerations 528 This draft does not require any IANA action. 530 7. Acknowledgements 532 A large part of this draft originates in discussion of SNI encryption 533 on the TLS WG mailing list, including comments after the tunneling 534 approach was first proposed in a message to that list: 535 . 538 Thanks to Daniel Kahn Gillmor for a pretty detailed review of the 539 initial draft. Thanks to Bernard Aboba, Mike Bishop, Stephen 540 Farrell, Barry Leiba, Martin Rex, Meral Shirazipour, Martin Thomson 541 and employees of the UK National Cyber Security Centre for their 542 reviews. 544 8. Informative References 546 [domfront] 547 Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V. 548 Paxson, "Blocking-resistant communication through domain 549 fronting", DOI 10.1515/popets-2015-0009, 2015, 550 . 552 [I-D.ietf-httpbis-http2-secondary-certs] 553 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 554 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 555 http2-secondary-certs-04 (work in progress), April 2019. 557 [I-D.ietf-quic-tls] 558 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 559 draft-ietf-quic-tls-23 (work in progress), September 2019. 561 [I-D.ietf-tls-dtls13] 562 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 563 Datagram Transport Layer Security (DTLS) Protocol Version 564 1.3", draft-ietf-tls-dtls13-32 (work in progress), July 565 2019. 567 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 568 RFC 2246, DOI 10.17487/RFC2246, January 1999, 569 . 571 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 572 and T. Wright, "Transport Layer Security (TLS) 573 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 574 . 576 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 577 Text on Security Considerations", BCP 72, RFC 3552, 578 DOI 10.17487/RFC3552, July 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 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 602 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 603 DOI 10.17487/RFC7540, May 2015, 604 . 606 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 607 Security (TLS) in the Extensible Messaging and Presence 608 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 609 2015, . 611 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 612 and P. Hoffman, "Specification for DNS over Transport 613 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 614 2016, . 616 [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: 617 Use of Transport Layer Security (TLS) for Email Submission 618 and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, 619 . 621 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 622 RFC 8336, DOI 10.17487/RFC8336, March 2018, 623 . 625 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 626 Pervasive Encryption on Operators", RFC 8404, 627 DOI 10.17487/RFC8404, July 2018, 628 . 630 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 631 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 632 . 634 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 635 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 636 . 638 Authors' Addresses 640 Christian Huitema 641 Private Octopus Inc. 642 Friday Harbor WA 98250 643 U.S.A 645 Email: huitema@huitema.net 647 Eric Rescorla 648 RTFM, Inc. 649 U.S.A 651 Email: ekr@rtfm.com