idnits 2.17.1 draft-ietf-tls-sni-encryption-03.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 (May 20, 2018) is 2168 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-08 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-11 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-26 -- 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: November 21, 2018 RTFM, Inc. 6 May 20, 2018 8 Issues and Requirements for SNI Encryption in TLS 9 draft-ietf-tls-sni-encryption-03 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 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 21, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. History of the TLS SNI extension . . . . . . . . . . . . . . 3 57 2.1. Unanticipated usage of SNI information . . . . . . . . . 3 58 2.2. SNI encryption timeliness . . . . . . . . . . . . . . . . 4 59 2.3. End-to-end alternatives . . . . . . . . . . . . . . . . . 4 60 3. Security and Privacy Requirements for SNI Encryption . . . . 5 61 3.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 5 62 3.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 5 63 3.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 6 64 3.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 6 65 3.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 6 66 3.6. Proper Security Context . . . . . . . . . . . . . . . . . 6 67 3.7. Fronting Server Spoofing . . . . . . . . . . . . . . . . 7 68 3.8. Supporting multiple protocols . . . . . . . . . . . . . . 7 69 3.8.1. Hiding the Application Layer Protocol Negotiation . . 8 70 3.8.2. Support other transports than HTTP . . . . . . . . . 8 71 3.9. Fail to fronting . . . . . . . . . . . . . . . . . . . . 8 72 4. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 9 73 4.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 10 74 4.2. Delegation Control . . . . . . . . . . . . . . . . . . . 10 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Historically, adversaries have been able to monitor the use of web 86 services through three channels: looking at DNS requests, looking at 87 IP addresses in packet headers, and looking at the data stream 88 between user and services. These channels are getting progressively 89 closed. A growing fraction of Internet communication is encrypted, 90 mostly using Transport Layer Security (TLS) [RFC5246]. Progressive 91 deployment of solutions like DNS in TLS [RFC7858] mitigates the 92 disclosure of DNS information. More and more services are colocated 93 on multiplexed servers, loosening the relation between IP address and 94 web service. However, multiplexed servers rely on the Service Name 95 Information (SNI) to direct TLS connections to the appropriate 96 service implementation. This protocol element is transmitted in 97 clear text. As the other methods of monitoring get blocked, 98 monitoring focuses on the clear text SNI. The purpose of SNI 99 encryption is to prevent that. 101 In the past, there have been multiple attempts at defining SNI 102 encryption. These attempts have generally floundered, because the 103 simple designs fail to mitigate several of the attacks listed in 104 Section 3. In the absence of a TLS level solution, the most popular 105 approach to SNI privacy is HTTP level fronting, which we discuss in 106 Section 4. 108 2. History of the TLS SNI extension 110 The SNI extension was standardized in 2003 in [RFC3546] to facilitate 111 management of "colocation servers", in which a multiple services 112 shared the same IP address. A typical example would be mutiple web 113 sites served by the same web server. The SNI extension carries the 114 name of a specific server, enabling the TLS connection to be 115 established with the desired server context. The current SNI 116 extension specification can be found in [RFC6066]. 118 The SNI specification allowed for different types of server names, 119 but only the "hostname" variant was standardized and deployed. In 120 that variant, the SNI extension carries the domain name of the target 121 server. The SNI extension is carried in clear text in the TLS 122 "Client Hello" message. 124 2.1. Unanticipated usage of SNI information 126 The SNI was defined to facilitate management of servers, but the 127 developer of middleboxes soon found out that they could take 128 advantage of the information. Many examples of such usage are 129 reviewed in [I-D.mm-wg-effect-encrypt]. They include: 131 o Censorship of specific sites by "national firewalls", 133 o Content filtering by ISP blocking specific web sites in order to 134 implement "parental controls", or to prevent access to fraudulent 135 web sites, such as used for phishing, 137 o ISP assigning different QOS profiles to target services, 139 o Enterprise firewalls blocking web sites not deemed appropriate for 140 work, 142 o Enterprise firewalls exempting specific web sites from MITM 143 inspection, such as healthcare or financial sites for which 144 inspection would intrude with the privacy of employees. 146 The SNI is probably also included in the general collection of 147 metadata by pervasive surveillance actors. 149 2.2. SNI encryption timeliness 151 The clear-text transmission of the SNI was not flagged as a problem 152 in the security consideration sections of [RFC3546], [RFC4366], or 153 [RFC6066]. These specifications did not anticipate the abuses 154 described in Section 2.1. One reason may be that, when these RFCs 155 were written, the SNI information was available through a variety of 156 other means. 158 Many deployments still allocate different IP addresses to different 159 services, so that different services can be identified by their IP 160 addresses. However, content distribution networks (CDN) commonly 161 serve a large number of services through a small number of addresses. 163 The SNI carries the domain name of the server, which is also sent as 164 part of the DNS queries. Most of the SNI usage described in 165 Section 2.1 could also be implemented by monitoring DNS traffic or 166 controlling DNS usage. But this is changing with the advent of DNS 167 resolvers providing services like DNS over TLS [RFC7858] or DNS over 168 HTTPS [I-D.ietf-doh-dns-over-https]. 170 The common name component of the server certificate generally exposes 171 the same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 172 [RFC4346], and 1.2 [RFC5246], the server send their certificate in 173 clear text, ensuring that there would be limited benefits in hiding 174 the SNI. But the transmission of the server certificate is protected 175 in TLS 1.3 [I-D.ietf-tls-tls13]. 177 The decoupling of IP addresses and server names, the deployment of 178 DNS privacy, and the protection of server certificates transmissions 179 all contribute to user privacy. Encrypting the SNI now will complete 180 this push for privacy and make it much harder to censor specific 181 internet services. 183 2.3. End-to-end alternatives 185 Deploying SNI encryption will help thwarting most the "unanticipated" 186 SNI usages described in Section 2.1, including censorship and 187 pervasive surveillance. It will also thwart functions that are 188 sometimes described as legitimate. Most of these functions can 189 however be realized by other means. For example, some DNS service 190 providers offer customers the provision to "opt in" filtering 191 services for parental control and phishing protection. Per stream 192 QoS can be provided by a combination of packet marking and end to end 193 agreements. Enterprises can deploy monitoring software to control 194 usage of the enterprises computers. As SNI encryption becomes 195 common, we can expect more deployment of such "end to end" solutions. 197 3. Security and Privacy Requirements for SNI Encryption 199 Over the past years, there have been multiple proposals to add an SNI 200 encryption option in TLS. Many of these proposals appeared 201 promising, but were rejected after security reviews pointed plausible 202 attacks. In this section, we collect a list of these known attacks. 204 3.1. Mitigate Replay Attacks 206 The simplest SNI encryption designs replace in the initial TLS 207 exchange the clear text SNI with an encrypted value, using a key 208 known to the multiplexed server. Regardless of the encryption used, 209 these designs can be broken by a simple replay attack, which works as 210 follow: 212 1- The user starts a TLS connection to the multiplexed server, 213 including an encrypted SNI value. 215 2- The adversary observes the exchange and copies the encrypted SNI 216 parameter. 218 3- The adversary starts its own connection to the multiplexed server, 219 including in its connection parameters the encrypted SNI copied from 220 the observed exchange. 222 4- The multiplexed server establishes the connection to the protected 223 service, thus revealing the identity of the service. 225 One of the goals of SNI encryption is to prevent adversaries from 226 knowing which Hidden Service the client is using. Successful replay 227 attacks breaks that goal by allowing adversaries to discover that 228 service. 230 3.2. Avoid Widely Shared Secrets 232 It is easy to think of simple schemes in which the SNI is encrypted 233 or hashed using a shared secret. This symmetric key must be known by 234 the multiplexed server, and by every users of the protected services. 235 Such schemes are thus very fragile, since the compromise of a single 236 user would compromise the entire set of users and protected services. 238 3.3. Prevent SNI-based Denial of Service Attacks 240 Encrypting the SNI may create extra load for the multiplexed server. 241 Adversaries may mount denial of service attacks by generating random 242 encrypted SNI values and forcing the multiplexed server to spend 243 resources in useless decryption attempts. 245 It may be argued that this is not an important DOS avenue, as regular 246 TLS connection attempts also require the server to perform a number 247 of cryptographic operations. However, in many cases, the SNI 248 decryption will have to be performed by a front end component with 249 limited resources, while the TLS operations are performed by the 250 component dedicated to their respective services. SNI based DOS 251 attacks could target the front end component. 253 3.4. Do not stick out 255 In some designs, handshakes using SNI encryption can be easily 256 differentiated from "regular" handshakes. For example, some designs 257 require specific extensions in the Client Hello packets, or specific 258 values of the clear text SNI parameter. If adversaries can easily 259 detect the use of SNI encryption, they could block it, or they could 260 flag the users of SNI encryption for special treatment. 262 In the future, it might be possible to assume that a large fraction 263 of TLS handshakes use SNI encryption. If that was the case, the 264 detection of SNI encryption would be a lesser concern. However, we 265 have to assume that in the near future, only a small fraction of TLS 266 connections will use SNI encryption. 268 3.5. Forward Secrecy 270 The general concerns about forward secrecy apply to SNI encryption 271 just as well as to regular TLS sessions. For example, some proposed 272 designs rely on a public key of the multiplexed server to define the 273 SNI encryption key. If the corresponding private key was 274 compromised, the adversaries would be able to process archival 275 records of past connections, and retrieve the protected SNI used in 276 these connections. These designs failed to maintain forward secrecy 277 of SNI encryption. 279 3.6. Proper Security Context 281 We can design solutions in which the multiplexed server or a fronting 282 service act as a relay to reach the protected service. Some of those 283 solutions involve just one TLS handshake between the client and the 284 multiplexed server, or between the client and the fronting service. 286 The master secret is verified by verifying a certificate provided by 287 either of these entities, but not by the protected service. 289 These solutions expose the client to a Man-In-The-Middle attack by 290 the multiplexed server or by the fronting service. Even if the 291 client has some reasonable trust in these services, the possibility 292 of MITM attack is troubling. 294 The multiplexed server or the fronting services could be pressured by 295 adversaries. By design, they could be forced to deny access to the 296 protected service, or to divulge which client accessed it. But if 297 MITM is possible, the adversaries would also be able to pressure them 298 into intercepting or spoofing the communications between client and 299 protected service. 301 3.7. Fronting Server Spoofing 303 Adversaries could mount an attack by spoofing the Fronting Service. 304 A spoofed Fronting Service could act as a "honeypot" for users of 305 hidden services. At a minimum, the fake server could record the IP 306 addresses of these users. If the SNI encryption solution places too 307 much trust on the fronting server, the fake server could also serve 308 fake content of its own choosing, including various forms of malware. 310 There are two main channels by which adversaries can conduct this 311 attack. Adversaries can simply try to mislead users into believing 312 that the honeypot is a valid Fronting Server, especially if that 313 information is carried by word of mouth or in unprotected DNS 314 records. Adversaries can also attempt to hijack the traffic to the 315 regular Fronting Server, using for example spoofed DNS responses or 316 spoofed IP level routing, combined with a spoofed certificate. 318 3.8. Supporting multiple protocols 320 The SNI encryption requirement do not stop with HTTP over TLS. 321 Multiple other applications currently use TLS, including for example 322 SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. These applications 323 too will benefit of SNI encryption. HTTP only methods like those 324 described in Section 4.1 would not apply there. In fact, even for 325 the HTTPS case, the HTTPS tunneling service described in Section 4.1 326 is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly 327 with the multiple streams feature of HTTP 2.0 [RFC7540]. This points 328 to the need of an application agnostic solution, that would be 329 implemented fully in the TLS layer. 331 3.8.1. Hiding the Application Layer Protocol Negotiation 333 The Application Layer Protocol Negotiation (ALPN) parameters of TLS 334 allow implementations to negotiate the application layer protocol 335 used on a given connection. TLS provides the ALPN values in clear 336 text during the initial handshake. While exposing the ALPN does not 337 create the same privacy issues as exposing the SNI, there is still a 338 risk. For example, some networks may attempt to block applications 339 that they do not understand, or that they wish users would not use. 341 In a sense, ALPN filtering could be very similar to the filtering of 342 specific port numbers exposed in some network. This filtering by 343 ports has given rise to evasion tactics in which various protocols 344 are tunneled over HTTP in order to use open ports 80 or 443. 345 Filtering by ALPN would probably beget the same responses, in which 346 the applications just move over HTTP, and only the HTTP ALPN values 347 are used. Applications would not need to do that if the ALPN was 348 hidden in the same way as the SNI. 350 It is thus desirable that SNI Encryption mechanisms be also able hide 351 the ALPN. 353 3.8.2. Support other transports than HTTP 355 The TLS handshake is also used over other transports such as UDP with 356 both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls]. The 357 requirement to encrypt the SNI apply just as well for these 358 transports as for TLS over TCP. 360 This points to a requirement for SNI Encryption mechanisms to also be 361 applicable to non-TCP transports such as DTLS or QUIC. 363 3.9. Fail to fronting 365 It is easy to imagine designs in which the client sends some client 366 hello extension that points to a secret shared by client and hidden 367 server. If that secret is incorporated into the handshake secret, 368 the exchange will only succeeds if the connection truly ends at the 369 hidden server. The exchange will fail if the extension is stripped 370 by an MITM, and the exchange will also fail if an adversary replays 371 the extension in a Client Hello. 373 The problem with that approach is clear. Adversaries that replay the 374 extension can test whether the client truly wanted to access the 375 fronting server, or was simply using that fronting server as an 376 access gateway to something else. The adversaries will not know what 377 hidden service the client was trying to reach, but they can guess. 379 They can also start directly interrogate the user, or other 380 unpleasant alternatives. 382 When designing SNI encryption schemes, we have to take into account 383 attacks that strip parameters from the Client Hello, or replay 384 attacks. In both cases, the desired behavior is to fall back to a 385 connection with the fronting server, so there is no visble difference 386 between a regular connection to that server and an attempt to reach 387 the hidden server. 389 4. HTTP Co-Tenancy Fronting 391 In the absence of TLS level SNI encryption, many sites rely on an 392 "HTTP Co-Tenancy" solution. The TLS connection is established with 393 the fronting server, and HTTP requests are then sent over that 394 connection to the hidden service. For example, the TLS SNI could be 395 set to "fronting.example.com", the fronting server, and HTTP requests 396 sent over that connection could be directed to "hidden.example.com/ 397 some-content", accessing the hidden service. This solution works 398 well in practice when the fronting server and the hidden server are 399 'co-tenant" of the same multiplexed server. 401 The HTTP fronting solution can be deployed without modification to 402 the TLS protocol, and does not require using any specific version of 403 TLS. There are however a few issues regarding discovery, client 404 implementations, trust, and applicability: 406 o The client has to discover that the hidden service can be accessed 407 through the fronting server. 409 o The client browser's has to be directed to access the hidden 410 service through the fronting service. 412 o Since the TLS connection is established with the fronting service, 413 the client has no proof that the content does in fact come from 414 the hidden service. The solution does thus not mitigate the 415 context sharing issues described in Section 3.6. 417 o Since this is an HTTP level solution, it would not protected non 418 HTTP protocols such as DNS over TLS [RFC7858] or IMAP over TLS 419 [RFC2595]. 421 The discovery issue is common to pretty much every SNI encryption 422 solution. The browser issue may be solved by developing a browser 423 extension that support HTTP Fronting, and manages the list of 424 fronting services associated with the hidden services that the client 425 uses. The multi-protocol issue can be mitigated by using 426 implementation of other applications over HTTP, such as for example 427 DNS over HTTPS [I-D.hoffman-dns-over-https]. The trust issue, 428 however, requires specific developments. 430 4.1. HTTPS Tunnels 432 The HTTP Fronting solution places a lot of trust in the Fronting 433 Server. This required trust can be reduced by tunnelling HTTPS in 434 HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. 435 In this solution, the client establishes a TLS connection to the 436 Fronting Server, and then issues an HTTP Connect request to the 437 Hidden Server. This will establish an end-to-end HTTPS over TLS 438 connection between the client and the Hidden Server, mitigating the 439 issues described in Section 3.6. 441 The HTTPS in HTTPS solution requires double encryption of every 442 packet. It also requires that the fronting server decrypts and relay 443 messages to the hidden server. Both of these requirements make the 444 implementation onerous. 446 4.2. Delegation Control 448 Clients would see their privacy compromised if they contacted the 449 wrong fronting server to access the hidden service, since this wrong 450 server could disclose their access to adversaries. This requires a 451 controlled way to indicate which fronting ferver is acceptable by the 452 hidden service. 454 This problem is both similar and different from the "fronting server 455 spoofing" attack described in Section 3.7. Here, the spoofing would 456 be performed by distributing fake advice, such as "to reach example 457 hidden.example.com, use fake.example.com as a fronting server", when 458 "fake.example.com" is under the control of an adversary. 460 In practice, this attack is well mitigated when the hidden service is 461 accessed through a specialized application. The name of the fronting 462 server can then be programmed in the code of the application. But 463 the attack is much harder to mitigate when the hidden service has to 464 be accessed through general purpose web browsers. The browsers will 465 need a mechanism to obtain the fronting server indication in a secure 466 way. 468 There are several proposed solutions to this problem, such as 469 creating a special form of certificate to codify the relation between 470 fronting and hidden server, or obtaining the relation between hidden 471 and fronting service through the DNS, possibly using DNSSEC to avoid 472 spoofing. 474 We can observe that content distribution network have a similar 475 requirement. They need to convince the client that "www.example.com" 476 can be accessed through the seemingly unrelated "cdn-node- 477 xyz.example.net". Most CDN have deployed DNS-based solutions to this 478 problem. 480 5. Security Considerations 482 Replacing clear text SNI transmission by an encrypted variant will 483 improve the privacy and reliability of TLS connections, but the 484 design of proper SNI encryption solutions is difficult. This 485 document does not present the design of a solution, but provide 486 guidelines for evaluating proposed solutions. 488 This document lists a number of attacks against SNI encryption in 489 Section 3, and also in Section 4.2, and presents a list of 490 requirements to mitigate these attacks. The current HTTP based 491 solutions described in Section 4 only meet some of these 492 requirements. In practice, it may well be that no solution can meet 493 every requirement, and that practical solutions will have to make 494 some compromises. 496 In particular, the requirement to not stick out presented in 497 Section 3.4 may have to be lifted, especially if for proposed 498 solutions that could quickly reach large scale deployments. 500 6. IANA Considerations 502 This draft does not require any IANA action. 504 7. Acknowledgements 506 A large part of this draft originates in discussion of SNI encryption 507 on the TLS WG mailing list, including comments after the tunneling 508 approach was first proposed in a message to that list: 509 . 512 Thanks to Daniel Kahn Gillmor for a pretty detailed review of the 513 initial draft. 515 8. References 517 8.1. Normative References 519 [I-D.ietf-tls-tls13] 520 Rescorla, E., "The Transport Layer Security (TLS) Protocol 521 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 522 March 2018. 524 8.2. Informative References 526 [I-D.hoffman-dns-over-https] 527 Hoffman, P. and P. McManus, "DNS Queries over HTTPS", 528 draft-hoffman-dns-over-https-01 (work in progress), June 529 2017. 531 [I-D.ietf-doh-dns-over-https] 532 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 533 (DOH)", draft-ietf-doh-dns-over-https-08 (work in 534 progress), May 2018. 536 [I-D.ietf-quic-tls] 537 Thomson, M. and S. Turner, "Using Transport Layer Security 538 (TLS) to Secure QUIC", draft-ietf-quic-tls-11 (work in 539 progress), April 2018. 541 [I-D.ietf-tls-dtls13] 542 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 543 Datagram Transport Layer Security (DTLS) Protocol Version 544 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 545 2018. 547 [I-D.mm-wg-effect-encrypt] 548 Moriarty, K. and A. Morton, "Effects of Pervasive 549 Encryption on Operators", draft-mm-wg-effect-encrypt-25 550 (work in progress), March 2018. 552 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 553 RFC 2246, DOI 10.17487/RFC2246, January 1999, 554 . 556 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 557 RFC 2595, DOI 10.17487/RFC2595, June 1999, 558 . 560 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 561 and T. Wright, "Transport Layer Security (TLS) 562 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 563 . 565 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 566 (TLS) Protocol Version 1.1", RFC 4346, 567 DOI 10.17487/RFC4346, April 2006, 568 . 570 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 571 and T. Wright, "Transport Layer Security (TLS) 572 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 573 . 575 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 576 (TLS) Protocol Version 1.2", RFC 5246, 577 DOI 10.17487/RFC5246, August 2008, 578 . 580 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 581 Extensions: Extension Definitions", RFC 6066, 582 DOI 10.17487/RFC6066, January 2011, 583 . 585 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 586 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 587 DOI 10.17487/RFC7540, May 2015, 588 . 590 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 591 Security (TLS) in the Extensible Messaging and Presence 592 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 593 2015, . 595 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 596 and P. Hoffman, "Specification for DNS over Transport 597 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 598 2016, . 600 Authors' Addresses 602 Christian Huitema 603 Private Octopus Inc. 604 Friday Harbor WA 98250 605 U.S.A 607 Email: huitema@huitema.net 608 Eric Rescorla 609 RTFM, Inc. 610 U.S.A 612 Email: ekr@rtfm.com