[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                          J. Watson
Internet-Draft                                               UC Berkeley
Intended status: Experimental                                      S. Li
Expires: April 26, 2019                                              EFF
                                                                  C. Man
                                                     Stanford University
                                                        October 23, 2018


                     Delegated Distributed Mappings
                      draft-watson-dinrg-delmap-01

Abstract

   Delegated namespaces underpin almost every Internet-scale system -
   domain name management, IP address allocation, Public Key
   Infrastructure, etc. - but are centrally managed by entities with
   unilateral revocation abilities and no common interface.  This draft
   specifies a generalized scheme for delegation that supports explicit
   time-bound guarantees and limits misuse.  Mappings may be secured by
   any general purpose distributed consensus protocol; clients can query
   the local state of any number of participants and receive the correct
   result barring a compromise at the consensus layer.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 26, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Watson, et al.           Expires April 26, 2019                 [Page 1]


Internet-Draft             Delegated Mappings               October 2018


   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Structure . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Cells . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Tables  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Root Key Listing  . . . . . . . . . . . . . . . . . . . .   7
   3.  Interacting with a Consensus Node . . . . . . . . . . . . . .   7
     3.1.  Storage Format  . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Client Interface  . . . . . . . . . . . . . . . . . . . .   8
   4.  Consensus-layer requirements  . . . . . . . . . . . . . . . .  10
     4.1.  Interface . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.2.  Validation  . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     5.1.  DoS mitigation  . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  Consensus node compromise . . . . . . . . . . . . . . . .  13
     5.3.  Upstream compromise . . . . . . . . . . . . . . . . . . .  14
     5.4.  Root listing governance . . . . . . . . . . . . . . . . .  14
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Internet entities rely heavily on delegated namespaces to function
   properly.  Typical web services have been delegated a domain name
   (after negotitation with an appropriate registrar) under which they
   host the entirety of their public-facing content, or obtain a public
   IP range from their ISP, which itself has been delegated through
   intermediary registries by the Internet Numbers Registry [RFC7249].
   An enormous amount of value and trust is therefore placed in these
   assignments (in this draft, _mappings_) yet they are dangerously
   ephemeral.  Delegating authorities, either maliciously or
   accidentally, can unilaterally revoke or replace mappings they've
   made, compromising infrastructure security.  Presented in this draft
   is a generalized mechanism for securely managing such mappings and
   their delegations by publishing authenticated time-locked commitments
   to namespace ownership entries.  Known entities identified by public



Watson, et al.           Expires April 26, 2019                 [Page 2]


Internet-Draft             Delegated Mappings               October 2018


   key are assigned namespaces (e.g. domain prefixes) under which they
   are authorized to create mapping records, or _cells_. A namespace's
   cells are grouped into logical units we term _tables_.

   Alone, this structure does not ensure security, given that any
   hosting server could arbitrarily modify cells or service clients with
   bogus entries.  We maintain security and consistency through a
   distributed consensus algorithm.  While detailed descriptions of
   varying consensus protocols are out of scope for this draft, we
   provide for a general-purpose interface between the delegation
   structure and a consensus layer.  At a minimum, the consensus layer
   must apply mapping updates in a consistent order, prevent
   equivocation, disallow unauthorized modification, and grant consensus
   nodes the ability to enforce high-level rules associated with the
   tables.  We find that federated protocols such as the Stellar
   Consensus Protocol [I-D.mazieres-dinrg-scp] are promising given their
   capability for open participation, broad diversity of interests among
   consensus participants, and providing accountability for malicious
   behavior.  Clients may query any number of trusted servers to
   retrieve a correct result barring widespread collusion.

   The ability to impose consistency yields several useful properties.
   The foremost is enforcing delegation semantics: a table's authority
   may choose to delegate a portion of its own namespace recursively,
   but must document the specific range and delegee in on of the table's
   cells.  Since each delegation forms a new table, for which a delegee
   is the sole authority, assigned namespace ranges must be unique.
   Consensus can also enforce that the delegating authority not make
   modifications to any delegated table and thus need not be trusted by
   the delegee.

   In addition, we provide explicit support for "commitments" that
   enforce an explicit lower-bound on the duration of delegations.
   Otherwise valid changes to cells that have a valid commitment are
   disallowed, including revoking delegations.  Upon expiration,
   however, the same namespace may be delegated to another party.

   Finally, decentralized infrastructure is highly visible and commonly
   misused.  As mappings are replicated among consensus nodes, of
   primary concern is resource exhaustion.  We limit undesired abuse of
   the structure by embedding recursive scale restrictions inside
   mappings, verified and ratified at consensus.  Combined with time-
   bounded delegations, this ensures that the system is resistant to
   spam in the short-term and can remove misbehaving hierarchies in the
   long-term.






Watson, et al.           Expires April 26, 2019                 [Page 3]


Internet-Draft             Delegated Mappings               October 2018


   The remainder of this draft specifies the structure for authenticated
   mapping management as well as its interfaces to consensus protocol
   implementations and users.

2.  Structure

   Trust within the delegation structure is based on public key
   signatures.  Namespace authorities must sign mapping additions,
   modifications, delegations, and revocations to their table as proof
   to the consensus participants that such changes are legitimate.  For
   the sake of completeness, the public key and signature types are
   detailed below.  All types in this draft are described in XDR
   [RFC4506].

    typedef publickey opaque<>; /* Typically a 256 byte RSA signature */

    struct signature {
        publickey pk;
        opaque data<>;
    };

2.1.  Cells

   Cells are the basic unit of the delegation structure.  In general,
   they compose an authenticated record of a mapping that may be queried
   by clients.  We describe two types of cells:

       enum celltype {
           VALUE = 0,
           DELEGATE = 1
       };

   Value cells store individual mapping entries.  They resolve a lookup
   key to an arbitrary value, for example, an encryption key associated
   with an email address or the zone files associated with a particular
   domain.  The public key of the cell's owner (e.g. the email account
   holder, the domain owner) is also included, as well as a signature
   authenticating the current version of the cell.  The cell's
   "update_sig" must be made by either the "owner_key", or when created,
   the authority of the table containing the cell, as is described
   below.  The cell owner may rotate their public key at any time by
   signing the update with the old key.









Watson, et al.           Expires April 26, 2019                 [Page 4]


Internet-Draft             Delegated Mappings               October 2018


    struct valuecell {
        opaque value<>;
        publickey owner_key;

        signature update_sig; /* Table signs cell creation, owner signs updates */
    };

   Delegate cells have a similar structure but different semantics.
   Rather than resolving to an individual mapping, they authorize the
   _delegee_ to create arbitrary value cells within an assigned
   namespace.  This namespace must be a subset of the _delegator_'s own
   namespace range.  Like the table authority, the delegee is uniquely
   identified by their public key.  Each delegate cell and subsequent
   updates to the cell are signed by the delegator - this ensures that
   the delegee cannot unilaterally modify its namespace, which limits
   the range of legitimate mappings they can create.  Finally, an
   _allowance_ must be provided to limit the upper-bound size of a
   delegated table.  Negative allowance values indicates no limit is
   placed on the table.  Given that the delegee has complete control
   over the contents of their table, it is emphatically not recommended
   to grant a "delegatecell" an unlimited allowance to limit the storage
   burden on consensus nodes.  A table with a non-negative allowance may
   not grant a delegee a negative one.  This limit is recursive along
   delegations - the total number of cells in a table plus the sum of
   allowances among its "delegatecells" must be less than or equal to
   the table's allowance, if non-negative.  This must be validated
   during consensus before adding new cells to a table, which can be
   done at every consensus node because table entry counts are visible
   publicly.

    struct delegatecell {
        opaque namespace<>;
        publickey delegee;
        signature authority_sig;  /* Delegator solely controls inclusion in table  */
        int allowance;
    };

   Both cell types share a set of common data members, namely a set of
   UNIX timestamps recording the creation time and, if applicable, the
   time of last modification.  An additional "commitment" timestamp must
   be present in every mapping.  It is an explicit guarantee on behalf
   of the table's authority that the mapping will remain valid until at
   least the specified time.  Therefore, while value cell owners may
   modify their cell at any time (e.g. key rotation), the authority
   cannot change (or remove) the cell until its commitment expires, as
   enforced by the consensus nodes.  Similarly, delegated namespaces are
   guaranteed to be valid until the commitment timestamp expiration,
   although after expiration, they can be reassigned to other parties.



Watson, et al.           Expires April 26, 2019                 [Page 5]


Internet-Draft             Delegated Mappings               October 2018


   Likely, most long-term delegations will be renewed (with a new
   commitment timestamp) before the expiration of the current period.
   The tradeoff between protecting delegees from arbitrary authority
   action and allowing quick reconfiguration is customizable to the use
   case.  Larger services should use longer delegation periods for
   stability whereas small namespaces with a smaller number of users
   should use shorter delegations.

       union innercell switch (celltype type) {
       case VALUE:
           valuecell vcell;
       case DELEGATE:
           delegatecell dcell;
       };

       struct cell {
           unsigned hyper create_time;     /* 64-bit UNIX timestamps */
           unsigned hyper *revision_time;
           unsigned hyper commitment_time;
           innercell c;
       }

2.2.  Tables

   Every cell is stored in a table, which groups all the mappings
   created by a single authority public key for a specific namespace.
   Individual cells are referenced by an application-specific label in a
   lookup table. _The combination of a lookup key and a referenced cell
   value forms a mapping_.

       struct tableentry {
           opaque lookup_key<>;
           cell c;
       }

   Delegating the whole or part of a namespace requires adding a new
   lookup key for the namespace and a matching delegate cell.  Each
   delegation must be validated in the context of the other table
   entries and the table itself.  For example, the owner of a table
   delegated an /8 IPv4 block must not to delegate the same /16 block to
   two different tables.

       struct table {
           tableentry entries<>;
       };

   To generalize correctness, each table must conform with a prefix-
   based rule: for every cell "c" in a table controlling namespace "x",



Watson, et al.           Expires April 26, 2019                 [Page 6]


Internet-Draft             Delegated Mappings               October 2018


   "x" must be a prefix of "c" and there cannot exist another cell "c'"
   such that "c" is a prefix of "c'".  While there exist many more
   hierarchical delegation mechanisms, many can be simply represented in
   a prefix scheme.  For example, suffix-based delegations including
   domain name hierarchies can use reversed keys internally and perform
   a swap in the application layer before displaying any results to
   clients.  Likewise, 'flat' delegation schemes where there is no
   explicit restriction can use an empty prefix.

2.3.  Root Key Listing

   Each linked group of delegation tables for a particular namespace is
   rooted by a public key stored in a flat root key listing, which is
   the entry point for lookup operations.  Well-known application
   identifier strings denote the namespace they control.  We describe
   below how lookups can be accomplished on the mappings.

       struct rootentry {
           publickey namespace_root_key;
           string application_identifier<>;
           signature listing_sig;
           int allowance;
       }

       struct rootlisting {
           rootentry roots<>;
       }

   A significant question is how to properly administer entries in this
   listing, which we address in Security Considerations.

3.  Interacting with a Consensus Node

3.1.  Storage Format

   Delegation tables are stored in a Merkle hash tree, described in
   detail in [RFC6962].  In particular, it enables efficient lookups and
   logarithmic proofs of existence in the tree, and prevents
   equivocation between different participants.  Among others, we can
   leverage Google's [Trillian] Merkle tree implementation which
   generalizes the datastructures used in Certificate Transparency.  In
   map mode, the tree can manage arbitrary key-value pairs at scale, but
   critically, this requires flattening the delegation links such that
   each table may be queried, while ensuring that a full lookup from the
   application root is made for each mapping.

   Given a "rootentry", the corresponding table in the Merkle tree can
   be queried at the following key (where || refers to concatenation):



Watson, et al.           Expires April 26, 2019                 [Page 7]


Internet-Draft             Delegated Mappings               October 2018


       root_table_name = app_id || namespace_root_key

   It follows that tables for delegated namespaces are found at:

       table = root_table_name || delegee_key_1 || ... || delegee_key_n

   And finally, individual entries are identified by the namespace
   lookup key:

       cell = table || desired_lookup_key

   Once an entry is found in the tree, a logarithmic proof can be
   constructed with the hashes of the siblings of each node in the
   tree's path to the entry.

       struct merkleproof {
           opaque sibling_hashes[32]<>;
           cell entry_cell;
           signature tree_sig;
       }

   The entry is hashed together with each "sibling_hash" - if the total
   matches the known tree root hash, then the entry must have been in
   the tree.

3.2.  Client Interface

   The presence of a natural mapping structure motivates an external
   client interface similar to a key-value store.

       struct MerkleRootOperation { }

       struct MerkleRootReturn {
           opaque root_hash[32];
           signature tree_sig;
       }

   It is important to note that the client should not rely on a root
   hash that has been provided by a single server to verify a
   "merkleproof", instead querying multiple consensus nodes using this
   interface.  Upon discovering that different servers are advertising
   non-matching hashes, the signed proof should be used to prove to
   other clients/nodes that one or more malicious trees are
   equivocating.







Watson, et al.           Expires April 26, 2019                 [Page 8]


Internet-Draft             Delegated Mappings               October 2018


       enum ReturnCode {
           CELL = 0,
           TABLE = 1,
           ERROR = 2
       }

       struct GetOperation {
           string application_identifier;
           opaque full_lookup_key<>;
       }

       union GetReturn switch (ReturnCode ret) {
       case CELL:
           cell value;
           merkleproof p;
       case TABLE:
           table t;
           merkleproof p;
       case ERROR:
           string reason;
       }

   Given an application identifier and the fully-qualified lookup key,
   the map described in the previous section can be searched
   recursively.  At each table, we find the cell whose name matches a
   prefix of the desired lookup key.  If the cell contains a
   "valuecell", it is returned if the cell's key matches the lookup key
   exactly, else an "ERROR" is returned.  If the cell contains a
   "delegatecell", it must contain the key for the next table, on which
   the process is repeated.  If no cell is found by prefix-matching, the
   node should return "ERROR" if the key has not been fully found, else
   the table itself (containing all of the current cells) is provided to
   the client.  As in every interaction with the delegated mapping
   structure, users should verify the attached proof.  Verifying
   existence of an entry follows from the same method.
















Watson, et al.           Expires April 26, 2019                 [Page 9]


Internet-Draft             Delegated Mappings               October 2018


       struct SetOperation {
           string application_identifier;
           opaque full_lookup_key<>;
           cell c;
       }

       struct SetRootOperation {
           rootentry e;
           bool remove;
       }

       union SetReturn switch (ReturnCode ret) {
       case SUCCESS:
           opaque empty;
       case ERROR:
           string reason;
       }

   Creating or updating a cell at a specified path requires once again
   the full lookup key, as well as the new version of the cell to place.
   The new cell must be well-formed under the validation checks
   described in the previous section, else an "ERROR" is returned.  For
   example, updating a cell's owner without a signature by the previous
   owning key should not succeed.  Both value cells and new/updated
   delegations may be created through this method.  Removing cells from
   tables (after their commitment timestamps have expired) can be
   accomplished by replacing the value or delegated namespace with an
   empty value and setting the owner's key to that of the table
   authority.  Asking the consensus layer to approve a new root entry
   follows a similar process, although the application identifier and
   lookup key is unnecessary (see "SetRootOperation").  Nodes can also
   trigger votes to remove entries from the root key listing to redress
   misbehaving applications.

4.  Consensus-layer requirements

   Safety is ensured by reaching distributed consensus on the state of
   the tree.  The general nature of a Merkle tree as discussed in the
   previous section enables almost any consensus protocol to support
   delegated mappings, with varying guarantees on the conditions under
   which safety is maintained and different trust implications.  For
   example, a deployment on a cluster of nodes running a classic
   Byzantine Fault Tolerant consensus protocol such as [PBFT] requires a
   limited, static membership and can tolerate compromises in up to a
   third of its nodes.  In comparison, proof-of-work schemes including
   many cryptocurrencies have open membership but rely on economic
   incentives and distributed control of hashing power to provide
   safety, and federated consensus algorithms like the Stellar Consensus



Watson, et al.           Expires April 26, 2019                [Page 10]


Internet-Draft             Delegated Mappings               October 2018


   Protocol (SCP) [I-D.mazieres-dinrg-scp] combine dynamic members with
   real-world trust relationships but require careful configuration.
   Determining which scheme, if any, is the best protocol to support
   authenticated delegation is an open question.

4.1.  Interface

   At a minimum, the consensus layer is expected to provide mechanisms
   for nodes to

   1.  Submit new values (commonly cell, but also root listing, updates)
       for consensus

   2.  Receive externalized values to which the protocol has committed

   3.  Validate values received from other nodes for each iteration of
       the protocol, as specified below

   Most input values to the consensus layer will consist of cell
   updates, but the same mechanism is ideally suited for updates to the
   root key listing, as previously discussed.  Specific protocols may
   require additional functionality from the delegated mapping layer,
   which should be implemented to ensure that valid updates are
   eventually applied (assuming a working consensus layer).

4.2.  Validation

   Incorrect (potentially malicious) updates to the Merkle tree should
   be rejected by nodes participating in consensus.  Given the known
   prefix-delegation scheme, each node can apply the same validation
   procedure without requiring table-specific knowledge.  Validation
   also provides a simple mechanism for rate-limiting actors attempting
   to perform DoS attacks, as only the most recent change to a
   particular cell need be retained, and the total number of updates to
   any particular table or overall can be capped.  Upon any modification
   to the delegation tables, a "SetOperation" or "SetRootOperation" as
   defined in the previous section, the submitted change to the
   consensus layer should:

   1.  Reference an existing application identifier in the root key
       listing and a valid table if applicable.

   2.  For updates to all cells:

       *  contain an unmodified "create_time" or a current timestamp if
          a new cell

       *  contain a current "revision_time" in the case of an update



Watson, et al.           Expires April 26, 2019                [Page 11]


Internet-Draft             Delegated Mappings               October 2018


       *  set a "commitment_time" greater than or equal to the previous
          commitment

       *  result in a total table size ("valuecell" count +
          "delegatecell" allowances) less than or equal to the table
          allowance, if not unlimited

   3.  For updates to value cells:

       *  be signed with the table authority's public key for new
          mappings

       *  be signed only by the current "owner_key" if the cell
          commitment has not yet expired, or by either the owner or
          table authority upon expiration for updates to the value or
          owner keys

       *  have a lookup key in the table that belongs to the authority's
          namespace

       *  not conflict with other cells in its table, breaking the
          prefix-delegation property

   4.  For updates to delegate cells:

       *  be signed by the table authority's public key for new
          delegations or updates

       *  retain the same "namespace" and "delegee" value unless the
          "commitment_time" is expired

       *  contain a valid namespace owned by the authority delegating
          the cell

       *  not conflict with other values or delegations in the same
          table, breaking the prefix-delegation property

       *  not grant unlimited (negative) allowance unless the delegating
          table also has an unlimited allowance

   Only after a round of the consensus protocol is successful are the
   changes exposed to client lookups.

5.  Security Considerations







Watson, et al.           Expires April 26, 2019                [Page 12]


Internet-Draft             Delegated Mappings               October 2018


5.1.  DoS mitigation

   Full consensus nodes must maintain complete, up-to-date table state
   in order to correctly validate and apply updates.  A significant
   concern is limiting computation and storage resources expended as the
   result of malicious entities operating in the delegation structure.
   This is doubly important because of the explicit lack of trust from a
   delegee to its delegating namespace.  While this prevents higher-
   level organizations from making arbitrary changes to delegated
   namespaces (as is currently possible in the CA hierarchy), a delegee
   may choose to incur unreasonable storage costs by filling their table
   with millions of garbage cells.  Of course, since the delegee has a
   commitment to controlling the specific namespace for a certain time
   period, these cells cannot be removed.  We recognize that this
   requires the provider to place some amount of trust in their users to
   consume resources responsibly, and attempt to limit misuse.

   The allowances included in each delegation work to address this,
   since it explicitly defines an agreement between the delegator and
   delegee as to the expected size required for correct operation.
   Since allowances are provided at the root level as well (ignoring
   unlimited allowances) there exists an upper bound on the total number
   of cells that consensus nodes should expect to be required to
   maintain.  Importantly, the ability to unlimit the table size (as
   well as further delegations) increases the risk of misuse but
   provides significant flexibility for well-known systems like DNS and
   IP allocation.  This can be mitigated by assigning unlimited
   allowances only to well-known entities where real-world
   accountability limits the urge to misbehave.  Consensus nodes are
   also encouraged to rate-limit excessive "SetOperation"s from clients
   to further limit this issue.

5.2.  Consensus node compromise

   We rely on the safety properties of the underlying consensus layer to
   provide a consistent view of the delegated mapping tables.  This
   ensures that no honest node will serve mappings to clients that have
   not succeeded at reaching consensus.  There is nothing directly
   preventing compromised consensus nodes from maliciously serving
   entries (e.g. incorrect DNS zone records) to clients as they see fit,
   _however_, they must also provide an inclusion proof and expose their
   Merkle root hash.  As noted previously, clients and other auditing
   parties may compare roots and discover misbehavior.  The proof
   associated with a query is unequivocal proof that is sufficient to
   ignore the compromised node in further consensus rounds.  Past
   individual compromise, the exact point at which a network of
   consensus nodes can completely violate safety varies from protocol to
   protocol (majority hashing power attack in Bitcoin, no quorum



Watson, et al.           Expires April 26, 2019                [Page 13]


Internet-Draft             Delegated Mappings               October 2018


   intersection of well-behaved nodess in SCP, etc.).  Thus, it is not
   secure to rely only on a small group of nodes hosted by one or two
   distinct entities for consensus, as they are easily targeted.  The
   generalized delegated mappings mechanism described in this draft
   allows parties from radically different sectors to collectively
   provide security, limiting the impact of a small number of malicious
   nodes.  Finally, in the case of an extremely large-scale compromise,
   mappings stored in prior trees with known root hashes are still valid
   - they cannot be modified without forging the inclusion proof whose
   root hash the client will verify.

5.3.  Upstream compromise

   As in any hierarchical delegation system, some amount of trust must
   be placed in the upstream provider.  With this work, we strive to
   minimize the amount and nature of trust that any entity has to place
   in their upstream dependencies.

   In a regular authenticated delegation system, the network must
   unilaterally trust a particular namespace operator to not equivocate
   (i.e. not present different states of the database to different
   entities) and to not hijack control of a particular delegated entry.
   Under consensus, nodes can trust that a single entity cannot force
   the network to equivocate, and entities can audit the database for
   any misbehavior.  The time-bound commitments to namespace delegations
   limit misuse to the brief renewal window, during which end-entities
   can monitor the network for misbehavior.

   Although an upstream entity can still unilaterally censor and deny
   service to a particular entity for the namespace that they control,
   their ability to hijack an existing delegee's entries is both limited
   and auditable.

5.4.  Root listing governance

   Relying on a centralized party in the long term to reliably and
   consistently manage the root key listing would create a centralized
   point of failure, so we consider alternative mechanisms of governing
   the root of the structure presented in this draft.  Concurrent work
   on IP address allocation [IP-blockchain] explores using a
   Decentralized Autonomous Organization built on the Ethereum
   blockchain to manage all delegations where proper behavior is
   economically motivated.  We identify similar challenges: controlling
   spam and misuse, while operating in a decentralized manner.

   In this draft, we focus on enabling governance through consensus
   operations.  For that reason, potential root entries are nominated
   with a proposed allowance, which will restrict the total number of



Watson, et al.           Expires April 26, 2019                [Page 14]


Internet-Draft             Delegated Mappings               October 2018


   cells currently supported by an application.  For large systems such
   as IP delegation or well-known entities like the IETF, the limit can
   be disabled as discussed earlier.  It is important that decisions
   regarding root listing membership be made by the consensus nodes
   themselves, since they bear the largest burden to store tables,
   communicate with other nodes, and service client queries.  If an
   application begins to run out of allowance (too many cells or large
   delegations), it can sign and nominate a new "rootentry" for the same
   application identifier with a larger value, at which point the other
   nodes can (given global knowledge of table sizes and growth rates,
   along with potential real-world information) determine whether or not
   to accept the change.  Note that if the consensus layer is
   compromised as discussed above, the governance of the root listing
   also becomes insecure.

6.  References

6.1.  Normative References

   [RFC4506]  Eisler, M., Ed., "XDR: External Data Representation
              Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
              2006, <https://www.rfc-editor.org/info/rfc4506>.

   [Trillian]
              Google, "Trillian: General Transparency", n.d.,
              <https://github.com/google/trillian>.

6.2.  Informative References

   [I-D.mazieres-dinrg-scp]
              Barry, N., Losa, G., Mazieres, D., McCaleb, J., and S.
              Polu, "The Stellar Consensus Protocol (SCP)", draft-
              mazieres-dinrg-scp-04 (work in progress), June 2018.

   [IP-blockchain]
              Angieri, S., Garcia-Martinez, A., Liu, B., Yan, Z., Wang,
              C., and M. Bagnulo, "An experiment in distributed Internet
              address management using blockchains", 2018,
              <https://arxiv.org/pdf/1807.10528.pdf>.

   [PBFT]     Castro, M. and B. Liskov, "Practical Byzantine Fault
              Tolerance", 1999,
              <http://pmg.csail.mit.edu/papers/osdi99.pdf>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.




Watson, et al.           Expires April 26, 2019                [Page 15]


Internet-Draft             Delegated Mappings               October 2018


   [RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249,
              DOI 10.17487/RFC7249, May 2014,
              <https://www.rfc-editor.org/info/rfc7249>.

Acknowledgments

   We are grateful for the contributions and feedback on design and
   applicability by David Mazieres, as well as help and feedback from
   many members of the IRTF DIN research group, including Dirk Kutscher
   and Melinda Shore.

   This work was supported by The Stanford Center For Blockchain
   Research.

Authors' Addresses

   Jean-Luc Watson
   UC Berkeley
   Cory Hall, 545W
   Berkeley, CA 94720
   US

   Email: jlwatson@eecs.berkeley.edu


   Sydney Li
   Electronic Frontier Foundation
   815 Eddy Street
   San Francisco, CA 94109
   US

   Email: sydney@eff.org


   Colin Man
   Stanford University
   353 Serra Mall
   Stanford, CA 94305
   US

   Email: colinman@cs.stanford.edu










Watson, et al.           Expires April 26, 2019                [Page 16]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/