idnits 2.17.00 (12 Aug 2021) /tmp/idnits9295/draft-ietf-dnsop-edns-key-tag-04.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2017) is 1950 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 218, but not defined == Missing Reference: 'TBA' is mentioned on line 416, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 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: July 21, 2017 Google 6 P. Hoffman 7 ICANN 8 January 17, 2017 10 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) 11 draft-ietf-dnsop-edns-key-tag-04 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 (see Section 1.1 for the 22 rationale). The data from such signaling allow zone administrators 23 to monitor the progress of rollovers in a DNSSEC-signed zone. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 21, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5 64 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5 66 4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6 67 4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6 68 4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6 69 4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 6 70 4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7 71 4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7 72 4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7 73 5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 8 74 5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8 75 5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8 76 5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 8 77 5.3.1. Interaction With Aggressive Negative Caching . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 10.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and 91 [RFC4035] were developed to provide origin authentication and 92 integrity protection for DNS data by using digital signatures. 93 DNSSEC uses Key Tags to efficiently match signatures to the keys from 94 which they are generated. The Key Tag is a 16-bit value computed 95 from the RDATA portion of a DNSKEY RR using a formula not unlike a 96 ones-complement checksum. RRSIG RRs contain a Key Tag field whose 97 value is equal to the Key Tag of the DNSKEY RR that validates the 98 signature. 100 Likewise, Delegation Signer (DS) RRs also contain a Key Tag field 101 whose value is equal to the Key Tag of the DNSKEY RR to which it 102 refers. 104 This document specifies how validating resolvers can tell a server, 105 in a DNS query, which DNSSEC key(s) they would use to validate the 106 server's responses. It describes two independent methods for 107 conveying Key Tag information bewteen clients and servers: placing an 108 EDNS option in the OPT meta-RR [RFC6891] that contains the key tags 109 (described in Section 4), and by periodically sending special "key 110 tag queries" to a server authoritative for the zone (described in 111 Section 5). 113 Each of these new signaling mechanisms is OPTIONAL to implement and 114 use. These mechanisms serve to measure the acceptance and use of new 115 DNSSEC trust anchors and key signing keys (KSKs). This signaling 116 data can be used by zone administrators as a gauge to measure the 117 successful deployment of new keys. This is of particular interest 118 for the DNS root zone in the event of key and/or algorithm rollovers 119 that rely on [RFC5011] to automatically update a validating DNS 120 resolver's trust anchor. 122 This document does not introduce new processes for rolling keys or 123 updating trust anchors. Rather, it specifies a means by which a DNS 124 query can signal the set of keys that a client uses for DNSSEC 125 validation. 127 1.1. Design Evolution 129 Initially, when the work on this document started, it proposed 130 including Key Tag values in a new EDNS(0) option code. It was 131 modeled after [RFC6975], which provides DNSSEC algorithm signaling. 133 The authors received feedback from dnsop Working Group participants 134 that it might be better to convey Key Tags in QNAME of a separate DNS 135 query, rather than as an EDNS(0) option. Mostly this is because 136 forwarding (e.g. from stub to recursive to authoritative) could be 137 problematic. Reasons include: 139 1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not 140 be forwarded by default, as per [RFC6891]. 142 2. Middleboxes might block entire queries containing unknown EDNS(0) 143 option codes. 145 3. A recursive might need to remember Key Tag values (i.e., keep 146 state) received from its stub clients and then forward them at a 147 later opportunity. 149 One advantage of the EDNS(0) option code is that it is possible to 150 see that a stub client has a different Key Tag list than its 151 forwarder. In the QNAME-based approach, this is not possible because 152 queries originated by a stub and a forwarder are indistinguishable. 153 The authors feel this advantage is not sufficient to justify the 154 EDNS(0) approach. 156 One downside to the QNAME approach is that it uses a separate query, 157 whereas with EDNS(0) the Key Tag values are "piggy-backed" on to an 158 existing DNSKEY query. For this reason, this document recommends 159 only sending QNAME-based key tag queries for configured trust 160 anchors, although EDNS-based key tags can be sent with any DNSKEY 161 query. 163 Another downside to the QNAME-based approach is that since the trust 164 anchor zone might not contain labels matching the QNAME, these 165 queries could be subject to aggressive negative caching features now 166 in development by the Working Group. This could affect the amount of 167 signaling sent by some clients compared to others. 169 A probably minor downside to the QNAME-based approach is that it 170 cannot be used with extremely long query names if the addition of the 171 prefix would cause the name to be longer than 255 octets. 173 2. Requirements Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 3. Terminology 181 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 182 A validating security-aware resolver uses this public key or hash 183 as a starting point for building the authentication chain to a 184 signed DNS response. In general, a validating resolver will have 185 to obtain the initial values of its trust anchors via some secure 186 or trusted means outside the DNS protocol. Presence of a trust 187 anchor also implies that the resolver should expect the zone to 188 which the trust anchor points to be signed. (quoted from [RFC4033] 189 Section 2) 191 Key Tag: A 16-bit integer that identifies and enables efficient 192 selection of DNSSEC public keys. A Key Tag value can be computed 193 over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and 194 DS records can be used to help select the corresponding DNSKEY RR 195 efficiently when more than one candidate DNSKEY RR is available. 196 For most algorithms the Key Tag is a simple 16-bit modular sum of 197 the DNSKEY RDATA. See [RFC4034] Appendix B. 199 4. Using the edns-key-tag Option 201 4.1. Option Format 203 The edns-key-tag option is encoded as follows: 205 0 8 16 206 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 207 | OPTION-CODE | 208 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 209 | OPTION-LENGTH | 210 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 211 | KEY-TAG | 212 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 213 | ... / 214 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 216 where: 218 OPTION-CODE: The EDNS0 option code assigned to edns-key-tag, [TBD]. 220 OPTION-LENGTH: The value 2 x number of key-tag values present. 222 KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B). 224 4.2. Use By Queriers 226 A validating resolver sets the edns-key-tag option in the OPT meta-RR 227 when sending a DNSKEY query. The validating resolver SHOULD also set 228 the DNSSEC OK bit [RFC4034] to indicate that it wishes to receive 229 DNSSEC RRs in the response. 231 A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY 232 queries. 234 The KEY-TAG value(s) included in the edns-key-tag option represent 235 the Key Tag of the Trust Anchor or DNSKEY RR that will be used to 236 validate the expected response. When the client sends a DNSKEY 237 query, the edns-key-tag option represents the Key Tag(s) of the 238 KSK(s) of the zone for which the server is authoritative. A 239 validating resolver learns the Key Tag(s) of the KSK(s) from the 240 zone's DS record(s) (found in the parent), or from a configured trust 241 anchor. 243 A DNS client SHOULD include the edns-key-tag option when issuing a 244 DNSKEY query for a zone corresponding to a configured Trust Anchor. 246 A DNS client MAY include the edns-key-tag option when issuing a 247 DNSKEY query for a non-Trust Anchor zone (i.e., Key Tags learned via 248 DS records). Since some DNSSEC validators implement bottom-up 249 validation, non-Trust Anchor Key Tags zone might not be known at the 250 time of the query. Such a validator can include the edns-key-tag 251 option based on previously cached data. 253 A DNS client MUST NOT include Key Tag(s) for keys which are not 254 learned via either configured Trust Anchor or DS records. 256 Since the edns-key-tag option is only set in the query, if a client 257 sees these options in the response, no action needs to be taken and 258 the client MUST ignore the option values. 260 4.2.1. Stub Resolvers 262 Typically, stub resolvers rely on an upstream recursive server (or 263 cache) to provide a response. Optimal setting of the edns-key-tag 264 option depends on whether the stub resolver elects to perform its own 265 validation. 267 4.2.1.1. Validating Stub Resolvers 269 A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4034] to 270 indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG 271 RRs) in the response. Such validating resolvers SHOULD include the 272 edns-key-tag option in the OPT RR when sending a DNSKEY query. 274 4.2.1.2. Non-validating Stub Resolvers 276 The edns-key-tag option MUST NOT be included by non-validating stub 277 resolvers. 279 4.2.2. Recursive Resolvers 280 4.2.2.1. Validating Recursive Resolvers 282 A validating recursive resolver is, by definition, configured with at 283 least one trust anchor. Thus, a recursive resolver SHOULD include 284 the edns-key-tag option in its DNSKEY queries as described above. 286 In addition, the clients of a validating recursive resolver might be 287 configured to do their own validation, with their own trust 288 anchor(s). When a validating recursive resolver receives a query 289 that includes the edns-key-tag option with a Key Tag list that 290 differs from its own, it SHOULD forward both the client's Key Tag 291 list as well as its own. When doing so, the recursive resolver 292 SHOULD transmit the two Key Tag lists using separate instances of the 293 edns-key-tag option code in the OPT meta-RR. For example, if the 294 recursive resolver's Key Tag list is (19036, 12345) and the stub/ 295 client's list is (19036, 34567), the recursive would include the 296 edns-key-tag option twice: Once with values (19036, 12345) and once 297 with values (19036, 34567). 299 A validating recursive resolver MAY combine stub/client Key Tag 300 values from multiple incoming queries into a single outgoing query. 301 It is RECOMMENDED that implementations place reasonable limits on the 302 number of Key Tags to include in the outgoing edns-key-tag option. 304 If the client included the DO and Checking Disabled (CD) bits, but 305 did not include the edns-key-tag option in the query, the validating 306 recursive resolver MAY include the option with its own Key Tag values 307 in full. 309 Validating recursive resolvers MUST NOT set the edns-key-tag option 310 in the final response to the stub client. 312 4.2.2.2. Non-validating Recursive Resolvers 314 Recursive resolvers that do not validate responses SHOULD copy the 315 edns-key-tag option seen in received queries, as they represent the 316 wishes of the validating downstream resolver that issued the original 317 query. 319 4.3. Use By Responders 321 An authoritative name server receiving queries with the edns-key-tag 322 option MAY log or otherwise collect the Key Tag values to provide 323 information to the zone operator. 325 A responder MUST NOT include the edns-key-tag option in any DNS 326 response. 328 5. Using the Key Tag Query 330 5.1. Query Format 332 A key tag query consists of a standard DNS query of type NULL and of 333 class IN [RFC1035]. 335 The first component of the query name is the string "_ta-" followed 336 by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag 337 values. The zone name corresponding to the trust anchor is appended 338 to this first component. 340 For example, a validating DNS resolver that has a single root zone 341 trust anchor with key tag 17476 (decimal) would originate a query of 342 the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444. 344 Hexadecimal values MUST be zero-padded. For example, if the key tag 345 is 999 (decimal), it is represented in hexadecimal as 03e7. 347 When representing multiple key tag values, they MUST be sorted in 348 order from smallest to largest. For example, A validating DNS 349 resolver that has a three trust anchors for the example.com zone with 350 key tags 1589, 43547, 31406 (decimal) would originate a query of the 351 form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com. 353 5.2. Use By Queriers 355 A validating DNS resolver (stub or recursive) SHOULD originate a key 356 tag query whenever it also originates a DNSKEY query for a configured 357 Trust Anchor zone. In other words, the need to issue a DNSKEY query 358 is also the trigger to issue a key tag query. 360 The value(s) included in the key tag query represent the Key Tag(s) 361 of the Trust Anchor that will be used to validate the expected DNSKEY 362 response. 364 A DNS validating resolver SHOULD NOT originate key tag queries when 365 also originating DNSKEY queries for non-Trust Anchor zones. 367 A non-validating DNS resolver MUST NOT originate key tag queries. 369 DNS resolvers with caches SHOULD cache and reuse the response to a 370 key tag query just as it would any other response. 372 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. A server does not need to have built-in logic 379 that determines the response to key tag queries: the response code is 380 determined by whether the data is in the zone file or covered by 381 wildcard. The zone operator might want to add specific key tag 382 records to its zone, perhaps with specific TTLs, to affect the 383 frequency of key tag queries from clients. [ Note RFC1035 says NULL 384 RRs are not allowed in master files, but I believe that to be 385 incorrect ] 387 5.3.1. Interaction With Aggressive Negative Caching 389 Aggressive NSEC/NSEC3 negative caching 390 [draft-ietf-dnsop-nsec-aggressiveuse] may also affect the quality of 391 key tag signaling. When the response code for a key tag query is 392 NXDOMAIN, DNS resolvers that implement aggressive negative caching 393 will send fewer key tag queries than resolvers that do not implement 394 it. 396 For this reason, zone operators might choose to create records 397 corresponding to expected key tag queries. During a rollover from 398 key tag 1111 (hex) to key tag 2222 (hex), the zone could include the 399 following records: 401 _ta-1111 IN NULL \# 0 402 _ta-2222 IN NULL \# 0 403 _ta-1111-2222 IN NULL \# 0 405 Recall that when multiple key tags are present, the originating 406 client MUST sort them from smallest to largest in the query name. 408 6. IANA Considerations 410 The IANA is directed to assign an EDNS0 option code for the edns-key- 411 tag option from the DNS EDNS0 Option Codes (OPT) registry as follows: 413 +-------+--------------+----------+-----------------+ 414 | Value | Name | Status | Reference | 415 +-------+--------------+----------+-----------------+ 416 | [TBA] | edns-key-tag | Optional | [This document] | 417 +-------+--------------+----------+-----------------+ 419 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, November 1987. 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 491 Rose, "DNS Security Introduction and Requirements", RFC 492 4033, March 2005. 494 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 495 Rose, "Resource Records for the DNS Security Extensions", 496 RFC 4034, March 2005. 498 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 499 Rose, "Protocol Modifications for the DNS Security 500 Extensions", RFC 4035, March 2005. 502 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 503 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 505 10.2. Informative References 507 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 508 Trust Anchors", STD 74, RFC 5011, September 2007. 510 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 511 Algorithm Understanding in DNS Security Extensions 512 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 513 . 515 [draft-ietf-dnsop-nsec-aggressiveuse] 516 Fujiwara, K., "Aggressive use of NSEC/NSEC3", 2016. 518 Appendix A. Changes / Author Notes. 520 [RFC Editor: Please remove this section before publication] 522 From -01 to -02: 524 o Added QNAME-based method of signaling key tags. 526 o Added Paul Hoffman as coauthor. 528 From -00 to -01: 530 o Changed how a recursive should combine a stub's key tag values 531 with its own. Previously it was to be a union of key tag values. 532 Now it is a separate instance of the option code for recursive and 533 stub. 535 o Added Warren as coauthor. 537 Authors' Addresses 539 Duane Wessels 540 Verisign 541 12061 Bluemont Way 542 Reston, VA 20190 543 United States 545 Phone: +1 703 948-3200 546 Email: dwessels@verisign.com 547 URI: http://verisigninc.com 549 Warren Kumari 550 Google 551 1600 Amphitheatre Parkway 552 Mountain View, CA 94043 553 United States 555 Email: warren@kumari.net 557 Paul Hoffman 558 ICANN 560 Email: paul.hoffman@icann.org