idnits 2.17.1 draft-ietf-tls-sni-encryption-04.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 (November 22, 2018) is 1979 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-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-16 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-30 -- 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: May 26, 2019 RTFM, Inc. 6 November 22, 2018 8 Issues and Requirements for SNI Encryption in TLS 9 draft-ietf-tls-sni-encryption-04 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 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 May 26, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 4 64 3. Security and Privacy Requirements for SNI Encryption . . . . 5 65 3.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 6 69 3.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 6 70 3.6. Proper Security Context . . . . . . . . . . . . . . . . . 7 71 3.7. Fronting Server Spoofing . . . . . . . . . . . . . . . . 7 72 3.8. Supporting multiple protocols . . . . . . . . . . . . . . 7 73 3.8.1. Hiding the Application Layer Protocol Negotiation . . 8 74 3.8.2. Support other transports than HTTP . . . . . . . . . 8 75 4. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 8 76 4.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 9 77 4.2. Delegation Control . . . . . . . . . . . . . . . . . . . 10 78 4.3. Related work . . . . . . . . . . . . . . . . . . . . . . 10 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 8. Informative References . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 Historically, adversaries have been able to monitor the use of web 88 services through three channels: looking at DNS requests, looking at 89 IP addresses in packet headers, and looking at the data stream 90 between user and services. These channels are getting progressively 91 closed. A growing fraction of Internet communication is encrypted, 92 mostly using Transport Layer Security (TLS) [RFC5246]. Progressive 93 deployment of solutions like DNS in TLS [RFC7858] mitigates the 94 disclosure of DNS information. More and more services are colocated 95 on multiplexed servers, loosening the relation between IP address and 96 web service. However, multiplexed servers rely on the Service Name 97 Information (SNI) to direct TLS connections to the appropriate 98 service implementation. This protocol element is transmitted in 99 clear text. As the other methods of monitoring get blocked, 100 monitoring focuses on the clear text SNI. The purpose of SNI 101 encryption is to prevent that. 103 In the past, there have been multiple attempts at defining SNI 104 encryption. These attempts have generally floundered, because the 105 simple designs fail to mitigate several of the attacks listed in 106 Section 3. In the absence of a TLS level solution, the most popular 107 approach to SNI privacy is HTTP level fronting, which we discuss in 108 Section 4. 110 2. History of the TLS SNI extension 112 The SNI extension was standardized in 2003 in [RFC3546] to facilitate 113 management of "colocation servers", in which a multiple services 114 shared the same IP address. A typical example would be mutiple web 115 sites served by the same web server. The SNI extension carries the 116 name of a specific server, enabling the TLS connection to be 117 established with the desired server context. The current SNI 118 extension specification can be found in [RFC6066]. 120 The SNI specification allowed for different types of server names, 121 but only the "hostname" variant was standardized and deployed. In 122 that variant, the SNI extension carries the domain name of the target 123 server. The SNI extension is carried in clear text in the TLS 124 "Client Hello" message. 126 2.1. Unanticipated usage of SNI information 128 The SNI was defined to facilitate management of servers, but the 129 developer of middleboxes soon found out that they could take 130 advantage of the information. Many examples of such usage are 131 reviewed in [RFC8404]. They include: 133 o Censorship of specific sites by "national firewalls", 135 o Content filtering by ISP blocking specific web sites in order to 136 implement "parental controls", or to prevent access to fraudulent 137 web sites, such as used for phishing, 139 o ISP assigning different QOS profiles to target services, 141 o Enterprise firewalls blocking web sites not deemed appropriate for 142 work, or 144 o Enterprise firewalls exempting specific web sites from MITM 145 inspection, such as healthcare or financial sites for which 146 inspection would intrude with the privacy of employees. 148 The SNI is probably also included in the general collection of 149 metadata by pervasive surveillance actors. 151 2.2. SNI encryption timeliness 153 The clear-text transmission of the SNI was not flagged as a problem 154 in the security consideration sections of [RFC3546], [RFC4366], or 155 [RFC6066]. These specifications did not anticipate the alternative 156 uses and abuses described in Section 2.1. One reason may be that, 157 when these RFCs were written, the SNI information was available 158 through a variety of other means. 160 Many deployments still allocate different IP addresses to different 161 services, so that different services can be identified by their IP 162 addresses. However, content distribution networks (CDN) commonly 163 serve a large number of services through a small number of addresses. 165 The SNI carries the domain name of the server, which is also sent as 166 part of the DNS queries. Most of the SNI usage described in 167 Section 2.1 could also be implemented by monitoring DNS traffic or 168 controlling DNS usage. But this is changing with the advent of DNS 169 resolvers providing services like DNS over TLS [RFC7858] or DNS over 170 HTTPS [RFC8484]. 172 The subjectAltName extension of type dNSName of the server 173 certificate, or in its absence the common name component, expose the 174 same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346], 175 and 1.2 [RFC5246], the server send their certificate in clear text, 176 ensuring that there would be limited benefits in hiding the SNI. But 177 the transmission of the server certificate is protected in TLS 1.3 178 [RFC8446]. 180 The decoupling of IP addresses and server names, the deployment of 181 DNS privacy, and the protection of server certificates transmissions 182 all contribute to user privacy. Encrypting the SNI now will complete 183 this push for privacy and make it harder to censor specific internet 184 services. 186 2.3. End-to-end alternatives 188 Deploying SNI encryption will help thwarting most of the 189 "unanticipated" SNI usages described in Section 2.1, including 190 censorship and pervasive surveillance. It will also thwart functions 191 that are sometimes described as legitimate. Most of these functions 192 can however be realized by other means. For example, some DNS 193 service providers offer customers the provision to "opt in" filtering 194 services for parental control and phishing protection. Per stream 195 QoS can be provided by a combination of packet marking and end to end 196 agreements. As SNI encryption becomes common, we can expect more 197 deployment of such "end to end" solutions. 199 At the moment enterprises have the option of installing a firewall 200 performing SNI filtering to prevent connections to certain websites. 201 With SNI encryption this becomes ineffective. Obviously, managers 202 could block usage of SNI encryption in enterprise computers, but this 203 wide scale blocking would diminish the privacy protection of traffic 204 leaving the enterprise, which may not be desirable. Enterprises 205 managers could rely instead on filtering software and management 206 software deployed on enterprises computers. 208 3. Security and Privacy Requirements for SNI Encryption 210 Over the past years, there have been multiple proposals to add an SNI 211 encryption option in TLS. Many of these proposals appeared 212 promising, but were rejected after security reviews pointed plausible 213 attacks. In this section, we collect a list of these known attacks. 215 3.1. Mitigate Replay Attacks 217 The simplest SNI encryption designs replace in the initial TLS 218 exchange the clear text SNI with an encrypted value, using a key 219 known to the multiplexed server. Regardless of the encryption used, 220 these designs can be broken by a simple replay attack, which works as 221 follow: 223 1- The user starts a TLS connection to the multiplexed server, 224 including an encrypted SNI value. 226 2- The adversary observes the exchange and copies the encrypted SNI 227 parameter. 229 3- The adversary starts its own connection to the multiplexed server, 230 including in its connection parameters the encrypted SNI copied from 231 the observed exchange. 233 4- The multiplexed server establishes the connection to the protected 234 service, thus revealing the identity of the service. 236 One of the goals of SNI encryption is to prevent adversaries from 237 knowing which Hidden Service the client is using. Successful replay 238 attacks breaks that goal by allowing adversaries to discover that 239 service. 241 3.2. Avoid Widely Shared Secrets 243 It is easy to think of simple schemes in which the SNI is encrypted 244 or hashed using a shared secret. This symmetric key must be known by 245 the multiplexed server, and by every users of the protected services. 246 Such schemes are thus very fragile, since the compromise of a single 247 user would compromise the entire set of users and protected services. 249 3.3. Prevent SNI-based Denial of Service Attacks 251 Encrypting the SNI may create extra load for the multiplexed server. 252 Adversaries may mount denial of service attacks by generating random 253 encrypted SNI values and forcing the multiplexed server to spend 254 resources in useless decryption attempts. 256 It may be argued that this is not an important DOS avenue, as regular 257 TLS connection attempts also require the server to perform a number 258 of cryptographic operations. However, in many cases, the SNI 259 decryption will have to be performed by a front end component with 260 limited resources, while the TLS operations are performed by the 261 component dedicated to their respective services. SNI based DOS 262 attacks could target the front end component. 264 3.4. Do not stick out 266 In some designs, handshakes using SNI encryption can be easily 267 differentiated from "regular" handshakes. For example, some designs 268 require specific extensions in the Client Hello packets, or specific 269 values of the clear text SNI parameter. If adversaries can easily 270 detect the use of SNI encryption, they could block it, or they could 271 flag the users of SNI encryption for special treatment. 273 In the future, it might be possible to assume that a large fraction 274 of TLS handshakes use SNI encryption. If that was the case, the 275 detection of SNI encryption would be a lesser concern. However, we 276 have to assume that in the near future, only a small fraction of TLS 277 connections will use SNI encryption. 279 3.5. Forward Secrecy 281 The general concerns about forward secrecy apply to SNI encryption 282 just as well as to regular TLS sessions. For example, some proposed 283 designs rely on a public key of the multiplexed server to define the 284 SNI encryption key. If the corresponding private key was 285 compromised, the adversaries would be able to process archival 286 records of past connections, and retrieve the protected SNI used in 287 these connections. These designs failed to maintain forward secrecy 288 of SNI encryption. 290 3.6. Proper Security Context 292 We can design solutions in which a fronting service act as a relay to 293 reach the protected service. Some of those solutions involve just 294 one TLS handshake between the client and the fronting service. The 295 master secret is verified by verifying a certificate provided by the 296 fronting service, but not by the protected service. These solutions 297 expose the client to a Man-In-The-Middle attack by the fronting 298 service. Even if the client has some reasonable trust in this 299 services, the possibility of MITM attack is troubling. 301 There are other classes of solutions in which the master secret is 302 verified by verifying a certificate provided by the protected 303 service. These solutions offer more protection against a Man-In-The- 304 Middle attack by the fronting service. 306 The fronting service could be pressured by adversaries. By design, 307 it could be forced to deny access to the protected service, or to 308 divulge which client accessed it. But if MITM is possible, the 309 adversaries would also be able to pressure the fronting service into 310 intercepting or spoofing the communications between client and 311 protected service. 313 3.7. Fronting Server Spoofing 315 Adversaries could mount an attack by spoofing the Fronting Service. 316 A spoofed Fronting Service could act as a "honeypot" for users of 317 hidden services. At a minimum, the fake server could record the IP 318 addresses of these users. If the SNI encryption solution places too 319 much trust on the fronting server, the fake server could also serve 320 fake content of its own choosing, including various forms of malware. 322 There are two main channels by which adversaries can conduct this 323 attack. Adversaries can simply try to mislead users into believing 324 that the honeypot is a valid Fronting Server, especially if that 325 information is carried by word of mouth or in unprotected DNS 326 records. Adversaries can also attempt to hijack the traffic to the 327 regular Fronting Server, using for example spoofed DNS responses or 328 spoofed IP level routing, combined with a spoofed certificate. 330 3.8. Supporting multiple protocols 332 The SNI encryption requirement does not stop with HTTP over TLS. 333 Multiple other applications currently use TLS, including for example 334 SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. These applications 335 too will benefit of SNI encryption. HTTP only methods like those 336 described in Section 4.1 would not apply there. In fact, even for 337 the HTTPS case, the HTTPS tunneling service described in Section 4.1 338 is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly 339 with the multiple streams feature of HTTP 2.0 [RFC7540]. This points 340 to the need of an application agnostic solution, that would be 341 implemented fully in the TLS layer. 343 3.8.1. Hiding the Application Layer Protocol Negotiation 345 The Application Layer Protocol Negotiation (ALPN) parameters of TLS 346 allow implementations to negotiate the application layer protocol 347 used on a given connection. TLS provides the ALPN values in clear 348 text during the initial handshake. While exposing the ALPN does not 349 create the same privacy issues as exposing the SNI, there is still a 350 risk. For example, some networks may attempt to block applications 351 that they do not understand, or that they wish users would not use. 353 In a sense, ALPN filtering could be very similar to the filtering of 354 specific port numbers exposed in some network. This filtering by 355 ports has given rise to evasion tactics in which various protocols 356 are tunneled over HTTP in order to use open ports 80 or 443. 357 Filtering by ALPN would probably beget the same responses, in which 358 the applications just move over HTTP, and only the HTTP ALPN values 359 are used. Applications would not need to do that if the ALPN was 360 hidden in the same way as the SNI. 362 In addition to hiding the SNI, it is thus desirable to also hide the 363 ALPN. Of course, this implies engineering trade-offs. Using the 364 same technique for hiding the ALPN and encrypting the SNI may result 365 in excess complexity. It might be preferable to encrypt these 366 independently. 368 3.8.2. Support other transports than HTTP 370 The TLS handshake is also used over other transports such as UDP with 371 both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls]. The 372 requirement to encrypt the SNI apply just as well for these 373 transports as for TLS over TCP. 375 This points to a requirement for SNI Encryption mechanisms to also be 376 applicable to non-TCP transports such as DTLS or QUIC. 378 4. HTTP Co-Tenancy Fronting 380 In the absence of TLS level SNI encryption, many sites rely on an 381 "HTTP Co-Tenancy" solution. The TLS connection is established with 382 the fronting server, and HTTP requests are then sent over that 383 connection to the hidden service. For example, the TLS SNI could be 384 set to "fronting.example.com", the fronting server, and HTTP requests 385 sent over that connection could be directed to "hidden.example.com", 386 accessing the hidden service. This solution works well in practice 387 when the fronting server and the hidden server are "co-tenant" of the 388 same multiplexed server. 390 The HTTP fronting solution can be deployed without modification to 391 the TLS protocol, and does not require using any specific version of 392 TLS. There are however a few issues regarding discovery, client 393 implementations, trust, and applicability: 395 o The client has to discover that the hidden service can be accessed 396 through the fronting server. 398 o The client browser's has to be directed to access the hidden 399 service through the fronting service. 401 o Since the TLS connection is established with the fronting service, 402 the client has no proof that the content does in fact come from 403 the hidden service. The solution does thus not mitigate the 404 context sharing issues described in Section 3.6. 406 o Since this is an HTTP level solution, it would not protect non 407 HTTP protocols such as DNS over TLS [RFC7858] or IMAP over TLS 408 [RFC2595]. 410 The discovery issue is common to pretty much every SNI encryption 411 solution. The browser issue may be solved by developing a browser 412 extension that support HTTP Fronting, and manages the list of 413 fronting services associated with the hidden services that the client 414 uses. The multi-protocol issue can be mitigated by using 415 implementation of other applications over HTTP, such as for example 416 DNS over HTTPS [RFC8484]. The trust issue, however, requires 417 specific developments. 419 4.1. HTTPS Tunnels 421 The HTTP Fronting solution places a lot of trust in the Fronting 422 Server. This required trust can be reduced by tunnelling HTTPS in 423 HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. 424 In this solution, the client establishes a TLS connection to the 425 Fronting Server, and then issues an HTTP Connect request to the 426 Hidden Server. This will establish an end-to-end HTTPS over TLS 427 connection between the client and the Hidden Server, mitigating the 428 issues described in Section 3.6. 430 The HTTPS in HTTPS solution requires double encryption of every 431 packet. It also requires that the fronting server decrypts and relay 432 messages to the hidden server. Both of these requirements make the 433 implementation onerous. 435 4.2. Delegation Control 437 Clients would see their privacy compromised if they contacted the 438 wrong fronting server to access the hidden service, since this wrong 439 server could disclose their access to adversaries. This requires a 440 controlled way to indicate which fronting ferver is acceptable by the 441 hidden service. 443 This problem is both similar and different from the "fronting server 444 spoofing" attack described in Section 3.7. Here, the spoofing would 445 be performed by distributing fake advice, such as "to reach example 446 hidden.example.com, use fake.example.com as a fronting server", when 447 "fake.example.com" is under the control of an adversary. 449 In practice, this attack is well mitigated when the hidden service is 450 accessed through a specialized application. The name of the fronting 451 server can then be programmed in the code of the application. But 452 the attack is much harder to mitigate when the hidden service has to 453 be accessed through general purpose web browsers. The browsers will 454 need a mechanism to obtain the fronting server indication in a secure 455 way. 457 There are several proposed solutions to this problem, such as 458 creating a special form of certificate to codify the relation between 459 fronting and hidden server, or obtaining the relation between hidden 460 and fronting service through the DNS, possibly using DNSSEC to avoid 461 spoofing. 463 We can observe that content distribution network have a similar 464 requirement. They need to convince the client that "www.example.com" 465 can be accessed through the seemingly unrelated "cdn-node- 466 xyz.example.net". Most CDN have deployed DNS-based solutions to this 467 problem. 469 4.3. Related work 471 The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag 472 content provided by the hidden server. Secondary certificate 473 authentication [I-D.ietf-httpbis-http2-secondary-certs] can be used 474 to manage authentication of hidden server content, or to perform 475 client authentication before accessing hidden content. 477 5. Security Considerations 479 Replacing clear text SNI transmission by an encrypted variant will 480 improve the privacy and reliability of TLS connections, but the 481 design of proper SNI encryption solutions is difficult. This 482 document does not present the design of a solution, but provide 483 guidelines for evaluating proposed solutions. 485 This document lists a number of attacks against SNI encryption in 486 Section 3, and also in Section 4.2, and presents a list of 487 requirements to mitigate these attacks. The current HTTP based 488 solutions described in Section 4 only meet some of these 489 requirements. In practice, it may well be that no solution can meet 490 every requirement, and that practical solutions will have to make 491 some compromises. 493 In particular, the requirement to not stick out presented in 494 Section 3.4 may have to be lifted, especially for proposed solutions 495 that could quickly reach large scale deployments. 497 6. IANA Considerations 499 This draft does not require any IANA action. 501 7. Acknowledgements 503 A large part of this draft originates in discussion of SNI encryption 504 on the TLS WG mailing list, including comments after the tunneling 505 approach was first proposed in a message to that list: 506 . 509 Thanks to Daniel Kahn Gillmor for a pretty detailed review of the 510 initial draft. Thanks to Stephen Farrell, Mark Orchezowski, Martin 511 Rex and Martin Thomson for their reviews. 513 8. Informative References 515 [I-D.ietf-httpbis-http2-secondary-certs] 516 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 517 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 518 http2-secondary-certs-03 (work in progress), October 2018. 520 [I-D.ietf-quic-tls] 521 Thomson, M. and S. Turner, "Using Transport Layer Security 522 (TLS) to Secure QUIC", draft-ietf-quic-tls-16 (work in 523 progress), October 2018. 525 [I-D.ietf-tls-dtls13] 526 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 527 Datagram Transport Layer Security (DTLS) Protocol Version 528 1.3", draft-ietf-tls-dtls13-30 (work in progress), 529 November 2018. 531 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 532 RFC 2246, DOI 10.17487/RFC2246, January 1999, 533 . 535 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 536 RFC 2595, DOI 10.17487/RFC2595, June 1999, 537 . 539 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 540 and T. Wright, "Transport Layer Security (TLS) 541 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 542 . 544 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 545 (TLS) Protocol Version 1.1", RFC 4346, 546 DOI 10.17487/RFC4346, April 2006, 547 . 549 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 550 and T. Wright, "Transport Layer Security (TLS) 551 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 552 . 554 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 555 (TLS) Protocol Version 1.2", RFC 5246, 556 DOI 10.17487/RFC5246, August 2008, 557 . 559 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 560 Extensions: Extension Definitions", RFC 6066, 561 DOI 10.17487/RFC6066, January 2011, 562 . 564 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 565 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 566 DOI 10.17487/RFC7540, May 2015, 567 . 569 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 570 Security (TLS) in the Extensible Messaging and Presence 571 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 572 2015, . 574 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 575 and P. Hoffman, "Specification for DNS over Transport 576 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 577 2016, . 579 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 580 RFC 8336, DOI 10.17487/RFC8336, March 2018, 581 . 583 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 584 Pervasive Encryption on Operators", RFC 8404, 585 DOI 10.17487/RFC8404, July 2018, 586 . 588 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 589 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 590 . 592 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 593 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 594 . 596 Authors' Addresses 598 Christian Huitema 599 Private Octopus Inc. 600 Friday Harbor WA 98250 601 U.S.A 603 Email: huitema@huitema.net 605 Eric Rescorla 606 RTFM, Inc. 607 U.S.A 609 Email: ekr@rtfm.com