idnits 2.17.1 draft-schwartz-dns-sni-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '... TLS endpoint operator MAY publish one...' RFC 2119 keyword, line 170: '... Each SNI record MUST contain a prefix...' RFC 2119 keyword, line 172: '... [RFC6698]. The SNI record's RDATA MUST contain the intended Server...' RFC 2119 keyword, line 181: '... Section 3 of [RFC6066]. DNS resolvers SHOULD treat SNI records as...' RFC 2119 keyword, line 225: '... application SHOULD query the SNI re...' (27 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2017) is 2597 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Experimental RFC: RFC 7413 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Schwartz 3 Internet-Draft Google 4 Intended status: Standards Track February 17, 2017 5 Expires: August 21, 2017 7 A DNS Resource Record for TLS Server Name Indication (DNS SNI) 8 draft-schwartz-dns-sni-02 10 Abstract 12 The SNI record type allows a domain owner to specify the "server 13 name" to indicate in TLS connections, if it is different from the 14 domain name. This allows domains that use shared hosting and 15 wildcard or multi-domain (UCC) certificates to change the only domain 16 name shown in cleartext, to prevent a passive adversary from 17 identifying exactly which domain a user is accessing. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 21, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Threat example: shared hosting service . . . . . . . . . 3 55 2. Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Need for a new record type . . . . . . . . . . . . . . . 4 57 2.1.1. Using SRV . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1.2. Using TLSA . . . . . . . . . . . . . . . . . . . . . 5 59 2.1.3. Using TXT . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Client Requirements . . . . . . . . . . . . . . . . . . . . . 5 61 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 6 62 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Performance Considerations . . . . . . . . . . . . . . . . . 7 65 8. Considerations for optimizing privacy . . . . . . . . . . . . 9 66 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 10 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 12.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 Modern Internet standards are designed to avoid unnecessarily 77 revealing sensitive information about a user's behavior to a passive 78 adversary. One key piece of sensitive information is the name of the 79 domain that a user is visiting. Most commonly, this is the DNS name 80 of a website, so the sensitive information indicates browsing history 81 at domain granularity. 83 Several protocol standards contain elements that protect the user's 84 browsing history from a passive adversary. The DNS over TLS standard 85 [RFC7858] allows clients to perform DNS queries without revealing the 86 request or response to an attacker. This allows clients to access 87 DNS-named services without publicly revealing the name of the 88 services that they are about to access. 90 After a DNS lookup, the HTTPS standard [RFC2818] allows clients to 91 perform HTTP requests to a server without revealing the contents of 92 the HTTP request or response, using TLS. This hides the website's 93 host name from being observed by a passive adversary. Previous 94 versions of TLS transferred the server's certificate in cleartext, 95 revealing some information about the identity of the destination, but 96 TLS 1.3 [I-D.ietf-tls-tls13] enables encrypting the certificate as 97 well. 99 However, modern use of HTTPS requires providing a TLS Server Name 100 Indication (SNI, [RFC6066]), which conveys the website's DNS name in 101 cleartext. Sending the Server Name Indication in cleartext reveals 102 the user's sensitive information to a passive adversary, defeating 103 the desired privacy benefit. 105 DNS Server Client HTTP Server 106 | | | 107 1. |<==example.com AAAA?==| | 108 2. |===2001:db8::1=======>| | 109 3. | |--TLS ClientHello SNI:example.com--->| 110 4. | |<------TLS ServerHello---------------| 111 5. | |<==TLS EncryptedExt SNI:example.com==| 112 6. | |<==TLS Certificate, CN:example.com===| 113 7. | |==HTTP GET :authority:example.com===>| 115 ==== encrypted ---- cleartext 117 Figure 1: HTTP request with DPRIVE, HTTP/2, and TLS-1.3 119 This document describes a new DNS record that allows a domain owner 120 to tell clients precisely what Server Name Indication to send. For 121 domains that use wildcard or multi-domain (UCC) certificates, this 122 name may differ from the website's DNS name, preventing the passive 123 adversary from learning which domain the user is accessing with high 124 confidence. Instead, the adversary learns only the IP addresses with 125 confidence, so all services that share an IP address and certificate 126 can become part of a single anonymity set that is larger than any 127 single service. Clients can make use of this record without adding 128 delay to their connection process, and clients who do not make use of 129 this record are not negatively impacted. 131 1.1. Threat example: shared hosting service 133 Consider a shared hosting service, example.com, that offers each user 134 their own website, hosted at a unique subdomain like 135 alicesphotos.example.com. For confidentiality and access control, 136 example.com provides its users with service over HTTPS, using a 137 wildcard certificate for *.example.com. All users' subdomains are 138 hosted by the same set of servers. 140 Prior to the introduction of TLS Server Name Indication, this 141 arrangement was sufficient to prevent a passive adversary who 142 monitors example.com's incoming traffic from determining which user 143 is visiting which subdomain. However, modern TLS clients publish the 144 Fully Qualified Domain Name in the TLS ClientHello as the Server Name 145 Indication, so the adversary can easily identify which client IP 146 address is accessing which subdomain. Mapping IP addresses to 147 individual users is often straightforward for an adversary with 148 access to ISP records or a popular website's logs. 150 The user's choice of which subdomain to visit may be sensitive. 151 Subdomains of shared hosting services often contain controversial 152 material, and users may reasonably wish not to make public the names 153 of the subdomains that they read. 155 The user's identity as the author of a particular subdomain is 156 typically even more sensitive. Authors of controversial sites on 157 shared hosting often choose not to reveal their true identity or 158 location, to protect their physical safety. However, the author of a 159 domain is typically the only visitor who is likely to upload a large 160 amount of data. By combining the TLS SNI with a simple upload 161 threshold, the adversary can determine the author's client IP address 162 with high confidence. 164 2. Concept 166 We define a new RRTYPE: "SNI". To control the TLS Server Name 167 Indication that clients set, a TLS endpoint operator MAY publish one 168 or more SNI records for their domain name (the "base domain"). 170 Each SNI record MUST contain a prefix of the form 171 _(port)._(transport), the same prefix used for a TLSA record 172 [RFC6698]. The SNI record's RDATA MUST contain the intended Server 173 Name. For example, if the operator of subdomain1.example.com wishes 174 to inform HTTPS visitors to set a Server Name Indication of 175 "subdomain2.example.com", they would publish a record of the form 177 _443._tcp.subdomain1.example.com. IN SNI "subdomain2.example.com" 179 The RDATA of an SNI record consists of UTF-8 octets for use as a 180 HostName in the TLS Server Name Indication field, in conformance with 181 Section 3 of [RFC6066]. DNS resolvers SHOULD treat SNI records as 182 resource records of unknown type [RFC3597]. 184 2.1. Need for a new record type 186 Instead of defining a new record type, we could convey this 187 information using an existing record type. However, using any 188 existing record type has some significant drawbacks. 190 2.1.1. Using SRV 192 We could achieve an equivalent effect using SRV records [RFC2782], 193 with a new protocol type. 195 This would function very similarly to an SNI record, but it would be 196 a violation of the SRV specification, which requires the client to 197 redirect to the domain in the RDATA and perform additional DNS 198 queries. SRV records also include a port, which is not meaningful in 199 this context. Using SRV records in this way might also make future 200 extensions (e.g. to other forms of RDATA) somewhat less appealing. 202 2.1.2. Using TLSA 204 We could use the existing TLSA record type [RFC6698]. Clients could 205 extract the server's supported names from a "full certificate 206 association" Section 4.1 [RFC6698] TLSA response. 208 This approach doesn't work well for wildcard certificates, because 209 the client cannot tell what SNI to set. Using TLSA in this way would 210 also create problems for servers that use SNI for more than 211 certificate selection, and for servers that have multiple overlapping 212 certificates. It might also be very inefficient: transferring an 213 entire certificate just to learn its names is wasteful, and TLSA 214 records that contain hashes would have to be discarded. 216 2.1.3. Using TXT 218 We could encode this information in a TXT record, but that would 219 violate the intended purpose of TXT records: to convey information to 220 human readers. 222 3. Client Requirements 224 When initiating a TLS connection to a domain and port, a client 225 application SHOULD query the SNI record for the prefixed domain at 226 the same time as the A or AAAA query. The application MUST discard 227 or ignore any SNI record whose RDATA is not a valid TLS HostName or 228 an empty string. If an application's query returns multiple valid 229 SNI records, the application SHOULD choose one at random. 231 The client application SHOULD use the RDATA of the selected SNI 232 record as the Server Name Indication in the TLS ClientHello. If the 233 selected SNI record is present with an empty RDATA (RDLEN = 0), then 234 the client SHOULD omit the Server Name Indication. 236 Client applications MUST NOT allow the contents of the SNI record to 237 influence their certificate validation behavior. The client's 238 certificate validation MUST be based on the user's specified 239 destination, not the RDATA of the SNI DNS record. If the server's 240 certificate is not valid for the user's specified destination, the 241 client application MUST terminate the TCP connection and SHOULD retry 242 the TLS connection without the SNI RDATA, using the client's default 243 Server Name Indication behavior. 245 4. Server Requirements 247 Domain owners that publish an SNI record MUST ensure that all 248 relevant servers, when receiving this SNI value, reply with a 249 certificate whose set of valid domains includes the base domain. The 250 servers MUST satisfy this criterion for all SNI records that have 251 been published and not yet expired. Relevant servers are those whose 252 IP addresses are in the correct family and are listed in a non- 253 expired address record for this domain. 255 Domain owners that publish an SNI record MUST ensure that their 256 servers do not depend on the TLS Server Name Indication to select 257 which service to provide to the user. Instead, participating servers 258 SHOULD select the service using the tunneled protocol's service 259 identifier, e.g. the :authority pseudo-header in HTTP/2, bearing in 260 mind that this identifier is controlled by the client and may be 261 untrusted. 263 5. Use Cases 265 A host that serves many subdomains with a single wildcard certificate 266 could set the SNI of all subdomains to the same fixed subdomain, in 267 order to prevent a passive adversary from learning which subdomain a 268 user is accessing. 270 A host that uses multiple-domain (UCC) certificates, and which 271 controls the DNS entries for domains that it hosts, could set several 272 SNI records on the domains that share one certificate, with each 273 record indicating a different domain name that is also provided in 274 that certificate. This would prevent a passive adversary from 275 learning with confidence which of those domains a client is 276 accessing. 278 A TLS service operator who does not use shared hosting could set an 279 empty SNI record, to tell the client not to use SNI. 281 6. Security Considerations 283 The SNI record is provided over DNS, and MAY be used with or without 284 DNSSEC. The SNI record is therefore untrusted, and clients MUST NOT 285 rely on its presence or correctness. 287 A passive adversary who monitors the client's DNS queries could learn 288 which domain the client is accessing, defeating the confidentiality 289 benefits of this record type. Therefore, clients wishing to conceal 290 browsing history from a passive adversary SHOULD also use DNS over 291 TLS [RFC7858]. However, clients MAY use SNI records with standard 292 DNS, in order to provide protection against a weak passive adversary 293 who can monitor only the link between the client and the TLS server, 294 not the link between the client and the DNS server. 296 An active adversary who controls the DNS could remove the SNI record, 297 or add a malicious record. Removing the record would cause the 298 client to revert to its default behavior in the absence of an SNI 299 record. Adding a malicious record could cause the client to set an 300 incorrect or nonexistent Server Name. This will likely cause the 301 initial connection attempt to fail, but does not cause any additional 302 loss of confidentiality, because the client will still perform 303 standard TLS certificate verification. (Like the previous adversary, 304 this active adversary can also monitor DNS queries, so they can still 305 learn which domain the client is attempting to access.) 307 7. Performance Considerations 309 Client applications that intend to make use of the SNI record SHOULD 310 issue a DNS query for the SNI record immediately following the A or 311 AAAA record query. The client SHOULD NOT wait for an A or AAAA 312 response before issuing the SNI query, as this would introduce an 313 extra round-trip delay to the DNS server. A client application 314 SHOULD NOT delay initiating a TCP connection while waiting for the 315 SNI DNS response. 317 DNS Server Client TLS Server 318 | | | 319 |(Client wants to connect to example.com, but doesn't know the IP)| 320 1. |<===example.com AAAA?==========| | 321 |<==_443._tcp.example.com SNI?==| | 322 2. |===AAAA 2001:db8::1===========>| | 323 |(As soon as the client gets the IP they can start TCP connection)| 324 | |--------------TCP SYN----------->| 325 |(The DNS SNI response should arrive soon after the AAAA response)| 326 3. |======SNI example2.com========>| | 327 4. | |<------------TCP SYN+ACK---------| 328 | |--------------TCP ACK----------->| 329 |(When starting TLS, the client uses the SNI RDATA as the TLS SNI)| 330 | |--ClientHello SNI:example2.com-->| 332 Figure 2: TLS connection with SNI record, typical case 334 If the client can begin sending data to the server (e.g. SYN-ACK is 335 received) before the SNI RDATA has been received, the client MAY 336 issue a ClientHello using its default behavior (i.e. without using 337 the SNI RDATA). Note that if the client's DNS resolver has similar 338 performance for SNI and A/AAAA queries, the client will generally 339 receive the SNI response before the destination server receives the 340 TCP SYN packet, thus avoiding this situation. 342 DNS Server Client TLS Server 343 | | | 344 1. |<===example.com AAAA?==========| | 345 |<==_443._tcp.example.com SNI?==| | 346 2. |===AAAA 2001:db8::1===========>| | 347 | |--------------TCP SYN---------->| 348 3. | |<------------TCP SYN+ACK--------| 349 | |--------------TCP ACK---------->| 350 | |--ClientHello SNI:example.com-->| 351 4. |======SNI example2.com========>| | 353 Figure 3: TLS connection with SNI record, slow case (OPTIONAL) 355 If the client is using TCP Fast Open [RFC7413], and the destination 356 IP address is known (e.g. AAAA record is in cache) but the SNI RDATA 357 is not known, the client MAY send a TLS ClientHello using its default 358 behavior. However, the client SHOULD also issue a DNS query for the 359 SNI record, in order to populate the local cache for subsequent 360 connection attempts. 362 DNS Server Client TLS Server 363 | | | 364 1. | |----------TCP Fast Open-------->| 365 | |--ClientHello SNI:example.com-->| 366 2. |<==_443._tcp.example.com SNI?==| | 367 3. |======SNI example2.com========>| | 369 Figure 4: TCP Fast Open, AAAA cached but not SNI (OPTIONAL) 371 If the client is using TCP Fast Open and the destination IP address 372 is not known, the client SHOULD issue A/AAAA and SNI requests 373 simultaneously. If the A or AAAA response is received before the 374 corresponding SNI response, the client SHOULD wait briefly (e.g. 1 375 millisecond) to allow receipt of the SNI response before issuing a 376 TLS ClientHello. 378 DNS Server Client TLS Server 379 | | | 380 1. |<===example.com AAAA?==========| | 381 |<==_443._tcp.example.com SNI?==| | 382 2. |===AAAA 2001:db8::1===========>| | 383 | (client waits briefly for the SNI response to arrive) | 384 3. |======SNI example2.com========>| | 385 4. | |----------TCP Fast Open--------->| 386 | |--ClientHello SNI:example2.com-->| 388 Figure 5: TCP Fast Open, nothing cached (delay is RECOMMENDED) 390 TODO: Check if 1ms is a reasonable delay to receive an immediately 391 subsequent packet on current hardware. 393 8. Considerations for optimizing privacy 395 By publishing an SNI record, a service operator can reduce the 396 ability of a passive network adversary to determine with certainty 397 which domain each user is accessing. Reducing leakage of information 398 to this adversary, and reducing this adversary's confidence in the 399 information they do collect, improves user privacy. 401 Regardless of SNI, a passive adversary still learns the client's and 402 destination's IP addresses. The adversary may have foreknowledge of 403 which domains are hosted at that address. An active adversary could 404 attempt a similar connection in order to learn more about the 405 services hosted at the destination. The purpose of this proposal is 406 to ensure that if there is more than one service hosted at the 407 destination IP, a passive network adversary does not directly learn 408 which service the client is using. Services that share an IP address 409 and TLS certificate with a wider range of other services can benefit 410 more from the use of an SNI record. 412 An adversary may be able to distinguish different encrypted services 413 on the same IP address by the size, frequency, and timing of 414 encrypted packets. Use of the SNI record does not prevent attacks of 415 this kind. 417 If the adversary has full knowledge of the contents of the global DNS 418 (a strong adversary), then users of a domain only experience a 419 privacy benefit if another domain at the same IP address uses the 420 same SNI RDATA. The privacy benefit increases as more domains share 421 the same SNI RDATA and the same IP addresses. 423 If all clients will use the SNI record, then the greatest privacy 424 benefit is achieved by configuring all services that share a 425 certificate to use the same SNI. However, a service operator may 426 also choose to publish multiple SNI records for a domain, listing 427 several other services that share the same certificate. The client 428 will then choose from among these Server Name Indications at random. 429 This approach maintains protection of clients that are aware of the 430 SNI record, but also benefits users who are not using the SNI record: 431 if the adversary cannot distinguish these two groups of users, then 432 it cannot tell with certainty which domain any user is accessing. 433 Note that due to response latency issues, some clients might not be 434 using the SNI record contents, even if they have issued an SNI DNS 435 query (see Performance Considerations). 437 Use of the SNI record does not prevent an active adversary from 438 learning which certificate the server is using. A simple active 439 adversary can reuse the client's observed Server Name Indication, to 440 learn which certificate is sent by the server in reply. Therefore, 441 domain owners seeking to protect users against an active adversary 442 MUST ensure that the server's certificate includes a sufficiently 443 large and diverse set of domains to achieve their privacy goals. 445 In TLS 1.2 [RFC5246], the server sends its certificate in cleartext, 446 visible to a passive adversary. A passive adversary can also observe 447 the certificate ID if the client performs an OCSP lookup [RFC6960]. 448 Therefore, servers wishing to hide the certificate MUST implement TLS 449 1.3 and OCSP Stapling [RFC6961]. Note that this precaution does not 450 protect against even a simple active adversary. 452 9. Extensibility 454 The SNI record as described here contains two main mechanisms for 455 extensibility. First, future extensions may describe records whose 456 RDATA is not structured as a valid domain name (e.g. containing 457 whitespace or "=" characters). Clients conformant to this 458 specification MUST ignore such records. 460 Second, clients that connect to a server and experience a negotiation 461 failure SHOULD retry the connection without making use of the SNI 462 record. This allows future changes to the semantics of SNI records 463 with RDATA that are valid domain names, without causing a serious 464 problem for clients conformant to this version of the specification. 466 10. IANA Considerations 468 This document uses a new DNS RR type, SNI, which will require a value 469 assignment from IANA. 471 11. Acknowledgements 473 Thanks to Ben Vitale, Warren Kumari, and Vinicius Fortuna for their 474 constructive feedback. 476 12. References 478 12.1. Normative References 480 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 481 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 482 2003, . 484 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 485 (TLS) Protocol Version 1.2", RFC 5246, 486 DOI 10.17487/RFC5246, August 2008, 487 . 489 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 490 Extensions: Extension Definitions", RFC 6066, 491 DOI 10.17487/RFC6066, January 2011, 492 . 494 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 495 of Named Entities (DANE) Transport Layer Security (TLS) 496 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 497 2012, . 499 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 500 Galperin, S., and C. Adams, "X.509 Internet Public Key 501 Infrastructure Online Certificate Status Protocol - OCSP", 502 RFC 6960, DOI 10.17487/RFC6960, June 2013, 503 . 505 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 506 Multiple Certificate Status Request Extension", RFC 6961, 507 DOI 10.17487/RFC6961, June 2013, 508 . 510 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 511 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 512 . 514 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 515 and P. Hoffman, "Specification for DNS over Transport 516 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 517 2016, . 519 12.2. Informative References 521 [I-D.ietf-tls-tls13] 522 Rescorla, E., "The Transport Layer Security (TLS) Protocol 523 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 524 October 2016. 526 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 527 specifying the location of services (DNS SRV)", RFC 2782, 528 DOI 10.17487/RFC2782, February 2000, 529 . 531 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 532 DOI 10.17487/RFC2818, May 2000, 533 . 535 Author's Address 537 Benjamin M. Schwartz 538 Google, Inc. 539 111 8th Ave 540 New York, NY 10011 541 USA 543 Email: bemasc@google.com