idnits 2.17.1 draft-ietf-tls-sni-encryption-05.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 (August 15, 2019) is 1713 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3552' is defined on line 549, 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-22 == 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: February 16, 2020 RTFM, Inc. 6 August 15, 2019 8 Issues and Requirements for SNI Encryption in TLS 9 draft-ietf-tls-sni-encryption-05 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 February 16, 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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 11 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 8. Informative References . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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. However, 96 multiplexed servers rely on the Service Name Information (SNI) TLS 97 extension to direct connections to the appropriate service 98 implementation. This protocol element is transmitted in clear text. 99 As the other methods of monitoring get blocked, monitoring focuses on 100 the clear text SNI. The purpose of SNI encryption and privacy is to 101 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 for web services is HTTP-level fronting, 108 which we discuss in Section 4. 110 2. History of the TLS SNI extension 112 The SNI extension was specified in 2003 in [RFC3546] to facilitate 113 management of "colocation servers", in which multiple services shared 114 the same IP address. A typical example would be mutiple web sites 115 served by the same web server. The SNI extension carries the name of 116 a specific server, enabling the TLS connection to be established with 117 the desired server context. The current SNI extension specification 118 can be found in [RFC6066]. 120 The SNI specification allowed for different types of server names, 121 though only the "hostname" variant was specified 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 "ClientHello" message. 126 2.1. Unanticipated usage of SNI information 128 The SNI was defined to facilitate management of servers, though the 129 developers 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 Monitoring and identification of specific sites, 135 o Content filtering by ISP blocking specific web sites in order to 136 implement "parental controls", or to prevent access to phishing or 137 other fradulent web sites. 139 o ISP assigning different QoS profiles to target services, 141 o Firewalls within enterprise networks blocking web sites not deemed 142 appropriate for work, or 144 o Firewalls within enterprise networks exempting specific web sites 145 from MITM inspection, such as healthcare or financial sites for 146 which 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 comparatively small number 164 of addresses. 166 The SNI carries the domain name of the server, which is also sent as 167 part of the DNS queries. Most of the SNI usage described in 168 Section 2.1 could also be implemented by monitoring DNS traffic or 169 controlling DNS usage. But this is changing with the advent of DNS 170 resolvers providing services like DNS over TLS [RFC7858] or DNS over 171 HTTPS [RFC8484]. 173 The subjectAltName extension of type dNSName of the server 174 certificate, or in its absence the common name component, expose the 175 same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346], 176 and 1.2 [RFC5246], servers send certificates in clear text, ensuring 177 that there would be limited benefits in hiding the SNI. However, in 178 TLS 1.3 [RFC8446], server certificates are encrypted in transit. 179 Note that encryption alone is insufficient to protect server 180 certificates; see Section 3.1 for details. 182 The decoupling of IP addresses and server names, deployment of DNS 183 privacy, and protection of server certificates transmissions all 184 contribute to user privacy in the face of an [RFC3552]-style 185 adversary. Encrypting the SNI now will complete this push for 186 privacy and make it harder to censor or otherwise provide 187 differential treatment to specific internet services. 189 2.3. End-to-end alternatives 191 Deploying SNI encryption will help thwarting most of the 192 "unanticipated" SNI usages described in Section 2.1, including 193 censorship and pervasive surveillance. It will also thwart functions 194 that are sometimes described as legitimate. Most of these functions 195 can however be realized by other means. For example, some DNS 196 service providers offer customers the provision to "opt in" filtering 197 services for parental control and phishing protection. Per-stream 198 QoS can be provided by a combination of packet marking and end-to-end 199 agreements. As SNI encryption becomes common, we can expect more 200 deployment of such "end-to-end" solutions. 202 At the moment, enterprises have the option of installing a firewall 203 performing SNI filtering to prevent connections to certain websites. 204 With SNI encryption this becomes ineffective. Obviously, managers 205 could block usage of SNI encryption in enterprise computers, but this 206 wide-scale blocking would diminish the privacy protection of traffic 207 leaving the enterprise, which may not be desirable. Enterprise 208 managers could rely instead on filtering software and management 209 software deployed on the enterprise's computers. 211 3. Security and Privacy Requirements for SNI Encryption 213 Over the past years, there have been multiple proposals to add an SNI 214 encryption option in TLS. Many of these proposals appeared 215 promising, though were rejected after security reviews identified 216 plausible attacks. In this section, we collect a list of these known 217 attacks. 219 3.1. Mitigate Replay Attacks 221 The simplest SNI encryption designs replace in the initial TLS 222 exchange the clear text SNI with an encrypted value, using a key 223 known to the multiplexed server. Regardless of the encryption used, 224 these designs can be broken by a simple replay attack, which works as 225 follow: 227 1- The user starts a TLS connection to the multiplexed server, 228 including an encrypted SNI value. 230 2- The adversary observes the exchange and copies the encrypted SNI 231 parameter. 233 3- The adversary starts its own connection to the multiplexed server, 234 including in its connection parameters the encrypted SNI copied from 235 the observed exchange. 237 4- The multiplexed server establishes the connection to the protected 238 service, thus revealing the identity of the service. 240 One of the goals of SNI encryption is to prevent adversaries from 241 knowing which Hidden Service the client is using. Successful replay 242 attacks breaks that goal by allowing adversaries to discover that 243 service. 245 3.2. Avoid Widely Shared Secrets 247 It is easy to think of simple schemes in which the SNI is encrypted 248 or hashed using a shared secret. This symmetric key must be known by 249 the multiplexed server, and by every users of the protected services. 250 Such schemes are thus very fragile, since the compromise of a single 251 user would compromise the entire set of users and protected services. 253 3.3. Prevent SNI-based Denial of Service Attacks 255 Encrypting the SNI may create extra load for the multiplexed server. 256 Adversaries may mount denial of service attacks by generating random 257 encrypted SNI values and forcing the multiplexed server to spend 258 resources in useless decryption attempts. 260 It may be argued that this is not an important DOS avenue, as regular 261 TLS connection attempts also require the server to perform a number 262 of cryptographic operations. However, in many cases, the SNI 263 decryption will have to be performed by a front-end component with 264 limited resources, while the TLS operations are performed by the 265 component dedicated to their respective services. SNI-based DOS 266 attacks could target the front-end component. 268 3.4. Do not stick out 270 In some designs, handshakes using SNI encryption can be easily 271 differentiated from "regular" handshakes. For example, some designs 272 require specific extensions in the Client Hello packets, or specific 273 values of the clear text SNI parameter. If adversaries can easily 274 detect the use of SNI encryption, they could block it, or they could 275 flag the users of SNI encryption for special treatment. 277 In the future, it might be possible to assume that a large fraction 278 of TLS handshakes use SNI encryption. If that was the case, the 279 detection of SNI encryption would be a lesser concern. However, we 280 have to assume that in the near future, only a small fraction of TLS 281 connections will use SNI encryption. 283 3.5. Forward Secrecy 285 The general concerns about forward secrecy apply to SNI encryption 286 just as well as to regular TLS sessions. For example, some proposed 287 designs rely on a public key of the multiplexed server to define the 288 SNI encryption key. If the corresponding private key was 289 compromised, the adversaries would be able to process archival 290 records of past connections, and retrieve the protected SNI used in 291 these connections. These designs failed to maintain forward secrecy 292 of SNI encryption. 294 3.6. Multi-Party Security Contexts 296 We can design solutions in which a fronting service act as a relay to 297 reach the protected service. Some of those solutions involve just 298 one TLS handshake between the client and the fronting service. The 299 master secret is verified by verifying a certificate provided by the 300 fronting service, but not by the protected service. These solutions 301 expose the client to a Man-In-The-Middle attack by the fronting 302 service. Even if the client has some reasonable trust in this 303 service, the possibility of MITM attack is troubling. 305 There are other classes of solutions in which the master secret is 306 verified by verifying a certificate provided by the protected 307 service. These solutions offer more protection against a Man-In-The- 308 Middle attack by the fronting service. The downside is the the 309 client will not verify the identity of the fronting service with 310 risks discussed in , but solutions will have to mitigate this risks. 311 Overall, end-to-end TLS to the protected service is preferable. 313 The fronting service could be pressured by adversaries. By design, 314 it could be forced to deny access to the protected service, or to 315 divulge which client accessed it. But if MITM is possible, the 316 adversaries would also be able to pressure the fronting service into 317 intercepting or spoofing the communications between client and 318 protected service. 320 Adversaries could also mount an attack by spoofing the fronting 321 service. A spoofed fronting service could act as a "honeypot" for 322 users of hidden services. At a minimum, the fake server could record 323 the IP addresses of these users. If the SNI encryption solution 324 places too much trust on the fronting server, the fake server could 325 also serve fake content of its own choosing, including various forms 326 of malware. 328 There are two main channels by which adversaries can conduct this 329 attack. Adversaries can simply try to mislead users into believing 330 that the honeypot is a valid fronting server, especially if that 331 information is carried by word of mouth or in unprotected DNS 332 records. Adversaries can also attempt to hijack the traffic to the 333 regular fronting server, using for example spoofed DNS responses or 334 spoofed IP level routing, combined with a spoofed certificate. 336 3.7. Supporting multiple protocols 338 The SNI encryption requirement does not stop with HTTP over TLS. 339 Multiple other applications currently use TLS, including for example 340 SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. These applications 341 too will benefit of SNI encryption. HTTP only methods like those 342 described in Section 4.1 would not apply there. In fact, even for 343 the HTTPS case, the HTTPS tunneling service described in Section 4.1 344 is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly 345 with the multiple streams feature of HTTP 2.0 [RFC7540]. This points 346 to the need of an application-agnostic solution, that would be 347 implemented fully in the TLS layer. 349 3.7.1. Hiding the Application Layer Protocol Negotiation 351 The Application Layer Protocol Negotiation (ALPN) parameters of TLS 352 allow implementations to negotiate the application layer protocol 353 used on a given connection. TLS provides the ALPN values in clear 354 text during the initial handshake. While exposing the ALPN does not 355 create the same privacy issues as exposing the SNI, there is still a 356 risk. For example, some networks may attempt to block applications 357 that they do not understand, or that they wish users would not use. 359 In a sense, ALPN filtering could be very similar to the filtering of 360 specific port numbers exposed in some network. This filtering by 361 ports has given rise to evasion tactics in which various protocols 362 are tunneled over HTTP in order to use open ports 80 or 443. 363 Filtering by ALPN would probably beget the same responses, in which 364 the applications just move over HTTP, and only the HTTP ALPN values 365 are used. Applications would not need to do that if the ALPN was 366 hidden in the same way as the SNI. 368 In addition to hiding the SNI, it is thus desirable to also hide the 369 ALPN. Of course, this implies engineering trade-offs. Using the 370 same technique for hiding the ALPN and encrypting the SNI may result 371 in excess complexity. It might be preferable to encrypt these 372 independently. 374 3.7.2. Support other transports than TCP 376 The TLS handshake is also used over other transports such as UDP with 377 both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls]. The 378 requirement to encrypt the SNI apply just as well for these 379 transports as for TLS over TCP. 381 This points to a requirement for SNI Encryption mechanisms to also be 382 applicable to non-TCP transports such as DTLS or QUIC. 384 4. HTTP Co-Tenancy Fronting 386 In the absence of TLS-level SNI encryption, many sites rely on an 387 "HTTP Co-Tenancy" solution. The TLS connection is established with 388 the fronting server, and HTTP requests are then sent over that 389 connection to the hidden service. For example, the TLS SNI could be 390 set to "fronting.example.com", the fronting server, and HTTP requests 391 sent over that connection could be directed to "hidden.example.com", 392 accessing the hidden service. This solution works well in practice 393 when the fronting server and the hidden server are "co-tenant" of the 394 same multiplexed server. 396 The HTTP fronting solution can be deployed without modification to 397 the TLS protocol, and does not require using any specific version of 398 TLS. There are however a few issues regarding discovery, client 399 implementations, trust, and applicability: 401 o The client has to discover that the hidden service can be accessed 402 through the fronting server. 404 o The client browser's has to be directed to access the hidden 405 service through the fronting service. 407 o Since the TLS connection is established with the fronting service, 408 the client has no cryptographic proof that the content does in 409 fact come from the hidden service. The solution does thus not 410 mitigate the context sharing issues described in Section 3.6. 412 o Since this is an HTTP-level solution, it would not protect non- 413 HTTP protocols such as DNS over TLS [RFC7858] or IMAP over TLS 414 [RFC2595]. 416 The discovery issue is common to most SNI encryption solutions. The 417 browser issue may be solved by developing a browser extension that 418 support HTTP Fronting, and manages the list of fronting services 419 associated with the hidden services that the client uses. The multi- 420 protocol issue can be mitigated by using implementation of other 421 applications over HTTP, such as for example DNS over HTTPS [RFC8484]. 422 The trust issue, however, requires specific developments. 424 4.1. HTTPS Tunnels 426 The HTTP Fronting solution places a lot of trust in the Fronting 427 Server. This required trust can be reduced by tunnelling HTTPS in 428 HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. 429 In this solution, the client establishes a TLS connection to the 430 Fronting Server, and then issues an HTTP Connect request to the 431 Hidden Server. This will establish an end-to-end HTTPS over TLS 432 connection between the client and the Hidden Server, mitigating the 433 issues described in Section 3.6. 435 The HTTPS in HTTPS solution requires double encryption of every 436 packet. It also requires that the fronting server decrypts and relay 437 messages to the hidden server. Both of these requirements make the 438 implementation onerous. 440 4.2. Delegation Control 442 Clients would see their privacy compromised if they contacted the 443 wrong fronting server to access the hidden service, since this wrong 444 server could disclose their access to adversaries. This requires a 445 controlled way to indicate which fronting ferver is acceptable by the 446 hidden service. 448 This problem is both similar and different from the "fronting server 449 spoofing" attack described in Section 3.6. Here, the spoofing would 450 be performed by distributing fake advice, such as "to reach example 451 hidden.example.com, use fake.example.com as a fronting server", when 452 "fake.example.com" is under the control of an adversary. 454 In practice, this attack is well mitigated when the hidden service is 455 accessed through a specialized application. The name of the fronting 456 server can then be programmed in the code of the application. But 457 the attack is much harder to mitigate when the hidden service has to 458 be accessed through general purpose web browsers. The browsers will 459 need a mechanism to obtain the fronting server indication in a secure 460 way. 462 There are several proposed solutions to this problem, such as 463 creating a special form of certificate to codify the relation between 464 fronting and hidden server, or obtaining the relation between hidden 465 and fronting service through the DNS, possibly using DNSSEC to avoid 466 spoofing. 468 We can observe that content distribution network have a similar 469 requirement. They need to convince the client that "www.example.com" 470 can be accessed through the seemingly unrelated "cdn-node- 471 xyz.example.net". Most CDNs have deployed DNS-based solutions to 472 this problem. 474 4.3. Related work 476 The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag 477 content provided by the hidden server. Secondary certificate 478 authentication [I-D.ietf-httpbis-http2-secondary-certs] can be used 479 to manage authentication of hidden server content, or to perform 480 client authentication before accessing hidden content. 482 5. Security Considerations 484 Replacing clear text SNI transmission by an encrypted variant will 485 improve the privacy and reliability of TLS connections, but the 486 design of proper SNI encryption solutions is difficult. This 487 document does not present the design of a solution, but provides 488 guidelines for evaluating proposed solutions. 490 This document lists a number of attacks against SNI encryption in 491 Section 3, and also in Section 4.2, and presents a list of 492 requirements to mitigate these attacks. The current HTTP based 493 solutions described in Section 4 only meet some of these 494 requirements. In practice, it may well be that no solution can meet 495 every requirement, and that practical solutions will have to make 496 some compromises. 498 In particular, the requirement to not stick out presented in 499 Section 3.4 may have to be lifted, especially for proposed solutions 500 that could quickly reach large scale deployments. 502 6. IANA Considerations 504 This draft does not require any IANA action. 506 7. Acknowledgements 508 A large part of this draft originates in discussion of SNI encryption 509 on the TLS WG mailing list, including comments after the tunneling 510 approach was first proposed in a message to that list: 511 . 514 Thanks to Daniel Kahn Gillmor for a pretty detailed review of the 515 initial draft. Thanks to Stephen Farrell, Martin Rex Martin Thomson 516 and employees of the UK National Cyber Security Centre for their 517 reviews. 519 8. Informative References 521 [I-D.ietf-httpbis-http2-secondary-certs] 522 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 523 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 524 http2-secondary-certs-04 (work in progress), April 2019. 526 [I-D.ietf-quic-tls] 527 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 528 draft-ietf-quic-tls-22 (work in progress), July 2019. 530 [I-D.ietf-tls-dtls13] 531 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 532 Datagram Transport Layer Security (DTLS) Protocol Version 533 1.3", draft-ietf-tls-dtls13-32 (work in progress), July 534 2019. 536 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 537 RFC 2246, DOI 10.17487/RFC2246, January 1999, 538 . 540 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 541 RFC 2595, DOI 10.17487/RFC2595, June 1999, 542 . 544 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 545 and T. Wright, "Transport Layer Security (TLS) 546 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 547 . 549 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 550 Text on Security Considerations", BCP 72, RFC 3552, 551 DOI 10.17487/RFC3552, July 2003, 552 . 554 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 555 (TLS) Protocol Version 1.1", RFC 4346, 556 DOI 10.17487/RFC4346, April 2006, 557 . 559 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 560 and T. Wright, "Transport Layer Security (TLS) 561 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 562 . 564 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 565 (TLS) Protocol Version 1.2", RFC 5246, 566 DOI 10.17487/RFC5246, August 2008, 567 . 569 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 570 Extensions: Extension Definitions", RFC 6066, 571 DOI 10.17487/RFC6066, January 2011, 572 . 574 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 575 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 576 DOI 10.17487/RFC7540, May 2015, 577 . 579 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 580 Security (TLS) in the Extensible Messaging and Presence 581 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 582 2015, . 584 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 585 and P. Hoffman, "Specification for DNS over Transport 586 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 587 2016, . 589 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 590 RFC 8336, DOI 10.17487/RFC8336, March 2018, 591 . 593 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 594 Pervasive Encryption on Operators", RFC 8404, 595 DOI 10.17487/RFC8404, July 2018, 596 . 598 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 599 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 600 . 602 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 603 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 604 . 606 Authors' Addresses 607 Christian Huitema 608 Private Octopus Inc. 609 Friday Harbor WA 98250 610 U.S.A 612 Email: huitema@huitema.net 614 Eric Rescorla 615 RTFM, Inc. 616 U.S.A 618 Email: ekr@rtfm.com