idnits 2.17.1 draft-watson-dinrg-delmap-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 25, 2019) is 1821 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '32' on line 417 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Li 3 Internet-Draft EFF 4 Intended status: Experimental C. Man 5 Expires: October 27, 2019 Stanford University 6 J. Watson 7 UC Berkeley 8 April 25, 2019 10 Delegated Distributed Mappings 11 draft-watson-dinrg-delmap-02 13 Abstract 15 Delegated namespaces underpin almost every Internet-scale system - 16 domain name management, IP address allocation, Public Key 17 Infrastructure, etc. - but are centrally managed by entities with 18 unilateral revocation authority and no common interface. This draft 19 specifies a generalized scheme for delegation that supports explicit 20 time-bound guarantees and limits misuse. Mappings may be secured by 21 any general purpose distributed consensus protocol that supports 22 voting; clients can query the local state of any number of 23 participants and receive the correct result, barring a compromise at 24 the consensus layer. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 27, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Cells . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Prefix-based Delegation Correctness . . . . . . . . . . . 7 65 2.4. Root Key Listing . . . . . . . . . . . . . . . . . . . . 7 66 3. Interacting with a Consensus Node . . . . . . . . . . . . . . 8 67 3.1. Storage Format . . . . . . . . . . . . . . . . . . . . . 8 68 3.2. Client Interface . . . . . . . . . . . . . . . . . . . . 9 69 4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2. Validation . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.3. SCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 6.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Internet entities rely heavily on delegated namespaces to function 83 properly. Typical web services have been delegated a domain name 84 (after negotitation with an appropriate registrar) under which they 85 host the entirety of their public-facing content, or obtain a public 86 IP range from their ISP, which itself has been delegated to 87 intermediary registries by the Internet Numbers Registry [RFC7249]. 88 An enormous amount of economic value is therefore placed in these 89 assignments (in this draft, _mappings_) yet they are dangerously 90 ephemeral. Delegating authorities, either maliciously or 91 accidentally, may unilaterally revoke or replace mappings they've 92 made, compromising infrastructure security. Presented in this draft 93 is a generalized mechanism for securely managing such mappings and 94 their delegations. Known entities identified by public key are 95 assigned namespaces (e.g. domain prefixes) under which they are 96 authorized to create mapping records, or _cells_. Cells in a 97 namespace are grouped into logical units we term _tables_. 99 Alone, this structure does not ensure security, given that any 100 hosting server could arbitrarily modify cells or serve bogus entries 101 to unwitting clients. We maintain security and consistency by 102 relying on a distributed consensus algorithm. While detailed 103 descriptions of varying consensus protocols are out of scope for this 104 draft, we provide for a general-purpose interface between the 105 delegation structure and a consensus layer. At a minimum, the 106 consensus layer must apply mapping updates in a consistent order, 107 prevent equivocation, disallow unauthorized modification, grant 108 consensus nodes the ability to enforce high-level rules associated 109 with the tables, and perform voting among nodes to decide top-level 110 governance. We find that federated protocols such as the Stellar 111 Consensus Protocol [I-D.mazieres-dinrg-scp] are promising given their 112 capability for open participation, broad diversity of interests among 113 consensus participants, and providing accountability for malicious 114 behavior. Clients may query any number of trusted servers to 115 retrieve a correct result, barring widespread collusion. 117 The ability to impose consistency yields several useful properties. 118 The foremost is enforcing delegation semantics: a table's authority 119 may choose to recursively delegate a portion of its own namespace, 120 but must document the specific range and delegee in one of its 121 table's cells. Since delegation forms a new table, for which a 122 delegee is the sole authority, assigned namespace ranges must be 123 unique. Consensus is also used to enforce that the delegating 124 authority not make modifications to any delegated table and thus need 125 not be trusted by the delegee. 127 In addition, we provide explicit support for commitments that enforce 128 an explicit lower-bound on the duration of delegations. Otherwise 129 valid changes to cells that have a valid commitment are disallowed, 130 including revoking delegations. Upon expiration, however, the same 131 namespace may be delegated to another party. 133 Finally, decentralized infrastructure is highly visible and commonly 134 misused. As mappings are replicated among consensus nodes, of 135 primary concern is resource exhaustion. We limit undesired abuse of 136 the structure by embedding recursive scale restrictions inside 137 mappings, verified and ratified at consensus time. Combined with 138 time-bounded delegations, this ensures that the system is resistant 139 to spam in the short-term and can remove misbehaving hierarchies in 140 the long-term. 142 The remainder of this draft specifies the structure for authenticated 143 mapping management as well as its interfaces to consensus protocol 144 implementations and users. 146 2. Structure 148 Trust within the delegation structure is based on public key 149 signatures. Namespace authorities must sign mapping additions, 150 modifications, delegations, and revocations to their table as proof 151 to the consensus participants that such changes are legitimate. For 152 the sake of completeness, the public key and signature types are 153 detailed below. All types in this draft are described in XDR 154 [RFC4506]. 156 typedef publickey opaque<>; /* Typically a 256 byte RSA signature */ 158 struct signature { 159 publickey pk; 160 opaque data<>; 161 }; 163 2.1. Cells 165 Cells are the basic unit of the delegation structure. In general, 166 they compose an authenticated record of a mapping that may be queried 167 by clients. We describe two types of cells: 169 enum celltype { 170 VALUE = 0, 171 DELEGATE = 1 172 }; 174 Value cells store individual mapping values. They resolve a lookup 175 key to an arbitrary value, for example, an encryption key associated 176 with an email address or the zone files associated with a particular 177 domain. The public key of the cell's owner (e.g. the email account 178 holder, the domain owner) is also included, as well as a signature 179 authenticating the current version of the cell. Since the cell's 180 contents are controlled by the owner, its "value_sig" must be made by 181 the "owner_key". The cell owner may rotate their public key at any 182 time by signing the update with the old key. 184 struct valuecell { 185 opaque value<>; 186 publickey owner_key; 187 /* Owner signs contents */ 188 signature value_sig; 189 }; 191 Delegate cells have a similar structure but different semantics. 192 Rather than resolving to an individual mapping, they authorize the 193 _delegee_ to create arbitrary value cells within a table mapped to 194 the assigned namespace. This namespace must be a subset of the 195 _delegator_'s own namespace range. Like the table authority, the 196 delegee is uniquely identified by their public key. Each delegate 197 cell and subsequent updates to the cell are signed by the delegator - 198 this ensures that the delegee cannot unilaterally modify its 199 namespace, which limits the range of mappings they can create to 200 those legitimately assigned to them. 202 struct delegatecell { 203 opaque namespace<>; 204 publickey delegee; 205 /* Table authority controls delegations, not delegee */ 206 signature delegation_sig; 207 unsigned int allowance; 208 }; 210 Both cell types share a set of common data members, namely a set of 211 UNIX timestamps recording the creation time and, if applicable, the 212 time of last modification. An additional commitment timestamp must 213 be present in every cell. Each commitment is an explicit guarantee 214 on behalf of the table's authority that the mapping will remain valid 215 until at least the time specified. Therefore, while value cell 216 owners may modify their cell's contents at any time (e.g. this scheme 217 supports key rotation), the authority cannot change or remove the 218 cell until its commitment expires, as enforced by the consensus 219 nodes. Similarly, delegated namespaces are guaranteed to be valid 220 until the commitment timestamp expiration, although after expiration, 221 they can be reassigned to other parties. Likely, most long-term 222 delegations will be renewed (with a new commitment timestamp) before 223 the expiration of the current period. The tradeoff between 224 protecting delegees from arbitrary authority action and allowing 225 quick delegation reconfiguration is customizable to the use case. 226 Likely, widely-used services will see larger delegation periods for 227 stability whereas small namespaces with relatively unknown delegees 228 will experience shorter delegations. 230 An _allowance_ must be provided, which limits the upper-bound size of 231 a delegated table. For value cells, the allowance value is ignored 232 and set to 0. Importantly, for delegate cells, an allowance with 233 value 0 indicates no limit is placed on the size of the delegated 234 table. Given that the delegee has complete control over the contents 235 of their table, it is emphatically not recommended to grant a 236 delegatecell an unlimited allowance, in order to limit the storage 237 burden on consensus nodes. This limit is recursive along delegations 238 - the total number of cells in a table plus the sum of allowances 239 among its "delegatecells" must be less than or equal to the table's 240 allowance, if non-zero. Futher, a table with a non-zero allowance 241 may not grant a delegee an unlimited allowance. These properties 242 must be validated during consensus before adding new cells to a 243 table, which can be performed at every consensus node because table 244 entry counts are visible publicly. 246 Finally, a valid table cell's timestamps and allowance is signed by 247 the table authority and placed in "authority_sig". 249 union innercell switch (celltype type) { 250 case VALUE: 251 valuecell vcell; 252 case DELEGATE: 253 delegatecell dcell; 254 }; 256 struct cell { 257 /* 64-bit UNIX timestamps */ 258 unsigned hyper create_time; 259 unsigned hyper *revision_time; 260 unsigned hyper commitment_time; 261 /* Ignored by value cells */ 262 unsigned int allowance; 263 signature authority_sig; 264 innercell c; 265 } 267 2.2. Tables 269 Every cell is stored in a table, which groups all the mappings 270 created by a single authority public key for a specific namespace. 271 Individual cells are referenced by an application-specific label in a 272 lookup table. _The combination of a lookup key and a referenced cell 273 value forms a mapping_. 275 struct tableentry { 276 opaque lookup_key<>; 277 cell c; 278 } 280 Delegating the whole or part of a namespace requires adding a new 281 lookup key for the namespace and a matching delegate cell. Each 282 delegation must be validated in the context of the other table 283 entries and the table itself. For example, the owner of a table 284 delegated an /8 IPv4 block must not to delegate the same /16 block to 285 two different tables. 287 struct table { 288 tableentry entries<>; 289 }; 291 2.3. Prefix-based Delegation Correctness 293 To generalize correctness, each table must conform with a prefix- 294 based rule: for every cell with value or delegation subset "c" in a 295 table controlling namespace "n", "n" must (1) be a prefix of "c" and 296 (2) there cannot exist another cell with value or delegation subset 297 "c2" such that "c" is a prefix of "c2". 299 While there exist many more hierarchical naming schemes, many can be 300 simply represented in a prefix scheme. For example, suffix-based 301 delegations, including domain name hierarchies, can use reversed keys 302 internally and perform a swap in the application layer before 303 displaying any results to clients. Likewise, 'flat' delegation 304 schemes where there is no explicit restriction can use an empty 305 prefix. 307 2.4. Root Key Listing 309 Each linked group of delegation tables for a particular namespace is 310 rooted by a public key stored in a flat root key listing, which is 311 the entry point for lookup operations. Well-known application 312 identifier strings denote the namespace they control. We describe 313 below how lookups can be accomplished on the mappings. 315 struct rootentry { 316 publickey namespace_root_key; 317 string application_identifier<>; 318 signature listing_sig; 319 unsigned int allowance; 320 } 322 struct rootlisting { 323 rootentry roots<>; 324 } 326 A significant question is how to properly administer entries in this 327 listing, since a strong authority, such as a single root key, can 328 easily protect the listing from spam and malicious changes, but 329 raises important concerns about misuse. Concurrent work on IP 330 address allocation [IP-blockchain] explores using a Decentralized 331 Autonomous Organization built on the Ethereum blockchain to manage 332 all delegations where proper behavior is economically motivated. We 333 identify similar challenges: controlling spam and misuse, while 334 operating in a decentralized manner. 336 In this draft, however, we focus on enabling governance through 337 consensus operations. For that reason, potential root entries are 338 nominated with a proposed allowance, which will restrict the total 339 number of cells currently supported by an application. For large 340 systems such as IP delegation or well-known entities like the IETF, 341 the limit can be disabled as discussed earlier in this draft. It is 342 important that decisions regarding root listing membership be made by 343 the consensus nodes themselves, since they bear the largest burden to 344 store tables, communicate with other nodes, and service client 345 queries. This structure further allows table authorities to focus on 346 content-specific administration of their own namespaces, which is not 347 provided for in the generic delmap semantics. If an application 348 begins to run out of allowance (too many cells or large delegations), 349 it can sign and nominate a new "rootentry" for the same application 350 identifier with a larger value, at which point the other nodes can 351 (given global knowledge of table sizes and growth rates, along with 352 additional real-world information, if applicable) determine whether 353 or not to accept the change. 355 Thus, this draft explicitly requires prospective consensus algorithms 356 to provide a mechanism for inter-node voting on governance issues. 357 This is already common in protocols that provide for periodic 358 updates: quorums in slice infrastructures like Stellar, Bitcoin-style 359 percentage- and time-based agreement windows, or hard forks. 360 Finally, although the possibility of fundemental disagreement in 361 governance between different sets of consensus nodes is real, in 362 realistic settings, in the worst case such groups should not 363 necessarily continue to trust each other in consensus relationships 364 and may indicate a (valid) need to split. 366 3. Interacting with a Consensus Node 368 3.1. Storage Format 370 Delegation tables are stored in a Merkle hash tree, described in 371 detail in [RFC6962]. In particular, it enables efficient lookups and 372 logarithmic proofs of existence in the tree, and prevents 373 equivocation between different participants. Among others, we can 374 leverage Google's [Trillian] Merkle tree implementation which 375 generalizes the datastructures used in Certificate Transparency. In 376 map mode, the tree can manage arbitrary key-value pairs at scale, but 377 critically, this requires flattening the delegation links such that 378 each table may be queried, while ensuring that a full lookup from the 379 application root is made for each mapping. 381 Given a "rootentry", the corresponding table in the Merkle tree can 382 be queried at the following key (where || indicates concatenation): 384 root_table_name = app_id || namespace_root_key 386 It follows that tables for delegated namespaces are found at: 388 table = root_table_name || delegee_key_1 || ... || delegee_key_n 390 And finally, individual entries are identified by the namespace 391 lookup key: 393 cell = table || desired_lookup_key 395 Once an entry is found in the tree, a logarithmic proof can be 396 constructed with the hashes of the siblings of each node in the 397 tree's path to the entry. 399 struct merkleproof { 400 opaque sibling_hashes[32]<>; 401 cell entry_cell; 402 signature tree_sig; 403 } 405 The entry is hashed together with each "sibling_hash" - if the total 406 matches the known tree root hash, then the entry must have been in 407 the tree. 409 3.2. Client Interface 411 The presence of a natural mapping structure motivates an external 412 client interface similar to a key-value store. 414 struct MerkleRootOperation { } 416 struct MerkleRootReturn { 417 opaque root_hash[32]; 418 signature tree_sig; 419 } 421 It is important to note that the client should not rely on a root 422 hash that has been provided by a single server to verify a 423 "merkleproof", instead querying multiple consensus nodes using this 424 interface. Upon discovering that different servers are advertising 425 non-matching hashes, the signed proof should be used to prove to 426 other clients/nodes that one or more malicious trees are 427 equivocating. 429 enum ReturnCode { 430 CELL = 0, 431 TABLE = 1, 432 ERROR = 2 433 } 435 struct GetOperation { 436 string application_identifier; 437 opaque full_lookup_key<>; 438 } 440 union GetReturn switch (ReturnCode ret) { 441 case CELL: 442 cell value; 443 merkleproof p; 444 case TABLE: 445 table t; 446 merkleproof p; 447 case ERROR: 448 string reason; 449 } 451 Given an application identifier and the fully-qualified lookup key, 452 the map described in the previous section can be searched 453 recursively. At each table, we find the cell whose name matches a 454 prefix of the desired lookup key. If the cell contains a 455 "valuecell", it is returned if the cell's key matches the lookup key 456 exactly, else an "ERROR" is returned. If the cell contains a 457 "delegatecell", it must contain the key for the next table, on which 458 the process is repeated. If no cell is found by prefix-matching, the 459 node should return "ERROR" if the key has not been fully found, else 460 the table itself (containing all of the current cells) is provided to 461 the client. As in every interaction with the delegated mapping 462 structure, users should verify the attached proof. Verifying 463 existence of an entry follows from the same method. 465 struct SetOperation { 466 string application_identifier; 467 opaque full_lookup_key<>; 468 cell c; 469 } 471 struct SetRootOperation { 472 rootentry e; 473 bool remove; 474 } 476 union SetReturn switch (ReturnCode ret) { 477 case SUCCESS: 478 opaque empty; 479 case ERROR: 480 string reason; 481 } 483 Creating or updating a cell at a specified path requires once again 484 the full lookup key, as well as the new version of the cell to place. 485 The new cell must be well-formed under the validation checks 486 described in the previous section, else an "ERROR" is returned. For 487 example, updating a cell's owner without a signature by the previous 488 owning key should not succeed. Both value cells and new/updated 489 delegations may be created through this method. Removing cells from 490 tables (after their commitment timestamps have expired) can be 491 accomplished by replacing the value or delegated namespace with an 492 empty value and setting the owner's key to that of the table 493 authority. Asking the consensus layer to approve a new root entry 494 follows a similar process, although the application identifier and 495 lookup key is unnecessary (see "SetRootOperation"). Nodes can also 496 trigger votes to remove entries from the root key listing to redress 497 misbehaving applications. 499 4. Consensus 501 Safety is ensured by reaching distributed consensus on the state of 502 the tree. The general nature of a Merkle tree as discussed in the 503 previous section enables almost any consensus protocol to support 504 delegated mappings, with varying guarantees on the conditions under 505 which safety is maintained and different trust implications. For 506 example, a deployment on a cluster of nodes running a classic 507 Byzantine Fault Tolerant consensus protocol such as [PBFT] requires a 508 limited, static membership and can tolerate compromises in up to a 509 third of its nodes. In comparison, proof-of-work schemes including 510 many cryptocurrencies have open membership but rely on economic 511 incentives and distributed control of hashing power to provide 512 safety, and federated consensus algorithms like the Stellar Consensus 513 Protocol (SCP) [I-D.mazieres-dinrg-scp] combine dynamic members with 514 real-world trust relationships but require careful configuration. 515 Determining which scheme, if any, is the "correct" protocol to 516 support authenticated delegation is an open question. 518 4.1. Interface 520 Explicit requirement for voting HERE 522 At a minimum, the consensus layer is expected to provide mechanisms 523 for nodes to 525 1. Submit new values (commonly cell, but also root listing, updates) 526 for consensus 528 2. Receive externalized values to which the protocol has committed 530 3. Validate values received from other nodes for each iteration of 531 the protocol, as specified below 533 4. Voting mechanism for making root listing governance decisions 535 Specific protocols may require additional functionality from the 536 delegated mapping layer, which should be implemented to ensure that 537 valid updates are eventually applied (assuming a working consensus 538 layer). 540 4.2. Validation 542 Incorrect (potentially malicious) updates to the Merkle tree should 543 be rejected by nodes participating in consensus. Given the known 544 prefix-delegation scheme, each node can apply the same validation 545 procedure without requiring table-specific or application-specific 546 knowledge. Validation also provides a simple mechanism for rate- 547 limiting actors attempting to perform DoS attacks, as only the most 548 recent change to a particular cell need be retained, and the total 549 number of updates to any particular table or overall can be capped. 550 Upon any modification to the delegation tables, a "SetOperation" or 551 "SetRootOperation" as defined in the previous section, the submitted 552 change to the consensus layer should: 554 1. Reference an existing application identifier in the root key 555 listing and a valid table if applicable. 557 2. For updates to all cells: 559 * contain an unmodified "create_time" or a current timestamp if 560 a new cell 562 * contain a current "revision_time" in the case of an update 564 * set a "commitment_time" greater than or equal to the previous 565 commitment 567 * not grant unlimited allowance (value 0) to delegate cells 568 unless the delegating table also has an unlimited allowance 570 * result in a total table size ("valuecell" count + 571 "delegatecell" allowances) less than or equal to the table 572 allowance, if not unlimited 574 * contain a valid signature of the overall cell data by the 575 table authority 577 3. For updates to value cells: 579 * be signed only by the current "owner_key" if the cell 580 commitment has not yet expired, or by a new owner upon 581 expiration 583 * have a lookup key in the table that belongs to the authority's 584 namespace 586 * not conflict with other cells in its table, breaking the 587 prefix-delegation property 589 4. For updates to delegate cells: 591 * be signed by the table authority's public key for new 592 delegations or updates 594 * retain the same "namespace" and "delegee" value unless the 595 "commitment_time" is expired 597 * contain a valid namespace owned by the authority delegating 598 the cell 600 * not conflict with other values or delegations in the same 601 table, breaking the prefix-delegation property 603 Only after a round of the consensus protocol is successful are the 604 changes exposed to client lookups. 606 4.3. SCP 608 While consensus can be reached with many protocols, this section 609 describes how the interface described above can be satisfied by SCP. 611 Updates to the delegation tables consist of the table change itself 612 (the new version of the cell). Since SCP does not need specific 613 knowledge of the format of these proofs, they directly form consensus 614 on the opaque values submitted to the consensus layer. Once a 615 combination of proofs are agreed to as outputs for a given slot, they 616 are externalized to the mapping layer and applied to the local node's 617 table states. [I-D.mazieres-dinrg-scp] requires this layer to 618 provide a _validity_ function that is applied to each input value, 619 allowing nodes to detect misformed cells that violate the delgation 620 semantics as defined by the previous subsection. 622 SCP asks the higher-level protocol to define a _combining_ function 623 to compose multiple candidate values. In this application, we can 624 take the union of valid updates proposed by the consensus nodes, 625 rejecting duplicate updates to the same cell in favor of the most up- 626 to-date timestamp. 628 Finally, SCP by specification uses federated voting to confirm 629 values, which can be used directly to propose and validate 630 modifications to the root key listing. 632 5. Security Considerations 634 The security of the delegation tables is primarily tied to the safety 635 properties of the underlying consensus layer. Further, incorrect use 636 of the public key infrastructure authenticating each mapping or 637 compromise of a namespace root key can endanger mappings delegated by 638 the key after their commitments expire. 640 6. References 642 6.1. Normative References 644 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 645 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 646 2006, . 648 [Trillian] 649 Google, "Trillian: General Transparency", n.d., 650 . 652 6.2. Informative References 654 [I-D.mazieres-dinrg-scp] 655 Barry, N., Losa, G., Mazieres, D., McCaleb, J., and S. 656 Polu, "The Stellar Consensus Protocol (SCP)", draft- 657 mazieres-dinrg-scp-05 (work in progress), November 2018. 659 [IP-blockchain] 660 Angieri, S., Garcia-Martinez, A., Liu, B., Yan, Z., Wang, 661 C., and M. Bagnulo, "An experiment in distributed Internet 662 address management using blockchains", 2018, 663 . 665 [PBFT] Castro, M. and B. Liskov, "Practical Byzantine Fault 666 Tolerance", 1999, 667 . 669 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 670 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 671 . 673 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, 674 DOI 10.17487/RFC7249, May 2014, 675 . 677 Acknowledgments 679 We are grateful for the contributions and feedback on design and 680 applicability by David Mazieres, as well as help and feedback from 681 many members of the IRTF DIN research group, including Dirk Kutscher 682 and Melinda Shore. 684 This work was supported by The Stanford Center For Blockchain 685 Research. 687 Authors' Addresses 689 Sydney Li 690 Electronic Frontier Foundation 691 815 Eddy Street 692 San Francisco, CA 94109 693 US 695 Email: sydney@eff.org 696 Colin Man 697 Stanford University 698 353 Serra Mall 699 Stanford, CA 94305 700 US 702 Email: colinman@cs.stanford.edu 704 Jean-Luc Watson 705 UC Berkeley 706 Cory Hall, 545W 707 Berkeley, CA 94720 708 US 710 Email: jlwatson@eecs.berkeley.edu