idnits 2.17.1 draft-hzhwm-start-tls-for-dns-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A DNS client that receives a response to its initial query using TCP transport that has the TO bit clear MUST not initiate a TLS handshake and SHOULD utilize the existing TCP connection for subsequent queries. DNS clients SHOULD remember server IP addresses that don't support DNS-over-TLS (including TLS handshake failures) and SHOULD NOT request DNS-over-TLS from them for reasonable period. (We suggest 1 hour, or when the client discovers a new resolver.) -- The document date (July 4, 2014) is 3584 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 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Hu 3 Internet-Draft L. Zhu 4 Intended status: Standards Track J. Heidemann 5 Expires: January 5, 2015 USC/Information Sciences 6 Institute 7 A. Mankin 8 D. Wessels 9 Verisign Labs 10 July 4, 2014 12 Starting TLS over DNS 13 draft-hzhwm-start-tls-for-dns-01 15 Abstract 17 This document describes a technique for upgrading a DNS TCP 18 connection to use Transport Layer Security (TLS) over standard ports. 19 Encryption provided by DNS-over-TLS eliminates opportunities for 20 eavesdropping of DNS queries in the network. The proposed mechanism 21 is backwards compatible with clients and servers that are not aware 22 of DNS-over-TLS. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent 59 unencrypted, which makes them vulnerable to eavesdropping by an 60 attacker that has access to the network channel, reducing the privacy 61 of the querier. Recent news reports have elevated these concerns, 62 and ongoing efforts are beginning to identify privacy concerns about 63 DNS ([draft-bortzmeyer-dnsop-dns-privacy]). 65 Prior work has addressed some aspects of DNS security, but none 66 addresses privacy between a DNS client and server using standard 67 protocols. DNS Security Extensions (DNSSEC, [RFC4033]) provide 68 _response integrity_ by defining mechanisms to cryptographically sign 69 zones, allowing end-users (or their first-hop resolver) to verify 70 replies are correct. DNSSEC however does nothing to protect request 71 or response privacy. Traditionally, either privacy was not 72 considered a requirement for DNS traffic, or it was assumed that 73 network traffic was sufficiently private, however these perceptions 74 are evolving due to recent events. 76 More recently, DNSCurve [draft-dempsky-dnscurve] defines a method to 77 provide link-level confidentiality and integrity between DNS clients 78 and servers. However, it does so with a new cryptographic protocol 79 and so does not take advantage of TLS. ConfidentialDNS 80 [draft-wijngaards-confidentialdns] and IPSECA 81 [draft-osterweil-dane-ipsec] use opportunistic encryption to provide 82 privacy for DNS queries and responses. However, it is unclear how a 83 client can locate an RR specific to its first-hop resolver. Finally, 84 others have suggested DNS-over-TLS. Recent work suggests DNS-over- 85 TLS ([draft-bortzmeyer-dnsop-privacy-sol]), and the Unbound DNS 86 software [unbound] includes a DNS-over-TLS implementation. However, 87 neither defines methods to negotiate TLS use over an existing 88 connection; unbound instead requires DNS-over-TLS to run on a 89 different port. 91 The mechanism described in this document enables DNS clients and 92 servers to upgrade an existing DNS-over-TCP connection to a DNS-over- 93 TLS connection. It is analogous to STARTTLS [RFC2595] used in SMTP 94 [RFC3207], IMAP [RFC3501] and POP [RFC1939]. 96 This document defines only the protocol extensions necessary to 97 support TLS negotiation. It does not describe how DNS clients might 98 validate server certificates or specify trusted certificate 99 authorities. Solutions for certificate authentication are outside 100 the scope of this document. 102 1.1. Reserved Words 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Protocol Changes 110 Clients and servers indicate their support for, and desire to use, 111 DNS-over-TLS by setting a bit in the Flags field of the EDNS0 112 [RFC6891] OPT meta-RR. The "TLS OK" (TO) bit is defined as the 113 second bit of the third and fourth bytes of the "extended RCODE and 114 flags" portion of the EDNS0 OPT meta-RR, immediately adjacent to the 115 "DNSSEC OK" (DO) bit [RFC4033]: 117 +0 (MSB) +1 (LSB) 118 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 119 0: | EXTENDED-RCODE | VERSION | 120 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 121 2: |DO|TO| Z | 122 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 124 2.1. Use by DNS Clients 126 2.1.1. Sending Queries 128 DNS clients MAY set the TO bit in queries sent using UDP transport to 129 signal their general ability to support DNS-over-TLS. Clients which 130 get no response to UDP TO=1 queries SHOULD retransmit them without 131 the TO bit set. 133 DNS clients MAY set the TO bit in the initial query sent to a server 134 using TCP transport to signal their desire that the TCP connection be 135 upgraded to TLS. DNS clients MUST NOT set the TO bit on subsequent 136 queries when using TCP or TLS transport (to avoid ambiguity). 138 Since the motivation for DNS-over-TLS is to preserve privacy, DNS 139 clients SHOULD use a query that reveals no private information in the 140 initial TO=1 query to a server. To provide a standard "dummy" query, 141 it is RECOMMENDED to send the initial query with RD=0, 142 QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT ("STARTTLS/CH/TXT") 143 analogous to administrative queries already in widespread use 144 [RFC4892]. 146 After sending the initial TO=1 query using TCP transport, DNS clients 147 MUST wait for the initial response before sending any subsequent 148 queries over the same TCP connection. 150 2.1.2. Receiving Responses 152 A DNS client that receives a response using UDP transport that has 153 the TO bit set MUST handle that response as usual. It MAY record the 154 server's support for DNS-over-TLS and use that information as part of 155 its server selection algorithm in the case where multiple servers are 156 available to service a particular query. 158 A DNS client that receives a response to its initial query using TCP 159 transport that has the TO bit set MUST immediately initiate a TLS 160 handshake using the procedure described in [RFC5246]. 162 A DNS client that receives a response to its initial query using TCP 163 transport that has the TO bit clear MUST not initiate a TLS handshake 164 and SHOULD utilize the existing TCP connection for subsequent 165 queries. DNS clients SHOULD remember server IP addresses that don't 166 support DNS-over-TLS (including TLS handshake failures) and SHOULD 167 NOT request DNS-over-TLS from them for reasonable period. (We 168 suggest 1 hour, or when the client discovers a new resolver.) 170 2.2. Use by DNS Servers 172 2.2.1. Receiving Queries 174 A DNS server receiving a query over UDP MUST ignore the TO bit. 176 A DNS server receiving a query over an existing TLS connection MUST 177 ignore the TO bit. 179 A DNS server receiving an initial query over TCP that has the TO bit 180 set MAY inform the client it is willing to establish a TLS session, 181 as described in the next section. 183 A DNS server receiving subsequent queries over TCP MUST ignore the TO 184 bit. (A client wishing to start TLS after the initial query MUST 185 open a new TCP connection to do so.) 187 2.2.2. Sending Responses 189 A DNS server sending a response over UDP SHOULD set the TO bit to 190 indicate its general support for DNS-over-TLS, as long as it is 191 willing and able to support a TLS connection with the particular 192 client. 194 A DNS server receiving an initial query over TCP that has the TO bit 195 set MAY set the TO bit in its response. The server MUST then proceed 196 with the TLS handshake protocol. 198 A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST 199 respond with RCODE=0 and a TXT RR in the Answer section. Contents of 200 the TXT RR are strictly informative (for humans) and MUST NOT be 201 interpreted by the client software. Recommended TXT RDATA values are 202 "STARTTLS" or "NO_TLS". 204 2.3. Established Sessions 206 After TLS negotiation completes, the connection will be encrypted and 207 is now protected from eavesdropping and normal DNS queries SHOULD 208 take place. 210 Both clients and servers SHOULD follow existing DNS-over-TCP timeout 211 rules, which are often implementation- and situation-dependent. In 212 the absence of any other advice, the RECOMMENDED timeout values are 213 30 seconds for recursive name servers, 60 seconds for clients of 214 recursive name servers, 10 seconds for authoritative name servers, 215 and 20 seconds for clients of authoritative name servers. Current 216 work in this area may assist DNS-over-TLS clients and servers select 217 useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns]. 219 As with current DNS-over-TCP, DNS servers MAY close the connection at 220 any time (e.g., due to resource constraints). As with current DNS- 221 over-TCP, clients MUST handle abrupt closes and be prepared to 222 reestablish connections and/or retry queries. DNS servers SHOULD use 223 the TLS close-notify request to shift TCP TIME-WAIT state to the 224 clients. 226 DNS servers SHOULD enable fast TLS session resumption [RFC5077] to 227 avoid keeping per-client session state. 229 2.4. Downgrade Attacks and Middleboxes 231 Middleboxes [RFC3234] may be present in some networks and have been 232 known to interfere with normal DNS resolution and create problems for 233 DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext 234 protocols that utilize "STARTTLS" signaling in a similar way. A DNS 235 client attempting DNS-over-TLS through a middlebox, or in the 236 presence of a downgrade attack, could have one of the following 237 outcomes (as discussed in prior RFCs [RFC3207]): 239 1. The DNS client sends a TO=1 query and receives a TO=0 response. 240 In this case there is no upgrade to TLS and DNS resolution occurs 241 normally, without encryption. 243 2. The DNS client sends a TO=1 query and receives a TO=1 response, 244 but the TLS handshake fails because the server's certificate 245 cannot be authenticated. In this case the client SHOULD close 246 the established connection and fall back to unencrypted DNS for a 247 reasonable period (as discussed in Section 2.1.2). 249 3. The DNS client sends a TO=1 query and receives a TO=1 response, 250 but the middlebox does not understand the TLS negotiation. 251 Middleboxes SHOULD clear TO in replies if they are not prepared 252 to pass through TLS negotiation. Clients SHOULD retry DNS 253 without TO set if negotiation fails, and then retry with TLS 254 after a reasonable period (see Section 2.1.2). 256 4. The DNS client sends a TO=1 query but receives no response at 257 all. The middlebox might be silently dropping the query due to 258 the presence of the TO bit, when it should, in fact, ignore and 259 pass through unknown flag bits [RFC6891]. The client SHOULD fall 260 back to normal (unencrypted) DNS for a reasonable period (as 261 discussed in Section 2.1.2). 263 In general, clients that attempt TLS and fail can either fall back on 264 unencrypted DNS, or wait and retry later, depending on their privacy 265 requirements. If the problem of middleboxes and threat of downgrade 266 attacks is too serious, the IETF might consider allocating a 267 dedicated port for DNS-over-TLS [RFC6335]. 269 3. Performance Considerations 271 DNS-over-TLS incurs additional latency at session startup. It also 272 requires additional state (memory) increased processing (CPU). 274 1. Latency: Compared to UDP, DNS-over-TCP requires an additional 275 round-trip-time (RTT) of latency to establish the connection. 276 The TLS handshake adds another two RTTs of latency. Clients and 277 servers should support connection keepalive (reuse) and out-of- 278 order processing to amortize connection setup costs. Moreover, 279 TLS connection resumption can further reduce the setup delay. 281 2. State: The use of connection-oriented TCP requires keeping 282 additional state in both kernels and applications. TLS has 283 marginal increases in state over TCP alone. The state 284 requirements are of particular concerns on servers with many 285 clients. Smaller timeout values will reduce the number of 286 concurrent connections, and servers can preemptively close 287 connections when resources limits are exceeded. 289 3. Processing: Use of TLS encryption algorithms results in slightly 290 higher CPU usage. Servers can choose to refuse new DNS-over-TCP 291 clients if processing limits are exceeded. 293 A full performance evaluation is outside the scope of this 294 specification. A more detailed analysis of the performance 295 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a 296 technical report [tdns]. 298 4. IANA Considerations 300 This document defines a new bit ("TO") in the Flags field of the 301 EDNS0 OPT meta-RR. At the time of approval of this draft in the 302 standards track, as per the IANA Considerations of RFC 6891, IANA is 303 requested to reserve the second leftmost bit of the flags as the TO 304 bit, immediately adjacent to the DNSSEC DO bit, as shown in 305 Section 2. 307 5. Security Considerations 309 The goal of this proposal is to address the security risks that arise 310 because DNS queries may be eavesdropped upon, as described above. 311 There are a number of residual risks that may impact this goal. 313 1. There are known attacks on TLS, such as person-in-the-middle and 314 protocol downgrade. These are general attacks on TLS and not 315 specific to DNS-over-TLS; we refer to the TLS RFCs for discussion 316 of these security issues. 318 2. Any protocol interactions prior to the TLS handshake are 319 performed in the clear and can be modified by a man-in-the-middle 320 attacker. For this reason, clients MAY discard cached 321 information about server capabilities advertised prior to the 322 start of the TLS handshake. 324 3. As with other uses of STARTTLS-upgrade to TLS, the mechanism 325 specified here is susceptible to downgrade attacks, where a 326 person-in-the-middle prevents a successful TLS upgrade. Keeping 327 track of servers known to support TLS (i.e., "pinning") enables 328 clients to detect downgrade attacks. For servers with no 329 connection history, clients may choose to refuse non-TLS DNS, or 330 they may continue without TLS, depending on their privacy 331 requirements. 333 4. This document does not propose new ideas for certificate 334 authentication for TLS in the context of DNS. Several external 335 methods are possible, although each has weaknesses. The current 336 Certificate Authority infrastructure [RFC5280] is used by HTTP/ 337 TLS [RFC2818]. With many trusted CAs, this approach has 338 recognized weaknesses [CA_Compromise]. Some work is underway to 339 partially address these concerns (for example, with certificate 340 pinning [certificate_pinning], but more work is needed. DANE 341 [RFC6698] provides mechanisms to root certificate trust with 342 DNSSEC. That use here must be carefully evaluated to address 343 potential issues in trust recursion. For stub-to-recursive 344 resolver use, certificate authentication is sometimes either easy 345 or nearly impossible. If the recursive resolver is manually 346 configured, its certificate can be authenticated when it is 347 configured. If the recursive resolver is automatically 348 configured (such as with DHCP [RFC2131]), it could use DHCP 349 authentication mechanisms [RFC3118]). 351 Ongoing discussion of opportunistic TLS (connections without CA 352 validation, [draft-hoffman-uta-opportunistic-tls]) may be relevant to 353 DNS-over-TLS. 355 6. Acknowledgments 357 We would like to thank Stephane Bortzmeyer, Brian Haberman, Paul 358 Hoffman, Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric 359 Osterweil and Glen Wiley for reviewing this Internet-draft, and to 360 Nikita Somaiya for early work on this idea. 362 Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is 363 partially sponsored by the U.S. Dept. of Homeland Security (DHS) 364 Science and Technology Directorate, HSARPA, Cyber Security Division, 365 BAA 11-01-RIKA and Air Force Research Laboratory, Information 366 Directorate under agreement number FA8750-12-2-0344, and contract 367 number D08PC75599. 369 7. References 371 7.1. Normative References 373 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 374 STD 13, RFC 1034, November 1987. 376 [RFC1035] Mockapetris, P., "Domain names - implementation and 377 specification", STD 13, RFC 1035, November 1987. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 383 "Transport Layer Security (TLS) Session Resumption without 384 Server-Side State", RFC 5077, January 2008. 386 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 387 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 389 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 390 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 392 7.2. Informative References 394 [CA_Compromise] 395 Infosec Island Admin, "CA Compromise", January 2012, . 400 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 401 STD 53, RFC 1939, May 1996. 403 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 404 RFC 2131, March 1997. 406 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 407 RFC 2595, June 1999. 409 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 411 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 412 Messages", RFC 3118, June 2001. 414 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 415 Transport Layer Security", RFC 3207, February 2002. 417 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 418 Issues", RFC 3234, February 2002. 420 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 421 4rev1", RFC 3501, March 2003. 423 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 424 Rose, "DNS Security Introduction and Requirements", 425 RFC 4033, March 2005. 427 [RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism 428 Identifying a Name Server Instance", RFC 4892, June 2007. 430 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 431 Housley, R., and W. Polk, "Internet X.509 Public Key 432 Infrastructure Certificate and Certificate Revocation List 433 (CRL) Profile", RFC 5280, May 2008. 435 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 436 Cheshire, "Internet Assigned Numbers Authority (IANA) 437 Procedures for the Management of the Service Name and 438 Transport Protocol Port Number Registry", BCP 165, 439 RFC 6335, August 2011. 441 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 442 of Named Entities (DANE) Transport Layer Security (TLS) 443 Protocol: TLSA", RFC 6698, August 2012. 445 [certificate_pinning] 446 OWASP, "Certificate and Public Key Pinning", . 450 [draft-bortzmeyer-dnsop-dns-privacy] 451 Bortzmeyer, S., "DNS Privacy issues", 452 draft-bortzmeyer-dnsop-dns-privacy-01 (work in progress), 453 November 2013, . 456 [draft-bortzmeyer-dnsop-privacy-sol] 457 Bortzmeyer, S., "Solutions to DNS privacy issues", 458 draft-bortzmeyer-dnsop-privacy-sol-00 (work in progress), 459 December 2013, . 462 [draft-dempsky-dnscurve] 463 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 464 in progress), August 2010, 465 . 467 [draft-hoffman-uta-opportunistic-tls] 468 Hoffman, P., "Opportunistic Encryption Using TLS", 469 draft-hoffman-uta-opportunistic-tls-00 (work in progress), 470 February 2014, . 473 [draft-osterweil-dane-ipsec] 474 Osterweil, E., Wiley, G., Mitchell, D., and A. Newton, 475 "Opportunistic Encryption with DANE Semantics and IPsec: 476 IPSECA", draft-osterweil-dane-ipsec-00 (work in progress), 477 February 2014, 478 . 481 [draft-wijngaards-confidentialdns] 482 Wijngaards, W., "Confidential DNS", 483 draft-wijngaards-dnsop-confidentialdns-00 (work in 484 progress), November 2013, . 487 [draft-wouters-edns-tcp-keepalive] 488 Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0 489 Option", draft-wouters-edns-tcp-keepalive-00 (work in 490 progress), October 2013, . 493 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 494 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 495 Privacy and Security", Technical report ISI-TR-688, 496 February 2014, . 499 [unbound] NLnet Labs, Verisign labs, "Unbound", December 2013, 500 . 502 Authors' Addresses 504 Zi Hu 505 USC/Information Sciences Institute 506 4676 Admiralty Way, Suite 1133 507 Marina del Rey, CA 90292 508 USA 510 Phone: +1 213 587-1057 511 Email: zihu@usc.edu 512 Liang Zhu 513 USC/Information Sciences Institute 514 4676 Admiralty Way, Suite 1133 515 Marina del Rey, CA 90292 516 USA 518 Phone: +1 310 448-8323 519 Email: liangzhu@usc.edu 521 John Heidemann 522 USC/Information Sciences Institute 523 4676 Admiralty Way, Suite 1001 524 Marina del Rey, CA 90292 525 USA 527 Phone: +1 310 822-1511 528 Email: johnh@isi.edu 530 Allison Mankin 531 Verisign Labs 532 12061 Bluemont Way 533 Reston, VA 20190 535 Phone: +1 703 948-3200 536 Email: amankin@verisign.com 538 Duane Wessels 539 Verisign Labs 540 12061 Bluemont Way 541 Reston, VA 20190 543 Phone: +1 703 948-3200 544 Email: dwessels@verisign.com