idnits 2.17.00 (12 Aug 2021) /tmp/idnits10835/draft-ietf-dnsop-edns-key-tag-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 : ---------------------------------------------------------------------------- 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 (July 8, 2016) is 2143 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) == Missing Reference: 'TBD' is mentioned on line 221, but not defined == Missing Reference: 'TBA' is mentioned on line 415, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Wessels 3 Internet-Draft Verisign 4 Intended status: Standards Track W. Kumari 5 Expires: January 9, 2017 Google 6 P. Hoffman 7 ICANN 8 July 8, 2016 10 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) 11 draft-ietf-dnsop-edns-key-tag-02 13 Abstract 15 The DNS Security Extensions (DNSSEC) were developed to provide origin 16 authentication and integrity protection for DNS data by using digital 17 signatures. These digital signatures can be verified by building a 18 chain-of-trust starting from a trust anchor and proceeding down to a 19 particular node in the DNS. This document specifies two different 20 ways for validating resolvers to signal to a server which keys are 21 referenced in their chain-of-trust. The data from such signaling 22 allow zone administrators to monitor the progress of rollovers in a 23 DNSSEC-signed zone. 25 This document describes two independent methods for validating 26 resolvers to publish their referenced keys: an EDNS option and a 27 differnt DNS query. The reason there are two methods instead of one 28 is some people see significant problems with each method. Having two 29 methods is clearly worse than having just one, but it is probably 30 better for the Internet than having no way to gain the information 31 from the resolvers. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3 69 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5 72 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5 74 4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6 75 4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6 76 4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6 77 4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 6 78 4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7 79 4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7 80 4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7 81 5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 8 82 5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8 83 5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8 84 5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 8 85 5.3.1. Interaction With Aggressive Negative Caching . . . . 9 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 88 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 10.2. Informative References . . . . . . . . . . . . . . . . . 11 93 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 96 1. Introduction 98 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and 99 [RFC4035] were developed to provide origin authentication and 100 integrity protection for DNS data by using digital signatures. 101 DNSSEC uses Key Tags to efficiently match signatures to the keys from 102 which they are generated. The Key Tag is a 16-bit value computed 103 from the RDATA portion of a DNSKEY RR using a formula not unlike a 104 ones-complement checksum. RRSIG RRs contain a Key Tag field whose 105 value is equal to the Key Tag of the DNSKEY RR that validates the 106 signature. 108 Likewise, Delegation Signer (DS) RRs also contain a Key Tag field 109 whose value is equal to the Key Tag of the DNSKEY RR to which it 110 refers. 112 This draft sets out to specify a way for validating resolvers to tell 113 a server in a DNS query which DNSSEC key(s) they would use to 114 validate responses from that zone. This is done in two ways: using 115 an EDNS option for use in the OPT meta-RR [RFC6891] that contains the 116 key tags (described in Section 4), and by periodically sending 117 special "key tag queries" to a server authoritative for the zone 118 (described in Section 5). 120 Each of these new signaling mechanisms is OPTIONAL to implement and 121 use. These mechanisms serve to measure the acceptance and use of new 122 DNSSEC trust anchors and key signing keys (KSKs). This signaling 123 data can be used by zone administrators as a gauge to measure the 124 successful deployment of new keys. This is of particular interest 125 for the DNS root zone in the event of key and/or algorithm rollovers 126 that rely on [RFC5011] to automatically update a validating DNS 127 resolver's trust anchor. 129 This document does not introduce new processes for rolling keys or 130 updating trust anchors. Rather, it specifies a means by which a DNS 131 query can signal the set of keys that a client uses for DNSSEC 132 validation. 134 1.1. Design Evolution 136 Initially this document was named draft-edns-key-tag and proposed 137 including Key Tag values in a new EDNS(0) option code. It was 138 modeled after [RFC6975], which provides DNSSEC algorithm signaling. 140 The authors received feedback from Working Group participants that it 141 might be better to convey Key Tags in QNAME of a separate DNS query, 142 rather than as an EDNS(0) option. Mostly this is because forwarding 143 (e.g. from stub to recursive to authoritative) could be problematic. 144 Reasons include: 146 1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not 147 be forwarded by default, as per [RFC6891]. 149 2. Middleboxes might block entire queries containing unknown EDNS(0) 150 option codes. 152 3. A recursive might need to remember Key Tag values (i.e., keep 153 state) received from its stub clients and then forward them at a 154 later opportunity. 156 One advantage of the EDNS(0) option code is that it is possible to 157 see that a stub client has a different Key Tag list than its 158 forwarder. In the QNAME-based approach, this is not possible because 159 queries originated by a stub and a forwarder are indistinguishable. 160 The authors feel this advantage is not sufficient to justify the 161 EDNS(0) approach. 163 One downside to the QNAME approach is that it uses a separate query, 164 whereas with EDNS(0) the Key Tag values are "piggy-backed" on to an 165 existing DNSKEY query. For this reason, this document recommends 166 only sending QNAME-based key tag queries for configured trust 167 anchors, although EDNS-based key tags can be sent with any DNSKEY 168 query. 170 Another downside to the QNAME-based approach is that since the trust 171 anchor zone might not contain labels matching the QNAME, these 172 queries could be subject to aggressive negative caching features now 173 in development by the Working Group. This could affect the amount of 174 signaling sent by some clients compared to others. 176 2. Requirements Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 3. Terminology 184 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 185 A validating security-aware resolver uses this public key or hash 186 as a starting point for building the authentication chain to a 187 signed DNS response. In general, a validating resolver will have 188 to obtain the initial values of its trust anchors via some secure 189 or trusted means outside the DNS protocol. Presence of a trust 190 anchor also implies that the resolver should expect the zone to 191 which the trust anchor points to be signed. (quoted from [RFC4033] 192 Section 2) 194 Key Tag: A 16-bit integer that identifies and enables efficient 195 selection of DNSSEC public keys. A Key Tag value can be computed 196 over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and 197 DS records can be used to help select the corresponding DNSKEY RR 198 efficiently when more than one candidate DNSKEY RR is available. 199 For most algorithms the Key Tag is a simple 16-bit modular sum of 200 the DNSKEY RDATA. See [RFC4034] Appendix B. 202 4. Using the edns-key-tag Option 204 4.1. Option Format 206 The edns-key-tag option is encoded as follows: 208 0 8 16 209 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 210 | OPTION-CODE | 211 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 212 | OPTION-LENGTH | 213 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 214 | KEY-TAG | 215 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 216 | ... / 217 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 219 where: 221 OPTION-CODE: The EDNS0 option code assigned to edns-key-tag, [TBD]. 223 OPTION-LENGTH: The value 2 x number of key-tag values present. 225 KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B). 227 4.2. Use By Queriers 229 A validating resolver sets the edns-key-tag option in the OPT meta-RR 230 when sending a DNSKEY query. The validating resolver SHOULD also set 231 the DNSSEC OK bit [RFC4034] to indicate that it wishes to receive 232 DNSSEC RRs in the response. 234 A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY 235 queries. 237 The KEY-TAG value(s) included in the edns-key-tag option represent 238 the Key Tag of the Trust Anchor or DNSKEY RR that will be used to 239 validate the expected response. When the client sends a DNSKEY 240 query, the edns-key-tag option represents the Key Tag(s) of the 241 KSK(s) of the zone for which the server is authoritative. A 242 validating resolver learns the Key Tag(s) of the KSK(s) from the 243 zone's DS record(s) (found in the parent), or from a configured trust 244 anchor. 246 A DNS client SHOULD include the edns-key-tag option when issuing a 247 DNSKEY query for a zone corresponding to a configured Trust Anchor. 249 A DNS client MAY include the edns-key-tag option when issuing a 250 DNSKEY query for a non-Trust Anchor zone (i.e., Key Tags learned via 251 DS records). Since some DNSSEC validators implement bottom-up 252 validation, non-Trust Anchor Key Tags zone might not be known at the 253 time of the query. Such a validator can include the edns-key-tag 254 option based on previously cached data. 256 A DNS client MUST NOT include Key Tag(s) for keys which are not 257 learned via either configured Trust Anchor or DS records. 259 Since the edns-key-tag option is only set in the query, if a client 260 sees these options in the response, no action needs to be taken and 261 the client MUST ignore the option values. 263 4.2.1. Stub Resolvers 265 Typically, stub resolvers rely on an upstream recursive server (or 266 cache) to provide a response. Optimal setting of the edns-key-tag 267 option depends on whether the stub resolver elects to perform its own 268 validation. 270 4.2.1.1. Validating Stub Resolvers 272 A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4034] to 273 indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG 274 RRs) in the response. Such validating resolvers SHOULD include the 275 edns-key-tag option in the OPT RR when sending a DNSKEY query. 277 4.2.1.2. Non-validating Stub Resolvers 279 The edns-key-tag option MUST NOT be included by non-validating stub 280 resolvers. 282 4.2.2. Recursive Resolvers 283 4.2.2.1. Validating Recursive Resolvers 285 A validating recursive resolver is, by definition, configured with at 286 least one trust anchor. Thus, a recursive resolver SHOULD include 287 the edns-key-tag option in its DNSKEY queries as described above. 289 In addition, the clients of a validating recursive resolver might be 290 configured to do their own validation, with their own trust 291 anchor(s). When a validating recursive resolver receives a query 292 that includes the edns-key-tag option with a Key Tag list that 293 differs from its own, it SHOULD forward both the client's Key Tag 294 list as well as its own. When doing so, the recursive resolver 295 SHOULD transmit the two Key Tag lists using separate instances of the 296 edns-key-tag option code in the OPT meta-RR. For example, if the 297 recursive resolver's Key Tag list is (19036, 12345) and the stub/ 298 client's list is (19036, 34567), the recursive would include the 299 edns-key-tag option twice: Once with values (19036, 12345) and once 300 with values (19036, 34567). 302 A validating recursive resolver MAY combine stub/client Key Tag 303 values from multiple incoming queries into a single outgoing query. 304 It is RECOMMENDED that implementations place reasonable limits on the 305 number of Key Tags to include in the outgoing edns-key-tag option. 307 If the client included the DO and Checking Disabled (CD) bits, but 308 did not include the edns-key-tag option in the query, the validating 309 recursive resolver MAY include the option with its own Key Tag values 310 in full. 312 Validating recursive resolvers MUST NOT set the edns-key-tag option 313 in the final response to the stub client. 315 4.2.2.2. Non-validating Recursive Resolvers 317 Recursive resolvers that do not validate responses SHOULD copy the 318 edns-key-tag option seen in received queries, as they represent the 319 wishes of the validating downstream resolver that issued the original 320 query. 322 4.3. Use By Responders 324 An authoritative name server receiving queries with the edns-key-tag 325 option MAY log or otherwise collect the Key Tag values to provide 326 information to the zone operator. 328 A responder MUST NOT include the edns-key-tag option in any DNS 329 response. 331 5. Using the Key Tag Query 333 5.1. Query Format 335 A key tag query consists of a standard DNS query of type NULL and of 336 class IN [RFC1035]. 338 The first component of the query name is the string "_ta-" followed 339 by a hyphen-separated list of hexadecimal-encoded Key Tag values. 340 The zone name corresponding to the trust anchor is appended to this 341 first component. 343 For example, a validating DNS resolver that has a single root zone 344 trust anchor with key tag 17476 (decimal) would originate a query of 345 the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444. 347 A validating DNS resolver that has a three trust anchors for the 348 example.com zone with key tags 31589, 43547, 31406 (decimal) would 349 originate a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-7b65- 350 aa1b-7aa3.example.com. 352 5.2. Use By Queriers 354 A validating DNS resolver (stub or recursive) SHOULD originate a key 355 tag query whenever it also originates a DNSKEY query for a configured 356 Trust Anchor zone. In other words, the need to issue a DNSKEY query 357 is also the trigger to issue a key tag query. 359 The value(s) included in the key tag query represent the Key Tag(s) 360 of the Trust Anchor that will be used to validate the expected DNSKEY 361 response. 363 A DNS validating resolver SHOULD NOT originate key tag queries when 364 also originating DNSKEY queries for non-Trust Anchor zones. 366 A non-validating DNS resolver MUST NOT originate key tag queries. 368 DNS resolvers with caches SHOULD cache and reuse the response to a 369 key tag query just as it would any other response. 371 5.3. Use By Responders 373 An authoritative name server receiving key tag queries MAY log or 374 otherwise collect the Key Tag values to provide information to the 375 zone operator. 377 An authoritative name server MUST generate an appropriate response to 378 the key tag query. Unless the zone operator has intentionally added 379 "_ta-xxxx" records to the zone, the server MUST generate an NXDOMAIN 380 response. The zone operator might want to add specific key tag 381 records to its zone, perhaps with specific TTLs, to affect the 382 frequency of key tag queries from clients. [ Note RFC1035 says NULL 383 RRs are not allowed in master files, but I believe that to be 384 incorrect ] 386 5.3.1. Interaction With Aggressive Negative Caching 388 Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec- 389 aggressiveuse] may also affect the quality of key tag signaling. 390 When the response code for a key tag query is NXDOMAIN, DNS resolvers 391 that implement aggressive negative caching will send fewer key tag 392 queries than resolvers that do not implement it. 394 For this reason, zone operators might choose to create records 395 corresponding to expected key tag queries. During a rollover from 396 key tag 1111 (hex) to key tag 2222 (hex), the zone could include the 397 following records: 399 _ta-1111 IN NULL \# 0 400 _ta-2222 IN NULL \# 0 401 _ta-1111-2222 IN NULL \# 0 402 _ta-2222-1111 IN NULL \# 0 404 [ most likely someone will suggest that key tag values should be 405 ordered to reduce the record count from 4 to 3 ] 407 6. IANA Considerations 409 The IANA is directed to assign an EDNS0 option code for the edns-key- 410 tag option from the DNS EDNS0 Option Codes (OPT) registry as follows: 412 +-------+--------------+----------+-----------------+ 413 | Value | Name | Status | Reference | 414 +-------+--------------+----------+-----------------+ 415 | [TBA] | edns-key-tag | Optional | [This document] | 416 +-------+--------------+----------+-----------------+ 418 7. Security Considerations 420 This document specifies a way for a client to signal its trust anchor 421 knowledge to a cache or server. The goal of these optional 422 mechanisms is to signal new trust anchor uptake in clients to allow 423 zone administrators to know when it is possible to complete a key 424 rollover in a DNSSEC-signed zone. 426 There is a possibility that an eavesdropper or server could infer the 427 validator in use by a client by the Key Tag list seen. This may 428 allow an attacker to find validators using old, possibly broken, 429 keys. It could also be used to identify the validator or narrow down 430 the possible validator implementations in use by a client, which 431 could have a known vulnerability that could be exploited by the 432 attacker. 434 Consumers of data collected from the mechanisms are advised that 435 provided Key Tag values might be "made up" by some DNS clients with 436 malicious or at least mischievous intentions. For example, an 437 attacker with sufficient resources might try to generate large 438 numbers of queries including only old Key Tag values, with the 439 intention of delaying the completion of a key rollover. 441 DNSSEC does not require keys in a zone to have unique Key Tags. 442 During a rollover there is a small possibility that an old key and a 443 new key will have identical Key Tag values. Zone operators relying 444 on the edns-key-tag mechanism SHOULD take care to ensure that new 445 keys have unique Key Tag values. 447 8. Privacy Considerations 449 This proposal adds additional, optional "signaling" to DNS queries in 450 the form of Key Tag values. While Key Tag values themselves are not 451 considered private information, it may be possible for an 452 eavesdropper to use Key Tag values as a fingerprinting technique to 453 identify particular DNS validating clients. This may be especially 454 true if the validator is configured with trust anchor for zones in 455 addition to the root zone. 457 A validating resolver need not transmit the key tags in every 458 applicable query. Due to privacy concerns, such a resolver MAY 459 choose to transmit the key tags for a subset of queries (e.g., every 460 25th time), or by random chance with a certain probability (e.g., 461 5%). 463 Implementations of this specification MAY be administratively 464 configured to only transmit the key tags for certain zones. For 465 example, the software's configuration file may specify a list of 466 zones for which use of the mechanisms described here is allowed or 467 denied. Since the primary motivation for this specification is to 468 provide operational measurement data for root zone key rollovers, it 469 is RECOMMENDED that implementations at least include the edns-key-tag 470 option for root zone DNSKEY queries. 472 9. Acknowledgments 474 This document was inspired by and borrows heavily from [RFC6975] by 475 Scott Rose and Steve Crocker. The authors would like to thank Mark 476 Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim 477 Wicinski, Suzanne Woolf, and other members of the dnsop working group 478 for their input. 480 10. References 482 10.1. Normative References 484 [RFC1035] Mockapetris, P., "Domain names - implementation and 485 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 486 November 1987, . 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 494 Rose, "DNS Security Introduction and Requirements", 495 RFC 4033, DOI 10.17487/RFC4033, March 2005, 496 . 498 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 499 Rose, "Resource Records for the DNS Security Extensions", 500 RFC 4034, DOI 10.17487/RFC4034, March 2005, 501 . 503 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 504 Rose, "Protocol Modifications for the DNS Security 505 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 506 . 508 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 509 for DNS (EDNS(0))", STD 75, RFC 6891, 510 DOI 10.17487/RFC6891, April 2013, 511 . 513 10.2. Informative References 515 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 516 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 517 September 2007, . 519 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 520 Algorithm Understanding in DNS Security Extensions 521 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 522 . 524 Appendix A. Changes / Author Notes. 526 [RFC Editor: Please remove this section before publication] 528 From -01 to -02: 530 o Added QNAME-based method of signaling key tags. 532 o Added Paul Hoffman as coauthor. 534 From -00 to -01: 536 o Changed how a recursive should combine a stub's key tag values 537 with its own. Previously it was to be a union of key tag values. 538 Now it is a separate instance of the option code for recursive and 539 stub. 541 o Added Warren as coauthor. 543 Authors' Addresses 545 Duane Wessels 546 Verisign 547 12061 Bluemont Way 548 Reston, VA 20190 549 United States 551 Phone: +1 703 948-3200 552 Email: dwessels@verisign.com 553 URI: http://verisigninc.com 555 Warren Kumari 556 Google 557 1600 Amphitheatre Parkway 558 Mountain View, CA 94043 559 United States 561 Email: warren@kumari.net 562 Paul Hoffman 563 ICANN 565 Email: paul.hoffman@icann.org