RAINS (Another Internet Naming Service) Protocol Specification
draft-trammell-rains-protocol-03

Versions: 00 01 02 03                                                   
Network Working Group                                        B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: Experimental                         September 20, 2017
Expires: March 24, 2018


     RAINS (Another Internet Naming Service) Protocol Specification
                    draft-trammell-rains-protocol-03

Abstract

   This document defines an alternate protocol for Internet name
   resolution, designed as a prototype to facilitate conversation about
   the evolution or replacement of the Domain Name System protocol.  It
   attempts to answer the question: "how would we design DNS knowing
   what we do now," on the background of the properties of an ideal
   naming service described in [I-D.trammell-inip-pins].

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 March 24, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (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




Trammell                 Expires March 24, 2018                 [Page 1]


Internet-Draft                    RAINS                   September 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Information Model . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Assertion . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.1.  Context in Assertions . . . . . . . . . . . . . . . .   8
       4.1.2.  Signatures in Assertions  . . . . . . . . . . . . . .   9
       4.1.3.  Shards and Zones  . . . . . . . . . . . . . . . . . .  10
       4.1.4.  Zone-Reflexive Assertions . . . . . . . . . . . . . .  11
     4.2.  Query . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       4.2.1.  Context in Queries  . . . . . . . . . . . . . . . . .  12
       4.2.2.  Answers to Queries  . . . . . . . . . . . . . . . . .  13
     4.3.  Address to Object Mapping . . . . . . . . . . . . . . . .  13
       4.3.1.  Context in Address Assertions . . . . . . . . . . . .  14
   5.  CBOR Data Model . . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  Symbol Table  . . . . . . . . . . . . . . . . . . . . . .  16
     5.2.  Message . . . . . . . . . . . . . . . . . . . . . . . . .  17
     5.3.  Message Section header  . . . . . . . . . . . . . . . . .  17
     5.4.  Assertion body  . . . . . . . . . . . . . . . . . . . . .  18
     5.5.  Shard body  . . . . . . . . . . . . . . . . . . . . . . .  19
     5.6.  Zone body . . . . . . . . . . . . . . . . . . . . . . . .  20
     5.7.  Query body  . . . . . . . . . . . . . . . . . . . . . . .  20
     5.8.  Address Assertion body  . . . . . . . . . . . . . . . . .  22
     5.9.  Address Query body  . . . . . . . . . . . . . . . . . . .  23
     5.10. Notification body . . . . . . . . . . . . . . . . . . . .  23
     5.11. Object  . . . . . . . . . . . . . . . . . . . . . . . . .  24
       5.11.1.  Certificate information format . . . . . . . . . . .  27
       5.11.2.  Name expression format . . . . . . . . . . . . . . .  29
     5.12. Tokens in queries and messages  . . . . . . . . . . . . .  30
     5.13. Signatures, delegation keys, and RAINS infrastructure
           keys  . . . . . . . . . . . . . . . . . . . . . . . . . .  31
       5.13.1.  EdDSA signature and public key format  . . . . . . .  32
       5.13.2.  ECDSA signature and public key format  . . . . . . .  33
     5.14. Capabilities  . . . . . . . . . . . . . . . . . . . . . .  33
   6.  Canonical signing format  . . . . . . . . . . . . . . . . . .  35
   7.  RAINS Protocol Definition . . . . . . . . . . . . . . . . . .  35
     7.1.  Message processing  . . . . . . . . . . . . . . . . . . .  35
     7.2.  Message Transmission  . . . . . . . . . . . . . . . . . .  39
     7.3.  Message Limits  . . . . . . . . . . . . . . . . . . . . .  39
     7.4.  Runtime Consistency Checking  . . . . . . . . . . . . . .  40
     7.5.  Integrity and Confidentiality Protection  . . . . . . . .  41
     7.6.  Cooperative Delegation Distribution . . . . . . . . . . .  41
   8.  RAINS Client Protocol . . . . . . . . . . . . . . . . . . . .  41



Trammell                 Expires March 24, 2018                 [Page 2]


Internet-Draft                    RAINS                   September 2017


   9.  RAINS Publication Protocol  . . . . . . . . . . . . . . . . .  42
   10. Deployment Considerations . . . . . . . . . . . . . . . . . .  42
     10.1.  Assertion Lifetime Management  . . . . . . . . . . . . .  42
     10.2.  Secret Key Management  . . . . . . . . . . . . . . . . .  43
     10.3.  Public Key Management  . . . . . . . . . . . . . . . . .  43
       10.3.1.  Key Phase and Key Rotation . . . . . . . . . . . . .  43
       10.3.2.  Next Key Assertions  . . . . . . . . . . . . . . . .  44
     10.4.  Unsigned Contained Assertions  . . . . . . . . . . . . .  44
     10.5.  Query Service Discovery  . . . . . . . . . . . . . . . .  44
     10.6.  Transition using translation between RAINS and DNS
            information models . . . . . . . . . . . . . . . . . . .  45
   11. Experimental Design and Evaluation  . . . . . . . . . . . . .  46
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  47
     13.1.  Server state exhaustion  . . . . . . . . . . . . . . . .  47
     13.2.  Query relay attacks  . . . . . . . . . . . . . . . . . .  48
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  48
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  48
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  48
     15.2.  Informative References . . . . . . . . . . . . . . . . .  49
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  51

1.  Introduction

   This document defines an experimental protocol for providing Internet
   name resolution services, as a replacement for DNS, called RAINS
   (RAINS, Another Internet Naming Service).  It is designed as a
   prototype to facilitate conversation about the evolution or
   replacement of the Domain Name System protocol, and was developed as
   a name resolution system for the SCION ("Scalability, Control, and
   Isolation on Next-Generation Networks") future Internet architecture
   [SCION].  It attempts to answer the question: "how would we design
   the DNS knowing what we do now," on the background of the properties
   of an ideal naming service described in [I-D.trammell-inip-pins].

   Its architecture (Section 3) and information model (Section 4) are
   largely compatible with the existing Domain Name System.  However, it
   does take several radical departures from DNS as presently defined
   and implemented:

   o  Delegation from a superordinate zone to a subordinate zone is done
      solely with cryptography: a superordinate defines the key(s) that
      are valid for signing assertions in the subordinate during a
      particular time interval.  Assertions about names can therefore
      safely be served from any infrastructure.






Trammell                 Expires March 24, 2018                 [Page 3]


Internet-Draft                    RAINS                   September 2017


   o  All time references in RAINS are absolute: instead of a time to
      live, each assertion's temporal validity is defined by the
      temporal validity of the signature(s) on it.

   o  All assertions have validity within a specific context.  A context
      determines the rules for chaining signatures to verify validity of
      an assertion.  The global context is a special case of context,
      which uses chains from the global naming root key.  The use of
      context explicitly separates global usage of the DNS from local
      usage thereof, and allows other application-specific naming
      constraints to be bound to names; see Section 4.1.1.  Queries are
      valid in one or more contexts, with specific rules for determining
      which assertions answer which queries; see Section 4.2.1.

   o  There is an explicit separation between registrant-level names and
      sub-registrant-level names, and explicit information about
      registrars and registrants available in the naming system at
      runtime.

   o  Sets of valid characters and rules for valid names are defined on
      a per-zone basis, and can be verified at runtime.

   o  Reverse lookups are done using a completely separate tree,
      supporting delegations of any prefix length, in accordance with
      CIDR [RFC4632] and the IPv6 addressing architecture [RFC4291].

   Instead of using a custom binary framing as DNS, RAINS uses Concise
   Binary Object Representation [RFC7049], partially in an effort to
   make implementations easier to verify and less likely to contain
   potentially dangerous parser bugs [PARSER-BUGS].  Like DNS, CBOR
   messages can be carried atop any number of substrate protocols; RAINS
   is presently defined to use TLS over persistent TCP connections (see
   Section 7).

2.  Terminology

   The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY, when they
   appear in all-capitals, are to be interpreted as defined in
   [RFC2119].

   In addition, the following terms are used in this document as
   defined:

   o  Authority: An entity which may make assertions about names in a
      zone, by virtue of holding a secret key which can generate
      signatures verifiable using a public key associated with a
      delegation to the zone.




Trammell                 Expires March 24, 2018                 [Page 4]


Internet-Draft                    RAINS                   September 2017


   o  Assertion: A mapping between a name and object(s) of specified
      types describing the name, signed by an authority for the zone
      containing the subject name.  See Section 4.1.

   o  Subject: The name to which an assertion pertains.

   o  Object: A type/value pair of information about a name within an
      assertion.

   o  Query: An expression of interest in certain types of objects
      pertaining to a subject name in one or more contexts.  See
      Section 4.2.

   o  Context: Additional information about the scope in which an
      assertion or query is valid.  See Section 4.1.1 and Section 4.2.1.

   o  Shard: A group of assertions common to a zone, with common
      signatures, which may be lexicographically complete for purposes
      of proving nonexistence of an assertion.  See Section 4.1.3.

   o  Zone: A group of all assertions valid at a given point in time,
      with common signatures, for a given level of delegation and
      context within the namespace.  See Section 4.1.3.

   o  RAINS Message: Unit of exchange in the RAINS protocol, containing
      assertions, shards, zones, queries, and notifications.  See
      Section 5.2.

   o  Notification: A RAINS-internal message section carrying
      information about the operation of the protocol itself.  See
      Section 5.10.

   o  Authority Service: A service provided by a RAINS Server for
      publishing assertions by an authority.  See Section 3.

   o  Query Service: A service provided by a RAINS Server for answering
      queries on behalf of a RAINS Client.  See Section 3.

   o  Intermediary Service: A service provided by a RAINS Server for
      answering queries and providing temporary storage for assertions
      on behalf of other RAINS Servers.  See Section 3.

   o  RAINS Server: A server that speaks the RAINS Protocol, and
      provides on or more services on behalf of other RAINS Servers and/
      or RAINS Clients.  See Section 3.






Trammell                 Expires March 24, 2018                 [Page 5]


Internet-Draft                    RAINS                   September 2017


   o  RAINS Client: A client that uses the Query Service of one or more
      RAINS Servers to retrieve assertions on behalf of applications
      that wish to connect to named services in the Internet.

3.  Architecture

   The RAINS architecture is simple, and resembles the architecture of
   DNS.  A RAINS Server is an entity that provides transient and/or
   permanent storage for assertions about names, and a lookup function
   that finds assertions for a given query about a name, either by
   searching local storage or by delegating to another RAINS server.
   RAINS servers can take on any or all of three roles:

   o  authority service, acting on behalf of an authority to ensure
      properly signed assertions are made available to the system
      (equivalent to an authoritative server in DNS);

   o  query service, acting on behalf of a client to answer queries with
      relevant assertions (equivalent to a recursive resolver in DNS),
      and to validate assertions on the client's behalf; and/or

   o  intermediary service, acting on behalf of neither but providing
      storage and lookup for assertions with certain properties for
      query and authority servers (partially replacing, but not really
      equivalent to, caching resolvers in DNS).

   RAINS Servers use the RAINS Protocol defined in this document to
   exchange queries and assertions.  RAINS Clients use a subset variant
   of the RAINS Protocol (called the RAINS Client Protocol) to interact
   with RAINS Servers providing query services on their behalf.

4.  Information Model

   The RAINS Protocol is based on an information model built around two
   kinds of information: Assertions and Queries.  An Assertion contains
   some information about a name or address, and a Query contains a
   request for information about a name of address.  The information
   model in this section omits information elements required by the
   resolution mechanism itself; these are defined in more detail in
   Section 5 and Section 7.

4.1.  Assertion

   An Assertion is a signed statement about a mapping from a subject
   name to an object value, and consists of the following elements:

   o  Context: name of the context in which the assertion is valid; see
      Section 4.1.1 below.



Trammell                 Expires March 24, 2018                 [Page 6]


Internet-Draft                    RAINS                   September 2017


   o  Subject: name about which the assertion is made.

   o  Zone: name of the zone in which the assertion is made.  The fully
      qualified name of the subject is made by appending the zone name
      to the subject name with a domain name separator ('.').

   o  Type: the type of information about the Subject contained in the
      assertion.  Each Assertion is about a single type of data.

   o  Object: the data of the indicated type associated with the Subject

   o  Signatures: one or more signatures generated by the authority for
      the Assertion.  Signatures contain a time interval during which
      they are considered valid.  See Section 4.1.2 below.

   The Types supported for each assertion are:

   o  Delegation: the authority associated with the zone identified by
      the name (roughly equivalent to the DNSSEC DS RRTYPE).  The Object
      contains a public key by which the authority can be identified.

   o  Redirection: The name(s) of one or more a RAINS servers providing
      authority service for the authority associated with the zone
      (roughly equivalent to the DNSSEC NS RRTYPE, but not always
      consulted directly during resolution).  The Object contains a set
      of names.

   o  Address: one or more addresses associated with the name (replaces
      DNS A and AAAA RTYPEs).  The Object contains a set of Addresses.
      An Address is an {address-family, value} tuple.

   o  Service-Info: one or more layer 4 ports and hostnames associated
      with a service name (replaces DNS SRV RRTYPE).  The object
      contains a {hostname, port-number, priority tuple}.

   o  Name: one or more names associated with the name (roughly
      equivalent to DNS CNAME).  The Object contains a set of names.

   o  Certificate: a certificate which must appear at a specified
      location in the certificate chain presented on a connection
      attempt with the named entity (roughly equivalent to DNS TLSA).

   o  Zone-Nameset: an expression of the set of names allowed within a
      zone; e.g.  Unicode scripts or codepages in which names in the
      zone may be issued.  This allows a zone to set policy on names in
      support of the distinguishability property in
      [I-D.trammell-inip-pins] that can be checked by RAINS servers at
      runtime.  An assertion about a Subject within a Zone whose name is



Trammell                 Expires March 24, 2018                 [Page 7]


Internet-Draft                    RAINS                   September 2017


      not allowed by a valid signed Zone-Nameset expression is taken to
      be invalid, even if it has a valid signature.

   o  Zone-Registrar: Information about the organization that caused a
      Subject name to exist, for registrant-level names.

   o  Zone-Registrant: Information about the organization responsible
      for a Subject name, for registrant-level names.

   o  Infrastructure Key: Information about public keys used for object
      security within the RAINS infrastructure itself.  The Object
      contains a public key by which a named RAINS server can be
      identified.

   o  External Key: Information about public keys used for additional
      signatures on assertions.  The external key is usually discovered
      outside RAINS, and can be verified by comparison with the key
      stored in a RAINS assertion.  The Object contains an external
      public key.

   o  Subsequent Key: Assertions about delegations are made by a zone's
      superordinate.  A zone may request that its superordinate delegate
      to a new public key by publishing a subsequent key assertion
      (replacing the mechanism implemented by CDS/CDNSKEY in DNS).

   For a given {subject, type} tuple, multiple assertions can be valid
   at a given point in time; the union of the object values of all of
   these assertions is considered to be the set of valid values at that
   point in time.

4.1.1.  Context in Assertions

   Assertion contexts are used to determine the validity of the
   signature by the declared authority as follows:

   o  The global context is identified by the special context name '.'.
      Assertions in the global context are signed by the authority for
      the subject name.  For example, assertions about the name
      simplon.inf.ethz.ch in the global context are only valid if signed
      by the relevant authority inf.ethz.ch.

   o  A local context is associated with a given authority.  The
      authority-part and the context-part of a local context name are
      divided by a context marker ('cx-').  The authority-part directly
      identifies the authority whose key was used to sign the assertion;
      assertions within a local context are only valid if signed by the
      identified authority.  Authorities have complete control over how




Trammell                 Expires March 24, 2018                 [Page 8]


Internet-Draft                    RAINS                   September 2017


      the contexts under their namespaces are arranged, and over the
      names within those contexts.

   Assertion context is the mechanism by which RAINS provides explicit
   inconsistency (see section 5.3.2 of [I-D.trammell-inip-pins]).  Some
   examples illustrate how context works:

   o  For the common split-DNS case, an enterprise could place names for
      machines on its local networks within a separate context.  E.g., a
      workstation could be named simplon.cab.inf.ethz.ch within the
      context staff-workstations.cx-.inf.ethz.ch.  Assertions about this
      name would be signed by the authority for inf.ethz.ch.  Here, the
      context serves simply as a marker, without enabling an alternate
      signature chain: note that the name simplon.cab.inf.ethz.ch can be
      validly signed by the authority for inf.ethz.ch if no delegation
      exists for cab.inf.ethz.ch.  The context simply marks this
      assertion as internal.  This allows a client making requests of
      local names to know they are local, and for local resolvers to
      manage visibility of assertions outside the enterprise: explicit
      context makes accidental leakage of both queries and assertions
      easier to detect and avoid.

   o  Contexts make captive-portal interactions more explicit: a captive
      portal resolver could respond to a query for a common website
      (e.g. www.google.ch) with a signed response directed at the
      captive portal, but within a context identifying the location as
      well as the ISP (e.g.  sihlquai.zurich.ch.cx-
      .starbucks.access.some-isp.net.).  This response will be signed by
      the authority for starbucks.access.some-isp.net.  This signature
      achieves two things: first, the client knows the result for
      www.google.ch is not globally valid; second, it can present the
      user with some indication as to the identity of the captive portal
      it is connected to.

   Further examples showing how context can be used in queries as well
   are given in Section 4.2.1 below.

   Developing conventions for assertion contexts for different
   situations will require implementation and deployment experience, and
   is a subject for future work.

4.1.2.  Signatures in Assertions

   A signature over an assertion contains the following information
   elements:

   o  Algorithm: identifier of the algorithm used to generate the
      signature.



Trammell                 Expires March 24, 2018                 [Page 9]


Internet-Draft                    RAINS                   September 2017


   o  Keyspace: identifier of the key space used to generate the
      signature, i.e. how the key to verify the signature should be
      retrieved.  RAINS supports an internal keyspace, but allows
      signatures using externally obtained keys to appear on assertions
      for additional security.

   o  Keyphase: phase of the key used to generate the signature.  Since
      multiple keys may be valid for a given authority at a given point
      in time, this allows the correct key to be retrieved directly.

   o  Valid-Since: a timestamp of the start of validity of this
      signature.

   o  Valid-Until: a timestamp of the end of validity of this signature.

   o  Signature: the cryptographic signature itself, whose format is
      determined by the algorithm used.

   The signature protects all the information in an assertion as well as
   its own algorithm identifier, keyspace, keyphase, valid-since, and
   valid-until values; it does not protect other signatures on the
   assertion.

4.1.3.  Shards and Zones

   Assertions may also be grouped and signed as a group.  A shard is a
   set of assertions within the same zone and context, protected by one
   or more signatures over all assertions within the shard.  Shards have
   an exclusive lexicographic range, and contain all assertions for
   names within a zone within that range.  This lexicographic
   completeness leads to the property that given a subject and an
   authenticated shard, it can be shown that either an assertion with a
   given name and type exists within the shard or does not exist at all.

   A shard has the following information elements:

   o  Context: name of the context in which the assertions in the shard
      are valid; see Section 4.1.1 above.

   o  Zone: name of the zone in which the assertions are made.

   o  Content: a set of assertions sharing the context and zone.

   o  Signatures: one or more signatures generated by the authority for
      the shard; see Section 4.1.2.






Trammell                 Expires March 24, 2018                [Page 10]


Internet-Draft                    RAINS                   September 2017


   For efficiency's sake, information elements within a shard common to
   all assertions (zone, context, signature) within the shard may be
   omitted from the assertions themselves.

   A zone is the entire set of shards subject to a given authority
   within a given context.  There are three kinds of zones; treating
   these zones differently may allow lookup protocol optimizations:

   o  Zones containing only delegation assertions are delegation-only
      zones.  Delegation-only zones are not relevant as part of an
      assertion lookup, other than for discovering and verifying
      authority.  Top-level domains are generally delegation-only.

   o  Zones containing no delegation assertions are final zones.  Final
      zones are not relevant as part of an authority discovery.

   o  Zones containing at least one delegation assertion and at least
      one assertion that is not a delegation assertion are mixed zones.
      No optimizations are available for mixed zones.

   A zone has the following information elements:

   o  Context: name of the context in which the assertions in the zone
      are valid; see Section 4.1.1 above.

   o  Zone: name of the zone.

   o  Content: a set of assertions and/or shards sharing the context and
      zone.

   o  Signatures: one or more signatures generated by the authority for
      the zone; see Section 4.1.2.

   o  Kind: delegation-only, final, or mixed; see above.

4.1.4.  Zone-Reflexive Assertions

   A zone may make an assertion about itself by using the string "@" as
   a subject name.  This facility can be used for any assertion type,
   but is especially useful for self-signing root zones, and for a zone
   to make a subsequent key assertion about itself.  If an assertion of
   a given type about a zone is available both in the zone itself and in
   the superordinate zone, the assertion in the superordinate zone will
   take precedence.







Trammell                 Expires March 24, 2018                [Page 11]


Internet-Draft                    RAINS                   September 2017


4.2.  Query

   A query is a request for a set of assertions supporting a conclusion
   about a given subject-object mapping.  It consists of the following
   information elements:

   o  Context: The context(s) in which assertions answering the query
      will be accepted; see Section 4.2.1 below.

   o  Qualified-Subject: the name about which the query is made.  The
      subject name in a query must be fully-qualified.

   o  Types: a set of assertion types the querier is interested in.

   o  Valid-Until: an optional client-generated timestamp for the query
      after which it expires and should not be answered.

   o  Query Token: a client-generated token for the query, which can be
      used in the answer to refer to the query.

   o  Options: a set of options by which a client may specify tradeoffs
      (e.g. privacy for performance).

   A query expresses interest about all the given types of assertion in
   all the specified contexts; more complex expressions of which types
   in which contexts must be asked using multiple queries.  Preferences
   for tradeoffs (freshness, bandwidth efficiency, latency, privacy
   preservation) in servicing a query may be bound to the query using
   query options.

4.2.1.  Context in Queries

   Context is used in queries as it is in assertions (see
   Section 4.1.1).  Assertion contexts in an answer to a query have to
   match the context in the query in order to respond to a query.  The
   Context section of a query contains the context of desired
   assertions; a special "any" context (represented by the empty string)
   indicates that assertions in any context will be accepted.

   Query contexts can also be used to provide additional information to
   RAINS servers about the query.  For example, context can provide a
   method for explicit selection of a CDN server not based on either the
   client's or the resolver's address (see [RFC7871]).  Here, the CDN
   creates a context for each of its content zones, and an external
   service selects appropriate contexts for the client based not just on
   client source address but passive and active measurement of
   performance.  Queries for names at which content resides can then be
   made within these contexts, with the priority order of the contexts



Trammell                 Expires March 24, 2018                [Page 12]


Internet-Draft                    RAINS                   September 2017


   reflecting the goodness of the zone for the client.  Here, a context
   might be zrh.cx-.cdn-zones.some-cdn.com for names of servers hosting
   content in a CDN's Zurich data center, and a client could represent
   its desire to find content nearby by making queries in the zrh.cx-,
   fra.cx- (Frankfurt), and ams.cx- (Amsterdam) contexts within cdn-
   zones .some-cdn.com.  In all cases, the assertions themselves will be
   signed by the authority for cdn-zones.some-cdn.com, accurately
   representing that it is the CDN, not the owner of the related name in
   the global context, that is making the assertion.

   As with assertion contexts, developing conventions for query contexts
   for different situations will require implementation and deployment
   experience, and is a subject for future work.

4.2.2.  Answers to Queries

   An answer consists of a set of assertions, shards, and/or zones which
   respond to a query.  If the query contained a token, it is bound to
   that query via the token.

   The content of an answer depends on whether the answer is positive or
   negative.  A positive answer contains the information requested in
   the smallest atomic container that can be found, usually a single
   assertion.  A negative answer contains the information used to verify
   it; either a Shard, an entire Zone, or a Zone-Nameset assertion
   showing the name is illegal within the zone.

   A query is taken to have an inconclusive answer when no answer
   returns to the querier before the query's Valid-Until time.

4.3.  Address to Object Mapping

   In contrast to the current domain name system, information about
   addresses is stored in a completely separate tree, keyed by address
   and prefix.  An address assertion consists of the following elements:

   o  Context: name of the context in which the assertion is valid; see
      Section 4.3.1.

   o  Subject: address about which the assertion is made, consisting of
      an address family, address, and prefix length.  A subject may be a
      network address (where the prefix length is less than the address
      length for the given address family) or a host address (where the
      prefix length is equal to the address length for the given address
      family)

   o  Type: the type of information about the Subject contained in the
      assertion.  Each Assertion is about a single type of data.



Trammell                 Expires March 24, 2018                [Page 13]


Internet-Draft                    RAINS                   September 2017


   o  Object: the data of the indicated type associated with the Subject

   o  Signatures: one or more signatures generated by the authority for
      the Assertion.  Signatures contain a time interval during which
      they are considered valid, as in Section 4.1.2.

   The following object types are available:

   o  Delegation: the authority associated with the subject network
      address.  The Object contains a public key by which the authority
      can be identified.  Only available for network address subjects.

   o  Redirection: The name(s) of one or more a RAINS servers providing
      authority service for the authority associated with the subject
      network address.  The Object contains a set of names.  Only
      available for network address subjects.

   o  Name: one or more names associated with the subject network
      address.  The Object contains a set of names.  Only available for
      host address subjects.

   o  Zone-Registrant: Information about the organization responsible
      for a network.  Only available for network address subjects.

   Queries for addresses are similar to those for names, and consist of
   the following information elements:

   o  Context: Context in which the query is made; this must match the
      assertion context as in Section 4.3.1.

   o  Subject: the address about which the query is made, consisting of
      an address family, address, and prefix length.

   o  Types: a set of assertion types the querier is interested in, as
      above.

   o  Valid-Until: an optional client-generated timestamp for the query
      after which it expires and should not be answered.

   o  Query Token: a client-generated token for the query, which can be
      used in the answer to refer to the query.

4.3.1.  Context in Address Assertions

   Just as in forward Assertions, Assertion contexts are used in address
   assertions to determine the scope of an address assertion, and the
   signature chain used to verify it.




Trammell                 Expires March 24, 2018                [Page 14]


Internet-Draft                    RAINS                   September 2017


   o  The global addressing context for each address family is
      identified by the special context name '.'.  For both IPv4 and
      IPv6 addresses, this is rooted at IANA, which delegates to the
      RIRs, which then delegates to LIRs and to address-holding
      registries.

   o  Local contexts associated with a given authority in a forward tree
      can also make assertions about addresses.  As with contexts in
      forward assertions, the authority-part and the context-part of a
      local context name are divided by a context marker ('cx-').  The
      authority-part directly identifies the authority whose key was
      used to sign the assertion; assertions within a local context are
      only valid if signed by the identified authority.  Authorities
      have complete control over how the contexts under their namespaces
      are arranged, and over the names within those contexts.

   Each local context may have a root address space zone (0/0), but
   these root address spaces may only delegate addresses that are
   reserved for local use [RFC1918] [RFC4193].  Local context assertions
   for other addresses are invalid.

5.  CBOR Data Model

   The RAINS data model is a relatively straightforward mapping of the
   information model in Section 4 to the Concise Binary Object
   Representation (CBOR) [RFC7049], with an outer message type providing
   a mechanism for future capabilities-based versioning and recognition
   of a message as a RAINS message.

   Messages, assertions, shards, zones, queries, and notifications are
   each represented as a CBOR map of integer keys to values, which
   allows each of these types to be extended in the future, as well as
   the addition of non- standard, application-specific information to
   RAINS messages and data items.  A common registry of map keys is
   given in Table 1.  RAINS implementations MUST ignore map keys the do
   not understand.  Integer map keys in the range -22 to +23 are
   reserved for the use of future versions or extensions to the RAINS
   protocol.

   Message contents, signatures and object values are implemented as
   type- prefixed CBOR arrays with fixed meanings of each array element;
   the structure of these lower-level elements can therefore not be
   extended.  Message section types are given in Table 2, object types
   in Table 5, and signature algorithms in Table 9.







Trammell                 Expires March 24, 2018                [Page 15]


Internet-Draft                    RAINS                   September 2017


5.1.  Symbol Table

   The meaning of each of the integer keys in message, zone, shard,
   assertion, and notification maps is given in the symbol table below:

   +------+---------------+--------------------------------------------+
   | Code | Name          | Description                                |
   +------+---------------+--------------------------------------------+
   |    0 | signatures    | Signatures on a message or section         |
   |      |               |                                            |
   |    1 | capabilities  | Capabilities of server sending message     |
   |      |               |                                            |
   |    2 | token         | Token for referring to a data item         |
   |      |               |                                            |
   |    3 | subject-name  | Subject name in an assertion               |
   |      |               |                                            |
   |    4 | subject-zone  | Zone name in an assertion                  |
   |      |               |                                            |
   |    5 | subject-addr  | Subject address in address assertion or    |
   |      |               | zone                                       |
   |      |               |                                            |
   |    6 | context       | Context of an assertion or query           |
   |      |               |                                            |
   |    7 | objects       | Objects of an assertion                    |
   |      |               |                                            |
   |    8 | query-name    | Fully qualified name for a query           |
   |      |               |                                            |
   |   10 | query-types   | Acceptable object types for query          |
   |      |               |                                            |
   |   11 | shard-range   | Lexical range of Assertions in Shard       |
   |      |               |                                            |
   |   12 | query-expires | Absolute timestamp for query expiration    |
   |      |               |                                            |
   |   13 | query-opts    | Set of query options requested             |
   |      |               |                                            |
   |   21 | note-type     | Notification type                          |
   |      |               |                                            |
   |   22 | note-data     | Additional notification data               |
   |      |               |                                            |
   |   23 | content       | Content of a message, shard, or zone       |
   +------+---------------+--------------------------------------------+

                   Table 1: CBOR Map Keys used in RAINS








Trammell                 Expires March 24, 2018                [Page 16]


Internet-Draft                    RAINS                   September 2017


5.2.  Message

   All interactions in RAINS take place in an outer envelope called a
   Message, which is a CBOR map tagged with the RAINS Message tag (hex
   0xE99BA8, decimal 15309736).

   A Message map MAY contain a signatures (0) key, whose value is an
   array of Signatures over the entire message as defined in
   Section 5.13, to be verified against the infrastructure key for the
   RAINS Server originating the message.

   A Message map MAY contain a capabilities (1) key, whose value is
   described in Section 5.14.

   A Message map MUST contain a token (2) key, whose value is a 16-byte
   array.  See Section 5.12 for details.

   A Message map MUST contain a content (23) key, whose value is an
   array of Message Sections; a Message Section is either an Assertion,
   Shard, Zone, or Query, or Notification.

5.3.  Message Section header

   Each Message Section in the Message's content value MUST be a two-
   element array.  The first element in the array is the message section
   type, encoded as an integer as in Section 5.1.  The second element in
   the array is a message section body, a CBOR map defined as in the
   subsections shown in Section 5.1:

       +------+--------------+-------------------------------------+
       | Code | Name         | Description                         |
       +------+--------------+-------------------------------------+
       |    1 | assertion    | Assertion (see Section 5.4)         |
       |      |              |                                     |
       |   -1 | revassertion | Address Assertion (see Section 5.8) |
       |      |              |                                     |
       |    2 | shard        | Shard (see Section 5.5)             |
       |      |              |                                     |
       |    3 | zone         | Zone (see Section 5.6)              |
       |      |              |                                     |
       |    4 | query        | Query (see Section 5.7)             |
       |      |              |                                     |
       |   -4 | revquery     | Address Query (see Section 5.9      |
       |      |              |                                     |
       |   23 | notification | Notification (see Section 5.10)     |
       +------+--------------+-------------------------------------+

                    Table 2: Message Section Type Codes



Trammell                 Expires March 24, 2018                [Page 17]


Internet-Draft                    RAINS                   September 2017


5.4.  Assertion body

   An Assertion body is a map.  The keys present in this map depend on
   whether the Assertion is contained in a Message Section or in a Shard
   or Zone.

   Assertions contained in Message Sections are "bare Assertions".
   Since they cannot inherit any values from their containers, they MUST
   contain the signatures (0), subject-name (3), subject-zone (4),
   context (6), and objects (7) keys.

   Assertions within a Shard or Zone are "contained Assertions", and can
   inherit values from their containers.  A contained Assertion MUST
   contain the subject- name (3) and objects (7) keys.  The subject-zone
   (4) and context (6) keys MUST NOT be present.  They are assumed to
   have the same value as the corresponding values in the containing
   Shard or Zone for signature generation and signature verification
   purposes; see Section 5.13.

   A contained Assertion SHOULD contain the signatures (0) key, since an
   unsigned contained Assertion cannot be used by a RAINS server to
   answer a query; it must be returned in a signed Shard or Zone.

   The value of the signatures (0) key, if present, is an array of one
   or more Signatures as defined in Section 5.13.  If not present, the
   containing Shard or Zone MUST be signed.  Signatures on a contained
   Assertion are generated as if the inherited subject-zone and context
   values are present in the Assertion, whether actually present or not.
   The signatures on the Assertion are to be verified against the
   appropriate key for the Zone containing the Assertion in the given
   context, as described in Section 4.1.2.

   The value of the subject-name (3) key is a UTF-8 encoded [RFC3629]
   string containing the name of the subject of the assertion.  The
   subject name never contains the zone in which the subject name; the
   fully-qualified name is obtained by joining the subject-name to the
   subject-zone with a '.' character.  The subject-name must be valid
   according to the nameset expression for the zone, if any.

   The value of the subject-zone (4) key, if present, is a UTF-8 encoded
   string containing the name of the zone in which the assertion is
   made.  If not present, the zone of the assertion is inherited from
   the containing Shard or Zone.

   The value of the context (6) key, if present, is a UTF-8 encoded
   string containing the name of the context in which the assertion is
   valid.  If not present, the context of the assertion is inherited
   from the containing Shard or Zone.



Trammell                 Expires March 24, 2018                [Page 18]


Internet-Draft                    RAINS                   September 2017


   The value of the objects (7) key is an array of objects, as defined
   in Section 5.11.

5.5.  Shard body

   A Shard body is a map.  The keys present in the map depend on whether
   the Shard is contained in a Message Section or in a Zone.

   Shards contained in Message Sections are "bare Shards".  Since they
   cannot inherit any values from their contained Zone, they MUST
   contain the content (23), signatures (0), subject-zone (4), context
   (6), and shard-range (11) keys.

   Shards within a Zone are "contained Shards", and can inherit values
   from their containing Zone.  A contained Shard MUST contain the
   shard-range(11) and content (23) keys.  The subject-zone (4) and
   context (6) keys MUST NOT be present.  They are assumed to have the
   same value as the corresponding values in the containing Zone for
   signature generation and signature verification purposes; see
   Section 5.13.

   A contained Shard SHOULD contain the signatures (0) key if it also
   contains a shard-range (11) key, since an unsigned contained Shard
   cannot be used by a RAINS server to answer a query for nonexistence;
   it must be returned in a signed Zone.

   The value of the content (23) key is an array of Assertion bodies as
   defined in Section 5.4 .Assertions within a Shard SHOULD be sorted by
   name in ascending lexicographic order.

   The value of the signatures (0) key, if present, is an array of one
   or more Signatures as defined in Section 5.13.  If not present, the
   containing Zone MUST be signed.  Signatures on a contained Shard are
   generated as if the inherited subject-zone and values are present in
   the Shard, whether actually present or not.  The signatures on the
   Shard are to be verified against the appropriate key for the Zone
   containing the Shard in the given context, as described in
   Section 4.1.2.

   The value of the subject-zone (4) key, if present, is a UTF-8 encoded
   string containing the name of the zone in which the Assertions within
   the Shard is made.  If not present, the zone of the assertion is
   inherited from the containing Zone.

   The value of the context (6) key, if present, is a UTF-8 encoded
   string containing the name of the context in which the Assertions
   within the Shard are valid.  If not present, the context of the
   assertion is inherited from the containing Zone.



Trammell                 Expires March 24, 2018                [Page 19]


Internet-Draft                    RAINS                   September 2017


   Shards are lexicographically complete within the range described in
   its the shard-range value: a mapping for a subject-name that should
   be between the two values given in the range but is not is asserted
   to not exist.  Lexicographic sorting is done on subject names by
   ordering Unicode codepoints in ascending order.

   The shard-range value MUST be a two element array of strings or nulls
   (subject-name A, subject-name B).  A must lexicographically sort
   before B, but neither subject name need be present in the shard's
   contents.  If A is null, the shard begins at the beginning of the
   zone.  If B is null, the shard ends at the end of the zone.  The
   shard MUST NOT contain any assertions whose subject names sort before
   A or after B.  In addition, the authority for the shard belongs to
   MUST NOT make any assertions during the period of validity of the
   shard's signatures that would fall between subject-name A and
   subject-name B inclusive that are not contained within the shard (see
   Section 7.4).

5.6.  Zone body

   A Zone body is a map.  Zones MUST contain the content (23),
   signatures (0), subject-zone (4), and context (6) keys.

   Signatures on the Zone are to be verified against the appropriate key
   for the Zone in the given context, as described in Section 4.1.2.

   The value of the content (23) key is an array of Shard bodies as
   defined in Section 5.5 and/or Assertion bodies as defined in
   Section 5.4.  Shards and Assertions in the content array SHOULD be
   sorted by shard range or name in ascending qlexicographic order.

   The value of the subject-zone (4) key is a UTF-8 encoded string
   containing the name of the Zone.

   The value of the context (6) key is a UTF-8 encoded string containing
   the name of the context for which the Zone is valid.

5.7.  Query body

   A Query body is a map.  Queries MUST contain the query-name (8),
   context (6), query-types (10), and query-expires (12) keys.  Queries
   MAY contain the query-opts (13) keys.

   The value of the context (6) key is a UTF-8 encoded string containing
   the name of the context to which a query pertains.  A zero-length
   string indicates that assertions will be accepted in any context.





Trammell                 Expires March 24, 2018                [Page 20]


Internet-Draft                    RAINS                   September 2017


   The value of the query-types (10) key is an array of integers
   encoding the type(s) of objects (as in Section 5.11) acceptable in
   answers to the query.  All values in the query-type array are treated
   at equal priority: [2,3] means the querier is equally interested in
   both IPv4 and IPv6 addresses for the query-name.  An empty query-
   types array indicates that objects of any type are acceptable in
   answers to the query.

   The value of the query-expires (12) key, is a CBOR integer counting
   seconds since the UNIX epoch UTC, identified with tag value 1 and
   encoded as in section 2.4.1 of [RFC7049].  After the query-expires
   time, the query will have been considered not answered by the
   original issuer.

   The value of the query-opts (13) key, if present, is an array of
   integers in priority order of the querier's preferences in tradeoffs
   in answering the query, as in Table 3.

   +------+------------------------------------------------------------+
   | Code | Description                                                |
   +------+------------------------------------------------------------+
   |    1 | Minimize end-to-end latency                                |
   |      |                                                            |
   |    2 | Minimize last-hop answer size (bandwidth)                  |
   |      |                                                            |
   |    3 | Minimize information leakage beyond first hop              |
   |      |                                                            |
   |    4 | No information leakage beyond first hop: cached answers    |
   |      | only                                                       |
   |      |                                                            |
   |    5 | Expired assertions are acceptable                          |
   |      |                                                            |
   |    6 | Enable query token tracing                                 |
   |      |                                                            |
   |    7 | Disable verification delegation (client protocol only)     |
   |      |                                                            |
   |    8 | Suppress proactive caching of future assertions            |
   +------+------------------------------------------------------------+

                        Table 3: Query Option Codes

   Options 1-5 specify performance/privacy tradeoffs.  Each server is
   free to determine how to minimize each performance metric requested;
   however, servers MUST NOT generate queries to other servers if "no
   information leakage" is specified, and servers MUST NOT return
   expired assertions unless "expired assertions acceptable" is
   specified.




Trammell                 Expires March 24, 2018                [Page 21]


Internet-Draft                    RAINS                   September 2017


   Option 6 specifies that a given token (see Section 5.12) should be
   used on all queries resulting from a given query, allowing
   traceability through an entire RAINS infrastructure.  It is meant for
   debugging purposes.

   By default, a client service will perform verification of negative
   queries and return a 404 No Assertion Exists for queries with a
   consistent proof of non- existence, within a message signed by the
   query service's infrakey.  Option 7 disables this behavior, and
   causes the query service to return the shard proving nonexistence for
   verification by the client.  It is intended to be used with untrusted
   query services.

   Option 8 specifies that a querier's interest in a query is strictly
   ephemeral, and that future assertions related to this query SHOULD
   NOT be proactively pushed to the querier.

5.8.  Address Assertion body

   Assertions about addresses are similar to assertions about names, but
   keyed by address and restricted in terms of the objects they can
   contain.  An Address Assertion body is a map which MUST contain the
   signatures (0), subject-addr (5), context (6), and objects (7) keys.

   The value of the signatures (0) key is an array of one or more
   Signatures as defined in Section 5.13.

   The value of the subject-addr (5) key is a three element CBOR array.
   The first element of the array is the address family encoded as an
   object type, 2 for IPv6 addresses and 3 for IPv4 addresses.  The
   second element is the prefix length encoded as an integer, 0-128 for
   IPv6 and 0-32 for IPv4.  The third element is the address, encoded as
   in Section 5.11.  Subject addresses with the maximum prefix length
   for the address family are subject host addresses, and are nameable;
   subject addresses with less than the maximum prefix length are
   subject network addresses, and are delegatable.

   The value of the context (6) key, if present, is a UTF-8 string
   containing the name of the context in which the Address Assertion is
   valid.  See Section 4.3.1.

   The value of the objects (7) key is an array of objects, as defined
   in Section 5.11.  Only object types redirection, delegation, and
   registrant are available for subject network addresses, and only
   object type name is available for subject host addresses.






Trammell                 Expires March 24, 2018                [Page 22]


Internet-Draft                    RAINS                   September 2017


5.9.  Address Query body

   Queries for assertions about addresses are similar to queries for
   assertions about names, but have semantic restrictions similar to
   those for Address Assertions.

   An Address Query body is a map.  Queries MUST contain the subject-
   addr (5), context (6), query-types (10), and query-expires (12) keys.
   Address Queries MAY contain query-opts (13) key.

   The value of the subject-addr (5) key is a three-element CBOR array.
   The first element of the array is the address family encoded as an
   object type, 2 for IPv6 addresses and 3 for IPv4 addresses.  The
   second element is the prefix length encoded as an integer, 0-128 for
   IPv6 and 0-32 for IPv4.  The third element is the address, encoded as
   in Section 5.11.

   The value of the context (6) key is a UTF-8 encoded string containing
   the name of the context for which the Query is valid.  Unlike queries
   for names, Address Queries can only pertain to a single context.  See
   Section 4.3.1 for more.

   The value of the query-types (10) key is an array of integers
   encoding the type(s) of objects (as in Section 5.11) acceptable in
   answers to the query.  All values in the query-type array are treated
   at equal priority: [4,5] means the querier is equally interested in
   both redirection and delegation for the subject-addr.  An empty
   query-types array indicates that objects of any type are acceptable
   in answers to the query.

   The value of the query-expires (12) key is a CBOR integer counting
   seconds since the UNIX epoch UTC, identified with tag value 1 and
   encoded as in section 2.4.1 of [RFC7049].  After the query-expires
   time, the query will have been considered not answered by the
   original issuer.

   The value of the query-opts (13) key, if present, is an array of
   integers in priority order of the querier's preferences in tradeoffs
   in answering the query, as in Table 3.  See Section 5.7 for more.

   An Address Assertion with a more-specific prefix is preferred over a
   less-specific in response to a Address Query.

5.10.  Notification body

   Notification Message Sections contain information about the operation
   of the RAINS protocol itself.  A Notification Message Section body is
   a map which MUST contain the token (2) and note-type (21) keys and



Trammell                 Expires March 24, 2018                [Page 23]


Internet-Draft                    RAINS                   September 2017


   MAY contain the note-data (22) key.  The value of the note-type key
   is encoded as an integer as in the Table 4.

           +------+--------------------------------------------+
           | Code | Description                                |
           +------+--------------------------------------------+
           |  100 | Connection heartbeat                       |
           |      |                                            |
           |  399 | Capability hash not understood             |
           |      |                                            |
           |  400 | Bad message received                       |
           |      |                                            |
           |  403 | Inconsistent message received              |
           |      |                                            |
           |  404 | No assertion exists (client protocol only) |
           |      |                                            |
           |  413 | Message too large                          |
           |      |                                            |
           |  500 | Unspecified server error                   |
           |      |                                            |
           |  501 | Server not capable                         |
           |      |                                            |
           |  504 | No assertion available                     |
           +------+--------------------------------------------+

                     Table 4: Notification Type Codes

   Note that the status codes are chosen to be mnemonically similar to
   status codes for HTTP [RFC7231].  Details of the meaning of each
   status code are given in Section 7.

   The value of the token (2) key is a 16-byte array, which MUST contain
   the token of the message or query to which the notification is a
   response.  See Section 5.12.

   The value of the note-data (22) key, if present, is a UTF-8 encoded
   string with additional information about the notification, intended
   to be displayed to an administrator to help debug the issue
   identified by the negotiation.

5.11.  Object

   Objects are encoded as arrays in CBOR, where the first element is the
   type of the object, encoded as an integer in the following table:







Trammell                 Expires March 24, 2018                [Page 24]


Internet-Draft                    RAINS                   September 2017


       +------+--------------+-------------------------------------+
       | Code | Name         | Description                         |
       +------+--------------+-------------------------------------+
       |    1 | name         | name associated with subject        |
       |      |              |                                     |
       |    2 | ip6-addr     | IPv6 address of subject             |
       |      |              |                                     |
       |    3 | ip4-addr     | IPv4 address of subject             |
       |      |              |                                     |
       |    4 | redirection  | name of zone authority server       |
       |      |              |                                     |
       |    5 | delegation   | public key for zone delgation       |
       |      |              |                                     |
       |    6 | nameset      | name set expression for zone        |
       |      |              |                                     |
       |    7 | cert-info    | certificate information for name    |
       |      |              |                                     |
       |    8 | service-info | service information for srvname     |
       |      |              |                                     |
       |    9 | registrar    | registrar information               |
       |      |              |                                     |
       |   10 | registrant   | registrant information              |
       |      |              |                                     |
       |   11 | infrakey     | public key for RAINS infrastructure |
       |      |              |                                     |
       |   12 | extrakey     | external public key for subject     |
       |      |              |                                     |
       |   13 | nextkey      | next public key for subject         |
       +------+--------------+-------------------------------------+

                        Table 5: Object type codes

   A name (1) object contains a name associated with a name as an alias.
   It is represented as a three-element array.  The second element is a
   fully-qualified name as a UTF-8 encoded string.  The third type is an
   array of object type codes for which the alias is valid, with the
   same semantics as the query-types (9) key in queries (see
   Section 5.7).

   An ip6-addr (2) object contains an IPv6 address associated with a
   name.  It is represented as a two element array.  The second element
   is a byte array of length 16 containing an IPv6 address in network
   byte order.

   An ip4-addr (3) object contains an IPv4 address associated with a
   name.  It is represented as a two element array.  The second element
   is a byte array of length 4 containing an IPv4 address in network
   byte order.



Trammell                 Expires March 24, 2018                [Page 25]


Internet-Draft                    RAINS                   September 2017


   A redirection (4) object contains the fully-qualified name of a RAINS
   authority server for a named zone.  It is represented as a two-
   element array.  The second element is a fully-qualified name of an
   RAINS authority server as a UTF-8 encoded string.

   A delegation (5) object contains a public key used to generate
   signatures on assertions in a named zone, and by which a delegation
   of a name within a zone to a subordinate zone may be verified.  It is
   represented as an N-element array.  The second element is a signature
   algorithm identifier as in Section 5.13.  Additional elements are as
   defined in Section 5.13 for the given algorithm identifier and
   keyspace.

   A nameset (6) object contains an expression defining which names are
   allowed and which names are disallowed in a given zone.  It is
   represented as a two- element array.  The second element is a nameset
   expression to be applied to each name element within the zone without
   an intervening delegation, as defined in Section 5.11.2

   A cert-info (7) object contains an expression binding a certificate
   or certificate authority to a name, such that connections to the name
   must either use the bound certificate or a certificate signed by a
   bound authority.  It is represented as an five-element array, as
   defined in Section 5.11.1.

   A service-info (8) object gives information about a named service.
   Services are named as in [RFC2782].  It is represented as a four-
   element array.  The second element is a fully-qualified name of a
   host providing the named service as a UTF-8 string.  The third
   element is a transport port number as a positive integer in the range
   0-65535.  The fourth element is a priority as a positive integer,
   with lower numbers having higher priority.

   A registrar (9) object gives the name and other identifying
   information of the registrar (the organization which caused the name
   to be added to the namespace) for organization-level names.  It is
   represented as a two element array.  The second element is a UTF-8
   string of maximum length 256 bytes containing identifying information
   chosen by the registrar according to the registry's policy.

   A registrant (10) object gives information about the registrant of an
   organization-level name.  It is represented as a two element array.
   The second element is a UTF-8 string with a maximum length of 4096
   bytes containing this information, with a format chosen by the
   registrar according to the registry's policy.

   An infrakey (11) object contains a public key used to generate
   signatures on messages by a named RAINS server, by which a RAINS



Trammell                 Expires March 24, 2018                [Page 26]


Internet-Draft                    RAINS                   September 2017


   message signature may be verified by a receiver.  It is identical in
   structure to a delegation object, as defined in Section 5.13.
   Infrakey signatures are especially useful for clients which delegate
   verification to their query servers to authenticate the messages sent
   by the query server.

   An extrakey (12) object contains a public key used to generate
   signatures on assertions in a named zone outside of the normal
   delegation chain.  It is represented as an 4-element array, where the
   second element is a signature algorithm identifier, and the third
   element is keyspace identifier, as in Section 5.13.  The fourth
   element is the public key, as defined in Section 5.13 for the given
   algorithm identifier.  An extrakey may be matched with a public key
   obtained through other means for additional authentication of an
   assertion.  Extrakeys are different from delegation keys in that they
   may not be used in the delegation chain: an extrakey signature is
   valid only on assertions of object types other than delegation.

   A nextkey (13) object contains the a public key that a zone owner
   would like its superordinate to delegate to in the future.  It is
   represented as an 5-element array The second element is a signature
   algorithm identifier as in Section 5.13.  The third element is the
   public key, as defined in Section 5.13 for the given algorithm
   identifier.  The fourth element is the requested-valid-since time,
   and the fifth element is the requested-valid-until time, formatted as
   for signatures as in Section 5.13.  See Section 10.3 for more.

5.11.1.  Certificate information format

   A cert-info object contains information about the certificate(s) that
   can be used to authenticate a transport-layer association with a
   named entity.  It is encoded as a file-element array.  The first
   element is the RAINS object type (7).  The second element is the
   protocol family specifier, describing the cryptographic protocol used
   to connect, as defined in Table 6.  The protocol family defines the
   format of certificate data to be hashed.  The third element is the
   certificate usage specifier as in Table 7, describing the constraint
   imposed by the assertion.  These are defined to be compatible with
   Certificate Usages in the TLSA RRTYPE for DANE [RFC6698].  The fourth
   element is the hash algorithm identifier, defining the hash algorithm
   used to generate the certificate data.  The fifth item is the data
   itself, whose format is defined by the protocol family and hash
   algorithm.








Trammell                 Expires March 24, 2018                [Page 27]


Internet-Draft                    RAINS                   September 2017


   +------+--------+---------------------------------+-----------------+
   | Code | Name   | Protocol family                 | Certificate     |
   |      |        |                                 | format          |
   +------+--------+---------------------------------+-----------------+
   |    0 | unspec | Unspecified                     | Unspecified     |
   |      |        |                                 |                 |
   |    1 | tls    | Transport Layer Security (TLS)  | [RFC5280]       |
   |      |        | [RFC5246]                       |                 |
   +------+--------+---------------------------------+-----------------+

            Table 6: Certificate information protocol families

   Protocol family 0 leaves the protocol family unspecified; client
   validation and usage of cert-info assertions, and the protocol used
   to connect, are up to the client, and no information is stored in
   RAINS.  Protocol family 1 specifies Transport Layer Security version
   1.2 [RFC5246] or a subsequent version, secured with PKIX [RFC5280]
   certificates.

                +------+------+--------------------------+
                | Code | Name | Certificate usage        |
                +------+------+--------------------------+
                |    2 | ta   | Trust Anchor Certificate |
                |      |      |                          |
                |    3 | ee   | End-Entity Certificate   |
                +------+------+--------------------------+

               Table 7: Certificate information usage values

   A trust anchor certificate constraint specifies a certificate that
   MUST appear as the trust anchor for the certificate presented by the
   subject of the assertion on a connection attempt.  An end-entity
   certificate constraint specifies a certificate that MUST be presented
   by the subject of the assertion on a connection attempt.

        +------+---------+---------------------------------------+
        | Code | Name    | Notes                                 |
        +------+---------+---------------------------------------+
        |    0 | full    | Data contains full certificate        |
        |      |         |                                       |
        |    1 | sha-256 | Data contains SHA-256 hash (32 bytes) |
        |      |         |                                       |
        |    2 | sha-512 | Data contains SHA-512 hash (64 bytes) |
        |      |         |                                       |
        |    3 | sha-384 | Data contains SHA-384 hash (48 bytes) |
        +------+---------+---------------------------------------+

             Table 8: Certificate information hash algorithms



Trammell                 Expires March 24, 2018                [Page 28]


Internet-Draft                    RAINS                   September 2017


   Code 0 is used to store full certificates in RAINS assertions, while
   other codes are used to store hashes for verification.

   For example, in a cert-info object with values [ 7, 1, 3, 3, (data)
   ], the data would be a 48 SHA-384 hash of the ASN.1 DER-encoded
   X.509v3 certificate (see Section 4.1 of [RFC5280]) to be presented by
   the endpoint on a connection attempt with TLS version 1.2 or later.

5.11.2.  Name expression format

   The nameset expression is represented as a UTF-8 string encoding a
   modified POSIX Extended Regular Expression format (see POSIX.2) to be
   applied to each element of a name within the zone.  A name containing
   an element that does not match the valid nameset expression for a
   zone is not valid within the zone, and the nameset assertion can be
   used to prove nonexistence.

   The POSIX character classes :alnum:, :alpha:, :ascii:, :digit:,
   :lower:, and :upper: are available in these regular expressions,
   where:

   o  :lower: matches all codepoints within the Unicode general category
      "Letter, lowercase"

   o  :upper: matches all codepoints within the Unicode general category
      "Letter, uppercase"

   o  :alpha: matches all codepoints within the Unicode general category
      "Letter".

   o  :digit: matches all codepoints within the Unicode general category
      "Number, decimal digit"

   o  :alnum: is the union of :alpha: and :digit:

   o  :ascii: matches all codepoints in the range 0x20-0x7f

   In addition, each Unicode block is available as a character class,
   with the syntax :ublkXXXX: where XXXX is a 4 or 5 digit, zero-
   prefixed hex encoding of the first codepoint in the block.  For
   example, the Cyrillic block is available as :ublk0400:.

   Unicode escapes are supported in these regular expressions; the
   sequence \uXXXX where XXXX is a 4 or 5 digit, possibly zero-prefixed
   hex encoding of the codepoint, is substituted with that codepoint.

   Set operations (intersection and subtraction) are available on
   character classes.  Two character class or range expressions in a



Trammell                 Expires March 24, 2018                [Page 29]


Internet-Draft                    RAINS                   September 2017


   bracket expression joined by the sequence && are equivalent to the
   intersection of the two character classes or ranges.  Two character
   class or range expressions in a bracket expression joined by the
   sequence - are equivalent to the subtraction of the second character
   class or range from the first.

   For example, the nameset expression:

   [[:ublk0400:]&&[:lower:][:digit:]]+

   matches any name made up of one or more lowercase Cyrillic letters
   and digits.  The same expression can be implemented with a range
   instead of a character class:

   [\u0400-\u04ff&&[:lower:][:digit:]]+

5.12.  Tokens in queries and messages

   Messages and notifications contain an opaque token (2) key, whose
   content is a 16-byte array, and is used to link Messages to the
   Queries they respond to, and Notifications to the Messages they
   respond to.  Tokens MUST be treated as opaque values by RAINS
   servers.

   A Message sent in response to a Query MUST contain the token of the
   Message containing the Query.  Otherwise, the Message MUST contain a
   token selected by the server originating it, so that future
   Notifications can be linked to the Message causing it.  Likewise, a
   Notification sent in response to a Message MUST contain the token
   from the Message causing it (where the new Message contains a fresh
   token selected by the server).  This allows sending multiple
   Notifications within one Message and the receiving server to respond
   to a Message containing Notifications (e.g. when it is malformed).

   Since tokens are used to link queries to replies, and to link
   notifications to messages, regardless of the sender or recipient of a
   message, they MUST be chosen by servers to be hard to guess; e.g.
   generated by a cryptographic random number generator.

   When a server creates a new query to forward to another server in
   response to a query it received, it MUST NOT use the same token on
   the delegated query as on the received query, unless option 6 Enable
   Tracing is present in the received, in which case it MUST use the
   same token.







Trammell                 Expires March 24, 2018                [Page 30]


Internet-Draft                    RAINS                   September 2017


5.13.  Signatures, delegation keys, and RAINS infrastructure keys

   RAINS supports multiple signature algorithms and hash functions for
   signing assertions for cryptographic algorithm agility [RFC7696].  A
   RAINS signature algorithm identifier specifies the signature
   algorithm; a hash function for generating the HMAC and the format of
   the encodings of the signature values in Assertions, Shards, Zones,
   and Messages, as well as of public key values in delegation objects.

   RAINS signatures have five common elements: the algorithm identifier,
   a keyspace identifier, a keyphase identifier, a valid-since
   timestamp, and a valid-until timestamp.  Signatures are represented
   as an array of these five values followed by additional elements
   containing the signature data itself, according to the algorithm
   identifier.

   The following algorithms are supported:

         +--------+------------+-----------+--------------------+
         | Alg ID | Signatures | Hash/HMAC | Format             |
         +--------+------------+-----------+--------------------+
         |      1 | ed25519    | sha-512   | See Section 5.13.1 |
         |        |            |           |                    |
         |      2 | ed448      | shake256  | See Section 5.13.1 |
         |        |            |           |                    |
         |      3 | ecdsa-256  | sha-256   | See Section 5.13.2 |
         |        |            |           |                    |
         |      4 | ecdsa-384  | sha-384   | See Section 5.13.2 |
         +--------+------------+-----------+--------------------+

                   Table 9: Defined signature algorithms

   As noted in Section 5.13.1, support for Algorithm 1, ed25519, is
   REQUIRED; other algorithms are OPTIONAL.

   The keyspace identifier associates the signature with a method for
   verifying signatures.  This facility is used to support signatures on
   assertions from external sources (the extrakey object type).  At
   present, one keyspace identifier is defined, and support for it is
   REQUIRED.

    +-------------+-------+------------------------------------------+
    | Keyspace ID | Name  | Signature Verification Algorithm         |
    +-------------+-------+------------------------------------------+
    |           0 | rains | RAINS delegation chain; see Section 5.13 |
    +-------------+-------+------------------------------------------+





Trammell                 Expires March 24, 2018                [Page 31]


Internet-Draft                    RAINS                   September 2017


   Within the RAINS delegation chain keyspace, the key phase is an
   unbounded, unsigned integer matching a signature's key phase to the
   delegation key phase.  Multiple keys may be valid for a delegation at
   a given point in time, in order to support seamless rollover of keys,
   but only one per key phase and algorithm may be valid at once.  The
   third element of delegation objects and signatures is the key phase.

   Valid-since and valid-until timestamps are represented as CBOR
   integers counting seconds since the UNIX epoch UTC, identified with
   tag value 1 and encoded as in section 2.4.1 of [RFC7049].  A
   signature MUST have a valid-until timestamp.  If a signature has no
   specified valid-since time (i.e., is valid from the beginning of time
   until its valid-until timestamp), the valid-since time MAY be null
   (as in Table 2 in Section 2.3 of [RFC7049]).

   A signature in RAINS is generated over a byte stream representing the
   message in a canonical signing format.  The signing process is
   defined as follows:

   o  Parse the object to be signed into a byte stream according to the
      format specified in Section 6.

   o  Generate a signature on the resulting byte stream according to the
      algorithm selected.

   o  Add the full signature to the signatures array at the appropriate
      point in the object.

   To verify a signature, generate the byte stream as for signing, then
   verify the signature according to the algorithm selected.

5.13.1.  EdDSA signature and public key format

   EdDSA public keys consist of a single value, a 32-byte bit string
   generated as in Section 5.1.5 of [RFC8032] for Ed25519, and a 57-byte
   bit string generated as in Section 5.2.5 of [RFC8032] for Ed448.  The
   fourth element in a RAINS delegation object is this bit string
   encoded as a CBOR byte array.  RAINS delegation objects for Ed25519
   keys with value k are therefore represented by the array [5, 1,
   phase, k]; and for Ed448 keys as [5, 2, phase, k].

   Ed25519 and Ed448 signatures are are a combination of two non-
   negative integers, called "R" and "S" in sections 5.1.6 and 5.2.6,
   respectively, of [RFC8032].  An Ed25519 signature is represented as a
   64-byte array containing the concatenation of R and S, and an Ed448
   signature is represented as a 114-byte array containing the
   concatenation of R and S.  RAINS signatures using Ed25519 are




Trammell                 Expires March 24, 2018                [Page 32]


Internet-Draft                    RAINS                   September 2017


   therefore the array [1, 0, phase, valid-since, valid-until, R|S];
   using Ed448 the array [2, 0, phase, valid-since, valid-until, R|S].

   Ed25519 keys are generated as in Section 5.1.5 of [RFC8032], and
   Ed448 keys as in Section 5.2.5 of [RFC8032].  Ed25519 signatures are
   generated from a normalized serialized CBOR object as in
   Section 5.1.6 of [RFC8032], and Ed448 signatures as in section 5.2.6
   of [RFC8032].

   RAINS Server and Client implementations MUST support Ed25519
   signatures for delegation.

5.13.2.  ECDSA signature and public key format

   ECDSA public keys consist of a single value, called "Q" in
   [FIPS-186-3].  Q is a simple bit string that represents the
   uncompressed form of a curve point, concatenated together as "x | y".
   The fourth element in a RAINS delegation object is the Q bit string
   encoded as a CBOR byte array.  RAINS delegation objects for ECDSA-256
   public keys are therefore represented as the array [5, 3, phase, Q];
   and for ECDSA-384 public keys as [5, 4, phase, Q].

   ECDSA signatures are a combination of two non-negative integers,
   called "r" and "s" in [FIPS-186-3].  A Signature using ECDSA is
   represented using a four-element CBOR array, with the fourth element
   being "r | s" such that r is represented as a byte array as described
   in Section C.2 of [FIPS-186-3], and s represented as a byte array as
   described in Section C.2 of [FIPS-186-3].  For ECDSA-256 signatures,
   each integer MUST be represented as a 32-byte array.  For ECDSA-384
   signatures, each integer MUST be represented as a 48-byte array.
   RAINS signatures using ECDSA-256 are therefore the array [3, 0,
   phase, valid-since, valid-until, r|s]; and for ECDSA-384 the array
   [4, 0, phase, valid-since, valid-until, r|s].

   ECDSA-256 signatures and public keys use the P-256 curve as defined
   in [FIPS-186-3].  ECDSA-384 signatures and public keys use the P-384
   curve as defined in [FIPS-186-3].

   ECDSA-256 and ECDSA-384 support are primarily meant for compatibility
   with and migration from existing DNSSEC deployments; see
   Section 10.6.

5.14.  Capabilities

   When a RAINS server or client sends the first message in a stream to
   a peer, it MAY expose optional capabilities to its peer using the
   capabilities (1) key.  This key contains either:




Trammell                 Expires March 24, 2018                [Page 33]


Internet-Draft                    RAINS                   September 2017


   o  an array of uniform resource names specifying capabilities
      supported by the sending server, taken from the table below, with
      each name encoded as a UTF-8 string.

   o  a SHA-256 hash of the CBOR byte stream derived from normalizing
      such an array by sorting it in lexicographically increasing order,
      then serializing it.

   This mechanism is inspired by [XEP0115], and is intended to be used
   to reduce the overhead in exposing common sets of capabilities.  Each
   RAINS server can cache a set of recently-seen or common hashes, and
   only request the full URN set (using notification code 399) on a
   cache miss.

   The following URNs are presently defined; other URNs will specify
   future optional features, support for alternate transport protocols
   and new signature algorithms, etc.

   +--------------------+----------------------------------------------+
   | URN                | Meaning                                      |
   +--------------------+----------------------------------------------+
   | urn:x-rains:tlssrv | Listens for connections on TLS over TCP from |
   |                    | other RAINS servers.                         |
   +--------------------+----------------------------------------------+

   Since there are only two defined capabilities at this time, RAINS
   servers can be implemented with two hard-coded hashes to determine
   whether a peer is listening or not.  The hash presented by a server
   supporting urn:x-rains:tlssrv is
   e5365a09be554ae55b855f15264dbc837b04f5831daeb321359e18cdabab5745; the
   hash presented by a server supporting no capabilities is
   76be8b528d0075f7aae98d6fa57a6d3c83ae480a8469e668d7b0af968995ac71.

   Servers MAY piggyback capability negotiation on other messages, or
   use dedicated messages for capability negotiation.

   A RAINS server MUST NOT assume that a peer server supports a given
   capability unless it has received a message containing that
   capability from that server.  An exception are the capabilities
   indicating that a server listens for connections using a given
   transport protocol; servers and clients can also learn this
   information from RAINS itself (given a redirection assertion for a
   named zone) or from external configuration values.








Trammell                 Expires March 24, 2018                [Page 34]


Internet-Draft                    RAINS                   September 2017


6.  Canonical signing format

   [EDITOR'S NOTE: to define, based on CBOR canonicalization, once this
   is implemented.]

7.  RAINS Protocol Definition

   As noted in Section 5, RAINS is a message-exchange protocol that uses
   CBOR [RFC7049] as its framing.  Since CBOR is self-framing - a CBOR
   parser can determine when a CBOR object is complete at the point at
   which it has read its final byte - RAINS requires no external
   framing.  It can therefore run over any streaming, multistreaming, or
   message-oriented transport protocol.  In order to protect query
   confidentiality, and support rapid deployment over a ubiquitously
   implemented transport, RAINS is defined in this document to run over
   persistent TLS 1.2 connections [RFC5246] over TCP [RFC0793] with
   mutual authentication between servers, and authentication of servers
   by clients.  The TLS certificates of RAINS server peers can be
   verified as specified in the cert-info assertions for those servers.

   RAINS servers MUST support this transport; future transports can be
   negotiated using the capabilities mechanism after bootstrapping using
   TLS 1.2.  As RAINS is an experimental protocol, RAINS servers listen
   on port 1022 [RFC4727] for connections from other RAINS servers and
   clients.  RAINS servers should strive to keep connections open to
   peer servers, unless it is clear that no future messages will be
   exchanged with those peers, or in the face of resource limitations at
   either peer.  If a RAINS server needs to send a message to another
   RAINS server to which it does not have an open connection, it
   attempts to open a connection with that server.

   This section describes the operation of the protocol as used among
   RAINS servers.  A simplified version of the protocol for client
   access is described in Section 8, and a simplified version of the
   protocol for publication by authorities is described in Section 9.

7.1.  Message processing

   Once a transport is established, any server may validly send a
   message with any content to any other server.  A client may send
   messages containing queries to servers, and a server may sent
   messages containing anything other than queries to clients.

   Upon receipt of a message, a server or client attempts to parse it.

   If the server or client cannot parse the message at all, it returns a
   400 Bad Message notification to the peer.  This notification may have
   a null token if the token cannot be retrieved from the message.



Trammell                 Expires March 24, 2018                [Page 35]


Internet-Draft                    RAINS                   September 2017


   If the server or client can parse the message, it:

   o  notes the token on the message.  This token MUST be present on any
      messages sent in reply to this message.

   o  processes any capabilities present, replacing the set of
      capabilities known for the peer with the set present in the
      message.  If the present capabilities are represented by a hash
      that the server does not have in its cache, it prepares a
      notification of type 399 "Capability hash not understood" to send
      to its peer.

   o  splits the contents into its constituent message sections, and
      verifies that each is acceptable.  Specifically, queries are not
      accepted by clients (see Section 8), and 404 No Assertion Exists
      notifications are not accepted by servers.  If a message contains
      an unacceptable section, the server or client returns a 400 Bad
      Message notification to its peer, and ceases processing of the
      message.

   On receipt of an assertion, shard, or zone message section, a server:

   o  verifies its consistency (see Section 7.4).  If the section is not
      consistent, it prepares to send a notification of type 403
      Inconsistent Message to the peer, and discards the section.
      Otherwise, it:

   o  determines whether it answers an outstanding query; if so, it
      prepares to forward the section to the server that issued the
      query.

   o  determines whether it is likely to answer a future query,
      according to its configuration, policy, and query history; if so,
      it caches the section.

   On receipt of an assertion, shard, or zone message section, a client:

   o  determines whether it answers an outstanding query; if so, it
      considers the query answered.  It then:

   o  determines whether it is likely to answer a future query,
      according to its configuration, policy, and query history; if so,
      it caches the section.

   On receipt of a query, a server:

   o  determines whether it has expired by checking the query-expires
      value.  If so, it drops the query silently.  If not, it:



Trammell                 Expires March 24, 2018                [Page 36]


Internet-Draft                    RAINS                   September 2017


   o  determines whether it has a stored assertion, shard, and/or zone
      message section which answers the query.  If so, it prepares to
      return the most specific such section (i.e., if it has both a
      shard and an assertion that would answer the query, it returns the
      assertion) with the signature of the longest remaining validity to
      the peer that issued the query.  If not, it:

   o  checks to see whether the query specifies option 4 (cached answers
      only).  If so, and if option 5 (expired assertions acceptable) is
      also specified, it then checks to see if it has any cached
      sections that answer the query on which signatures are expired;
      otherwise, processing stops, and the server returns a 504 No
      Assertion Available notification, as if the query had instantly
      expired.. If the query does not specify option 4, delegation
      proceeds, and the server:

   o  determines whether it has other non-authoritative servers it can
      forward the query to, according to its configuration and policy,
      and in compliance with any query options (see Section 5.7).  If
      so, it prepares to forward the query to those servers, noting the
      reply for the received query depends on the replies for the
      forwarded query.  If not, it:

   o  determines the responsible authority servers for the zone
      containing the query name in the query for the context requested,
      and forwards the query to those authority servers, noting the
      reply for the received query depends on the reply for the
      forwarded query.

   If query delegation fails to return an answer within the maximum of
   the valid-until time in the received query and a configured maximum
   timeout for a delegated query, the server prepares to send a 504 No
   assertion available response to the peer from which it received the
   query.

   When a server creates a new query to forward to another server in
   response to a query it received, it SHOULD NOT use the same token on
   the delegated query as on the received query, unless option 6 Enable
   Tracing is present in the received, in which case it MUST use the
   same token.  The Enable Tracing option is designed to allow debugging
   of query processing across multiple servers, It SHOULD only be
   enabled by clients designed explicitly for debugging RAINS itself,
   and MUST NOT be enabled by default by client resolvers.

   When a server creates a new query to forward to another server in
   response to a query it received, and the received query contains a
   query-expires time, the delegated query MUST NOT have a query-expires
   time after that in the received query.  If the received query



Trammell                 Expires March 24, 2018                [Page 37]


Internet-Draft                    RAINS                   September 2017


   contains no query-expires time, the delegated query MAY contain a
   query- expires time of the server's choosing, according to its
   configuration.

   On receipt of a notification, a server's behavior depends on the
   notification type:

   o  For type 100 "Connection Heartbeat", the server does nothing:
      these null messages are used to keep long-lived connections open
      in the presence of network behaviors that may drop state for idle
      connections.

   o  For type 399 "Capability hash not understood", the server prepares
      to send a full capabilities list on the next message it sends to
      the peer.

   o  For type 504 "No assertion available", the server checks the token
      on the message, and prepares to forward the assertion to the
      associated query.

   o  For type 413 "Message too large" the server notes that large
      messages may not be sent to a peer and tries again (see
      Section 7.3), or logs the error along with the note-data content.

   o  For type 400 "Bad message", type 403 "Inconsistent message", type
      500 "Server error", or type 501 "Server not capable", the server
      logs the error along with the note-data content, as these
      notifications generally represent implementation or configuration
      error conditions which will require human intervention to
      mitigate.

   On receipt of a notification, a client's behavior depends on the
   notification type:

   o  For type 100 "Connection Heartbeat", the client does nothing, as
      above.

   o  For type 399 "Capability hash not understood", the client prepares
      to send a full capabilities list on the next message it sends to
      the peer.

   o  For type 404 "No assertion exists", the client takes the query to
      be unanswerable.  It may reissue the query with query option 7 to
      do the verification of nonexistence again, if the server from
      which it received the notification is untrusted.






Trammell                 Expires March 24, 2018                [Page 38]


Internet-Draft                    RAINS                   September 2017


   o  For type 413 "Message too large" the client notes that large
      messages may not be sent to a peer and tries again (see
      Section 7.3), or logs the error along with the note-data content.

   o  For type 400 "Bad message", type 403 "Inconsistent message", type
      500 "Server error", or type 501 "Server not capable", the client
      logs the error along with the note-data content, as these
      notifications generally represent implementation or configuration
      error conditions which will require human intervention to
      mitigate.

   The first message a server or client sends to a peer after a new
   connection is established SHOULD contain a capabilities section, if
   the server or client supports any optional capabilities.  See
   Section 5.14.

   If the server is configured to keep long-running connections open,
   due to the presence of network behaviors that may drop state for idle
   connections, it SHOULD send a message containing a type 100
   Connection Heartbeat notification after a configured idle time
   without any messages containing other content being sent.

   In general, servers should follow the principles laid out in Sections
   4.1 and 4.2 of [I-D.thomson-postel-was-wrong].  A malformed message
   section, or a message section with any invalid (but not expired)
   signature, should be dropped and log.  A malformed message section or
   invalid signature should not, however, result in other sections in
   the same message being dropped, except as explicitly noted above.

7.2.  Message Transmission

   As noted in Section 7.1 many messages are sent in reply to messages
   received from peers.  Servers may also originate messages on their
   own, based on their configuration and policy:

   o  Proactive queries to retrieve assertions, shards, and zones for
      which all signatures have expired or will soon expire, for cache
      management purposes.

   o  Proactive push of assertions, shards, and zones to other servers,
      based on query history or other information indicating those
      servers may query for the assertions they contain.

7.3.  Message Limits

   RAINS servers MUST accept messages up to 65536 bytes in length, but
   MAY accept messages of greater length, subject to resource
   limitations of the server.  A server with resource limitations MUST



Trammell                 Expires March 24, 2018                [Page 39]


Internet-Draft                    RAINS                   September 2017


   respond to a message rejected due to length restrictions with a
   notification of type 413 (Message Too Large).  A server that receives
   a type 413 notification must note that the peer sending the message
   only accepts messages smaller than the largest message it's
   successfully sent that peer, or cap messages to that peer to 65536
   bytes in length.

   Since a bare assertion with a single Ed25519 signature requires on
   the order of 180 bytes, it is clear that many full zones won't fit
   into a single minimum maximum-size message.  Authorities are
   therefore encouraged to publish zones grouped into shards that will
   fit into 65536-byte messages, to allow servers to reply using these
   shards when full-zone transfers are not possible due to message size
   limitations.

7.4.  Runtime Consistency Checking

   The data model used by the RAINS protocol allows inconsistent
   information to be asserted, all resulting from misconfigured or
   misbehaving authority servers.  The following types of inconsistency
   are possible:

   o  A shard omits an assertion within its shard-range which is valid
      at the same time as the shard.

   o  A zone omits an assertion within its zone which is valid at the
      same time as the zone.

   o  An address assertion contains an object that is not allowed (see
      Section 5.8)

   o  An assertion prohibited by its zone's nameset is valid at the same
      time as the zone's nameset assertion.

   o  A zone contains a valid reflexive assertion of a given object type
      at the same time that its superordinate zone contains a valid
      assertion of the same type.

   o  Delegations to more than one key are simultaneously valid for a
      given context, zone, signature algorithm, and key phase.

   RAINS relies on runtime consistency checking to mitigate
   inconsistency: each server receiving an assertion, shard, or zone
   SHOULD, subject to resource constraints, ensure that it is consistent
   with other information it has, and if not, discard all assertions,
   shards, and zones in its cache, log the error, and send a 403
   Inconsistent Message to the source of the message.




Trammell                 Expires March 24, 2018                [Page 40]


Internet-Draft                    RAINS                   September 2017


7.5.  Integrity and Confidentiality Protection

   Assertions are not valid unless they contain at least one signature
   that can be verified from the chain of authorities specified by the
   name and context on the assertion; integrity protection is built into
   the information model.  The infrastructure key object type allows
   keys to be associated with RAINS servers in addition to zone
   authorities, which allows a client to delegate integrity verification
   of assertions to a trusted query service (see Section 8).

   Since the job of an Internet naming service is to provide publicly-
   available information mapping names to information needed to connect
   to the services they name, confidentiality protection for assertions
   is not a goal of the system.  Specifically, the information model and
   the mechanism for proving non-existence of an assertion is not
   designed to provide resistance against zone enumeration.

   On the other hand, confidentiality protection of query information in
   crucial.  Linking naming queries to a specific user can be nearly as
   useful to build a profile of that user for surveillance purposes as
   full access to the clear text of that client's communications
   [RFC7624].  In this revision, RAINS uses TLS to protect
   communications between servers and between servers and clients, with
   certificate information for RAINS infrastructure stored in RAINS
   itself.  Together with hop-by-hop confidentiality protection, query
   options, proactive caching, default use of non-persistent tokens, and
   redirection among servers can be used to mix queries and reduce the
   linkability of query information to specific clients.

7.6.  Cooperative Delegation Distribution

   Regardless of any other configuration directive, a RAINS server MUST
   be prepared to provide a full chain of delegation assertions from the
   appropriate delegation root to the signature on any assertion it
   gives to a peer or a client, whether as additional assertions on a
   message answering a query, or in reply to a subsequent query.  This
   property allows RAINS servers to maintain a full delegation tree

8.  RAINS Client Protocol

   The protocol used by clients to issue queries to and receive
   responses from an query service is a subset of the full RAINS
   protocol, with the following differences:

   o  Clients only process assertion, shard, zone, and notification
      sections; sending a query to a client results in a 400 Bad Message
      notification.




Trammell                 Expires March 24, 2018                [Page 41]


Internet-Draft                    RAINS                   September 2017


   o  Clients never listen for connections; a client must initiate and
      maintain a transport session to the query server(s) it uses for
      name resolution.

   o  Servers only process query and notification sections when
      connected to clients; a client sending assertions to a server
      results in a 400 Bad Message notification.

   Since signature verification is resource-intensive, clients delegate
   signature verification to query servers by default.  The query server
   signs the message containing results for a query using its own key
   (published as an infrakey object associated with the query server's
   name), and a validity time corresponding to the signature it verified
   with the longest lifetime, stripping other signatures from the reply.
   This behavior can be disabled by a client by specifying query option
   7, allowing the client to do its own verification.

9.  RAINS Publication Protocol

   The protocol used by authorities to publish assertions to an
   authority service is a subset of the full RAINS protocol, with the
   following differences:

   o  Servers only process assertion, shard, zone, and notification
      sections when connected to publishers; sending a query to a server
      via the publication procotol results in a 400 Bad Message
      notification.  Servers only process notifications for capability
      negotiation purposes (see Section 5.14).

   o  Publishers only process notification sections; sending a query or
      assertion to a publisher results in a 400 Bad Message
      notification.

10.  Deployment Considerations

   The following subsections discuss issues that must be considered in
   any deployment of RAINS at scale.

10.1.  Assertion Lifetime Management

   An assertion can contain multiple signatures, each with a different
   lifetime.  Signature lifetimes are equivalent to a time to live in
   the present DNS: authorities should compute a new signature for each
   validity period, and make these new signatures available when old
   ones are expiring.






Trammell                 Expires March 24, 2018                [Page 42]


Internet-Draft                    RAINS                   September 2017


   Since assertion lifetime management is based on a real-time clock
   expressed in UTC, RAINS servers MUST use a clock synchronization
   protocol such as NTP [RFC5905].

   RAINS servers MAY coalesce assertion lifetimes, e.g. using only the
   most recent valid-until time in their cache management.  This implies
   that an assertion with valid signatures in time intervals (T1, T2)
   and (T3, T4) such that T3 > T2 may be cached during the interval (T2,
   T3) as well.  Authorites MUST NOT rely on non-caching or non-
   availability of assertions during such intervals.

10.2.  Secret Key Management

   The secret keys associated with public keys for each RAINS server
   (via infrakey objects) must be available on that server, whether
   through a hardware or software security device, so they can sign
   messages on demand; this is particularly important for query servers.
   In addition, the secret keys associated with TLS certificates for
   each server (published via certinfo objects) must be available as
   well in order to establish TLS sessions.

   However, storing zone secret keys (associated via delegation objects)
   on RAINS servers would represent a more serious operational risk.  To
   keep this from being necessary, authority servers have an additional
   signer interface, from which they will accept and cache any
   assertion, shard, or zone for which they are authority servers until
   at least the end of validity of the last signature, provided the
   signature is verifiable.

10.3.  Public Key Management

   As signature lifetime is used to manage assertion lifetime, and key
   rotation strategies may be used both for revocation as well as
   operational flexibility purposes, RAINS presents a much more dynamic
   key management environment than that presented by DNSSEC.

10.3.1.  Key Phase and Key Rotation

   Each signature and public key in a RAINS message is associated with a
   key phase, allowing multiple keys to be valid for a given authority
   at any given time.  For example, given two key phases and a key
   validity interval of one day, a phase 0 key would be valid from 00:00
   on day 0 to 00:00 on day 1, and a phase 1 key valid from 12:00 on day
   0 to 12:00 on day 1.  When the phase 0 key expires, it would be
   replaced by a new phase 0 valid from 00:00 on day 1 to 00:00 on day
   2, and so on.





Trammell                 Expires March 24, 2018                [Page 43]


Internet-Draft                    RAINS                   September 2017


   Since the end time of the validity of a signature on an assertion is
   the maximum of the validity of the signatures on each of the
   delegations in the delegation chain from the root, key rotation
   avoids mass expiration of assertions, at the cost of requiring one
   valid signatures per key phase on at least all delegation assertions.
   Key rotation schedules are a matter of authority operational policy,
   but key validity intervals should be longer the closer in the
   delegation chain an assertion is to the root.

10.3.2.  Next Key Assertions

   Another problem this dyanmic envrionment raises is how a zone
   authority communicates to its superordinate that it would like to
   begin using a new public key to sign its assertions.

   This can be done out of band, using private APIs provided by the
   superordinate authority.  Through the nextkey object type, RAINS
   provides a way for a future public key to be shared with the
   superordinate authority (and all other queriers) in-band.  An
   authority that wishes to use a new key publishes a reflexive nextkey
   assertion (i.e., in its own zone, with subject @) with the new public
   key and a requested valid-since and valid-until time range.  The
   superordinate issues periodic queries for nextkey assertions from its
   subordinate zone, or the subordinate pushes these assertions to an
   intermediate service designated to receive them.  When the
   superordinate receives a nextkey, and it decides it wants to delegate
   to the new key, it creates and signs a delegation assertion.

   This process is not mandatory: the superordinate is free to ignore
   the request, or to use a different time range, depending on its
   policy and/or the status of its business relationship with the
   subordinate.  The subordinate can discover this, in turn, using its
   own RAINS queries, or through the delegation assertions being
   similarly pushed to a designated intermediate service.

10.4.  Unsigned Contained Assertions

   Although RAINS supports Shards and Zones containing unsigned
   assertions, protecting the integrity of those Assertions by the
   signature on the Shard or Zone, it is RECOMMENDED that authorities
   sign each Assertion, even those contained within a Shard or Zone, in
   order to minimize the size of positive answers to queries.

10.5.  Query Service Discovery

   A client that will not do its own verification must be able to
   discover the query server(s) it should trust for resolution.
   Integration with DHCP is left to a future revision of this document.



Trammell                 Expires March 24, 2018                [Page 44]


Internet-Draft                    RAINS                   September 2017


   In any case, clients MUST provide a configuration interface to allow
   a user to specify (by address or name) and/or constrain (by
   certificate property) a preferred/trusted query server.  This would
   allow client on an untrusted network to use an untrusted locally-
   available query server to discover a preferred query server (doing
   key verification on its own for bootstrapping), before connecting to
   that query server for normal name resolution.

10.6.  Transition using translation between RAINS and DNS information
       models

   Full adoption of RAINS would require changes to every client device
   (replacing DNS stub resolvers with RAINS clients) and name server on
   the Internet.  In addition, most client software would need to
   change, as well, to get the full benefits of explicit context in name
   resolution.  This is an unrealistic goal.

   RAINS servers can, however, coexist with Domain Name System servers
   and clients during an indefinite transition period.  RAINS assertions
   can be algorithmically translated into DNS answers, and RAINS queries
   can be algorithmically translated into DNS queries, by RAINS to DNS
   gateways, given the mostly compatible information models used by the
   two.

   While DNSSEC and RAINS keys for equivalent ciphersuites are
   compatible with each other, there is no equivalent to query option 7
   for gateways, since the RAINS signatures are generated over the RAINS
   byte stream for an assertion, not the DNS byte stream.  Therefore,
   RAINS to DNS gateways must provide verification services for DNS
   clients.  DNS over TLS [RFC7858] SHOULD be used between the DNS
   client and gateway to ensure confidentiality and integrity for
   queries and answers.

   Object type mappings are as follows:

   o  Objects of type name can (largely) be represented as CNAME RRs.

   o  Objects of type ip6-addr can be represented as AAAA RRs.

   o  Objects of type ip4-addr can be represented as A RRs.

   o  Objects of type redirection can be represented as NS RRs.

   o  Objects of type cert-info can be represented as TLSA RRs

   o  Objects of type service-info can be represented as SRV RRs.

   There are a few object types without mappings:



Trammell                 Expires March 24, 2018                [Page 45]


Internet-Draft                    RAINS                   September 2017


   o  Objects of type delegation can be represented as DS RRs, and
      signatures as RRSIG RRs, but since these keys are verified by the
      gateway, there is no need to represent this information to the
      client.

   o  Objects of type infrakey cannot be represented in DNS, but are
      irrelevant for DNS translation of RAINS messages, since DNS does
      not support server signing of responses.

   o  Objects of type registrar and registrant cannot be represented in
      DNS; clients can use WHOIS instead.  In addition, RRTYPEs could be
      added for them in the future if RAINS sees significant deployment
      with DNS as a front-end protocol.

   o  Objects of type nameset cannot be represented in DNS; the current
      equivalent are the IDNA parameters maintained by IANA (for the DNS
      root zone only) at https://www.iana.org/assignments/idna-tables-
      6.3.0/idna-tables-6.3.0.xhtml.

   When translating a DNS query from a client to a RAINS query for that
   client, client options can be set on a per-server, per-client, or
   per-query basis using some out of band configuration options.

   When translating a RAINS assertion to a DNS answer, the gateway can
   use the time to expiry for the verified signature as the TTL.

   There is no method for exposing context information in a DNS query or
   answer.  Therefore, queries and answers at a RAINS gateway are only
   supported for the global context ".".

11.  Experimental Design and Evaluation

   The protocol described in this document is intended primarily as a
   prototype for discussion, though the goal of the document is to
   specify RAINS completely enough to allow independent, interoperable
   implementation of clients an servers.  The massive inertia behind the
   deployment of the present domain name system makes full deployment as
   a replacement for DNS unlikely.  Despite this, there are some
   criteria by which the success of the RAINS experiment may be judged:

   First, deployment in simulated or closed networks, or in alternate
   Internet architectures such as SCION, allows implementation
   experience with the features of RAINS which DNS lacks (signatures as
   a first-order delegation primitive, support for explicit contexts,
   explicit tradeoffs in queries, runtime availability of registrar/
   registrant data, and nameset support), which in turn may inform the
   specification and deployment of these features on the present DNS.




Trammell                 Expires March 24, 2018                [Page 46]


Internet-Draft                    RAINS                   September 2017


   Second, deployment of RAINS "islands" in the present Internet
   alongside DNS on a per-domain basis would allow for comparison
   between operational and implementation complexity and efficiency and
   benefits derived from RAINS' features, as information for future
   development of the DNS protocol.

12.  IANA Considerations

   The present revision of this document has no actions for IANA.

   The authors have registered the CBOR tag 15309736 to identify RAINS
   messages in the CBOR tag registry at
   https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml.

   RAINS servers currently listen for connections from other servers on
   Port 1022.  Future revisions of this document may specify a different
   port, registered with IANA via Expert Review [RFC5226].

   The symbol table in this document in Section 5.1, the notification
   code table in Section 5.10, and the signature algorithm table in
   Section 5.13 may be candidates for IANA registries in future
   revisions of this document.

   The urn:x-rains namespace used by the RAINS capability mechanism in
   Section 5.14 may be a candidate for replacement with an IANA-
   registered namespace in a future revision of this document.

13.  Security Considerations

   This document specifies a new, experimental protocol for Internet
   name resolution, with mandatory integrity protection for assertions
   about names built into the information model, and confidentiality for
   query information protected on a hop-by-hop basis.  See especially
   Section 4.1.2, Section 7.5, Section 5.13, Section 5.11.1, and
   Section 10.2 for security-relevant details.

   With respect to the resistance of the protocol itself to various
   attacks, we consider a few potential attacks against RAINS servers
   and RAINS clients in the subsections below:

13.1.  Server state exhaustion

   [EDITOR'S NOTE: detail this attack: attacker can create domain, use
   long-validity queries to exhaust state at server. defense: server can
   consider shorter validity time than that requested, but not longer.
   attack: attacker can push garbage assertions proactively. defense:
   server doesn't accept assertions it's never seen a query for. how to
   handle an attacker that pushes assertions and queries? attack:



Trammell                 Expires March 24, 2018                [Page 47]


Internet-Draft                    RAINS                   September 2017


   attacker can push garbage delegations, exhausting delegation chain
   cache. defense: server doesn't accept sigs for domains it doesn't
   know about, but what about a domain with hundreds of valid
   delegations? in all cases, blacklisting both clients and domains
   seems like a good idea.]

13.2.  Query relay attacks

   [EDITOR'S NOTE: detail this attack: attacker can cause traffic
   overload at a targeted intermediate or authority service by crafting
   queries and sending them via multiple query services.  There is no
   amplification here, but a concentration, with indirection that makes
   tracing difficult.]

14.  Acknowledgments

   Thanks to Daniele Asoni, Laurent Chuat, Markus Deshon, Ted Hardie,
   Joe Hildebrand, Tobias Klausmann, Steve Matsumoto, Adrian Perrig,
   Raphael Reischuk, Andrew Sullivan, and Suzanne Woolf for the
   discussions leading to the design of this protocol.  Thanks
   especially to Stephen Shirley for detailed feedback, and to Christian
   Fehlmann for extensive implementation experience which has informed
   the further development of the protocol.

15.  References

15.1.  Normative References

   [FIPS-186-3]
              NIST, ., "Digital Signature Standard FIPS 186-3", June
              2009.

   [I-D.trammell-inip-pins]
              Trammell, B., "Properties of an Ideal Naming Service",
              draft-trammell-inip-pins-03 (work in progress), March
              2017.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.






Trammell                 Expires March 24, 2018                [Page 48]


Internet-Draft                    RAINS                   September 2017


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/info/rfc2782>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727,
              DOI 10.17487/RFC4727, November 2006,
              <https://www.rfc-editor.org/info/rfc4727>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

15.2.  Informative References







Trammell                 Expires March 24, 2018                [Page 49]


Internet-Draft                    RAINS                   September 2017


   [I-D.thomson-postel-was-wrong]
              Thomson, M., "The Harmful Consequences of Postel's Maxim",
              draft-thomson-postel-was-wrong-01 (work in progress), June
              2017.

   [PARSER-BUGS]
              Bratus, S., Patterson, M., and A. Shubina, "The Bugs We
              Have To Kill (USENIX login)", August 2015.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
              2006, <https://www.rfc-editor.org/info/rfc4632>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC6605]  Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
              Signature Algorithm (DSA) for DNSSEC", RFC 6605,
              DOI 10.17487/RFC6605, April 2012,
              <https://www.rfc-editor.org/info/rfc6605>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/info/rfc6698>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.





Trammell                 Expires March 24, 2018                [Page 50]


Internet-Draft                    RAINS                   September 2017


   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
              Trammell, B., Huitema, C., and D. Borkmann,
              "Confidentiality in the Face of Pervasive Surveillance: A
              Threat Model and Problem Statement", RFC 7624,
              DOI 10.17487/RFC7624, August 2015,
              <https://www.rfc-editor.org/info/rfc7624>.

   [RFC7696]  Housley, R., "Guidelines for Cryptographic Algorithm
              Agility and Selecting Mandatory-to-Implement Algorithms",
              BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
              <https://www.rfc-editor.org/info/rfc7696>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
              Kumari, "Client Subnet in DNS Queries", RFC 7871,
              DOI 10.17487/RFC7871, May 2016,
              <https://www.rfc-editor.org/info/rfc7871>.

   [SCION]    Barrera, D., Reischuk, R., Szalachowski, P., and A.
              Perrig, "SCION Five Years Later - Revisiting Scalability,
              Control, and Isolation Next-Generation Networks
              (arXiv:1508.01651v1)", August 2015.

   [XEP0115]  Hildebrand, J., Saint-Andre, P., Troncon, R., and J.
              Konieczny, "XEP-0115 Entity Capababilities", February
              2008.

Author's Address

   Brian Trammell
   ETH Zurich
   Universitaetstrasse 6
   Zurich  8092
   Switzerland

   Email: ietf@trammell.ch











Trammell                 Expires March 24, 2018                [Page 51]