RAINS (Another Internet Naming Service) Protocol Specification
draft-trammell-rains-protocol-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Brian Trammell , Christian Fehlmann | ||
| Last updated | 2019-01-11 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-trammell-rains-protocol-04
Network Working Group B. Trammell
Internet-Draft C. Fehlmann
Intended status: Experimental ETH Zurich
Expires: July 14, 2019 January 10, 2019
RAINS (Another Internet Naming Service) Protocol Specification
draft-trammell-rains-protocol-04
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 a set of properties of an
idealized Internet naming service.
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 July 14, 2019.
Copyright Notice
Copyright (c) 2019 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 & Fehlmann Expires July 14, 2019 [Page 1]
Internet-Draft RAINS January 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. About This Document . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. An Ideal Internet Naming Service . . . . . . . . . . . . . . 7
3.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Meaningfulness . . . . . . . . . . . . . . . . . . . 8
3.2.2. Distinguishability . . . . . . . . . . . . . . . . . 8
3.2.3. Minimal Structure . . . . . . . . . . . . . . . . . . 9
3.2.4. Federation of Authority . . . . . . . . . . . . . . . 9
3.2.5. Uniqueness of Authority . . . . . . . . . . . . . . . 9
3.2.6. Transparency of Authority . . . . . . . . . . . . . . 9
3.2.7. Revocability of Authority . . . . . . . . . . . . . . 10
3.2.8. Consensus on Root of Authority . . . . . . . . . . . 10
3.2.9. Authenticity of Delegation . . . . . . . . . . . . . 10
3.2.10. Authenticity of Response . . . . . . . . . . . . . . 10
3.2.11. Authenticity of Negative Response . . . . . . . . . . 10
3.2.12. Dynamic Consistency . . . . . . . . . . . . . . . . . 11
3.2.13. Explicit Inconsistency . . . . . . . . . . . . . . . 11
3.2.14. Global Invariance . . . . . . . . . . . . . . . . . . 12
3.2.15. Availability . . . . . . . . . . . . . . . . . . . . 12
3.2.16. Lookup Latency . . . . . . . . . . . . . . . . . . . 12
3.2.17. Bandwidth Efficiency . . . . . . . . . . . . . . . . 12
3.2.18. Query Linkability . . . . . . . . . . . . . . . . . . 12
3.2.19. Explicit Tradeoff . . . . . . . . . . . . . . . . . . 13
3.2.20. Trust in Infrastructure . . . . . . . . . . . . . . . 13
3.3. Observations . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. Delegation and redirection are separate operations . 14
3.3.2. Unicode alone may not be sufficient for
distinguishable names . . . . . . . . . . . . . . . . 14
3.3.3. Implicit inconsistency makes global invariance
challenging to verify . . . . . . . . . . . . . . . . 14
4. RAINS Protocol Architecture . . . . . . . . . . . . . . . . . 14
5. Information and Data Model . . . . . . . . . . . . . . . . . 16
5.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.1. Message Section structure . . . . . . . . . . . . . . 19
5.2. Assertions . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Singular Assertions . . . . . . . . . . . . . . . . . 21
5.2.2. Shards . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.3. Zones . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.4. P-Shards . . . . . . . . . . . . . . . . . . . . . . 24
5.2.5. Dynamic Assertion Validity . . . . . . . . . . . . . 25
5.2.6. Semantic of nonexistence proofs . . . . . . . . . . . 26
Trammell & Fehlmann Expires July 14, 2019 [Page 2]
Internet-Draft RAINS January 2019
5.2.7. Context in Assertions . . . . . . . . . . . . . . . . 26
5.2.8. Zone-Reflexive Singular Assertions . . . . . . . . . 27
5.3. Object Types and Encodings . . . . . . . . . . . . . . . 27
5.3.1. Name Alias . . . . . . . . . . . . . . . . . . . . . 29
5.3.2. IPv6 Address . . . . . . . . . . . . . . . . . . . . 29
5.3.3. IPv4 Address . . . . . . . . . . . . . . . . . . . . 29
5.3.4. Redirection . . . . . . . . . . . . . . . . . . . . . 29
5.3.5. Delegation . . . . . . . . . . . . . . . . . . . . . 29
5.3.6. Nameset . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.7. Certificate Information . . . . . . . . . . . . . . . 31
5.3.8. Service Information . . . . . . . . . . . . . . . . . 33
5.3.9. Registrar Information . . . . . . . . . . . . . . . . 33
5.3.10. Registrant Information . . . . . . . . . . . . . . . 33
5.3.11. Infrastructure Key . . . . . . . . . . . . . . . . . 33
5.3.12. External Key . . . . . . . . . . . . . . . . . . . . 33
5.3.13. Next Delegation Public Key . . . . . . . . . . . . . 34
5.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 34
5.5. Queries . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5.1. Query Options . . . . . . . . . . . . . . . . . . . . 37
5.5.2. Confirmation Queries . . . . . . . . . . . . . . . . 38
5.5.3. Context in Queries . . . . . . . . . . . . . . . . . 38
5.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 39
5.7. Signatures . . . . . . . . . . . . . . . . . . . . . . . 40
5.7.1. Canonicalization . . . . . . . . . . . . . . . . . . 42
5.7.2. EdDSA signature and public key format . . . . . . . . 43
5.8. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.9. Capabilities . . . . . . . . . . . . . . . . . . . . . . 45
6. RAINS Protocol . . . . . . . . . . . . . . . . . . . . . . . 46
6.1. Transport Bindings . . . . . . . . . . . . . . . . . . . 46
6.1.1. TLS over TCP . . . . . . . . . . . . . . . . . . . . 46
6.1.2. Heartbeat Messages . . . . . . . . . . . . . . . . . 47
6.2. Protocol Dynamics . . . . . . . . . . . . . . . . . . . . 47
6.2.1. Message Processing . . . . . . . . . . . . . . . . . 47
6.2.2. Message Transmission . . . . . . . . . . . . . . . . 51
6.3. Client Protocol . . . . . . . . . . . . . . . . . . . . . 52
6.4. Publication Protocol . . . . . . . . . . . . . . . . . . 52
6.5. Enforcing Assertion Consistency . . . . . . . . . . . . . 52
7. Operational Considerations . . . . . . . . . . . . . . . . . 53
7.1. Discovering RAINS servers . . . . . . . . . . . . . . . . 54
7.2. Bootstrapping RAINS Services . . . . . . . . . . . . . . 54
7.3. Cooperative Delegation Distribution . . . . . . . . . . . 54
7.4. Assertion Lifetime Management . . . . . . . . . . . . . . 55
7.5. Secret Key Management . . . . . . . . . . . . . . . . . . 55
7.6. Public Key Management . . . . . . . . . . . . . . . . . . 55
7.6.1. Key Phase and Key Rotation . . . . . . . . . . . . . 56
7.6.2. Next Key Assertions . . . . . . . . . . . . . . . . . 56
8. Experimental Design and Evaluation . . . . . . . . . . . . . 57
9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
Trammell & Fehlmann Expires July 14, 2019 [Page 3]
Internet-Draft RAINS January 2019
9.1. Integrity and Confidentiality Protection . . . . . . . . 57
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
12.1. Normative References . . . . . . . . . . . . . . . . . . 58
12.2. Informative References . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
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 defined in Section 3.
Its architecture (Section 4) and information model (Section 5) 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),
created by the subordinate, 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.
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 5.2.7. Queries are
valid in one or more contexts, with specific rules for determining
which assertions answer which queries; see Section 5.5.3.
Trammell & Fehlmann Expires July 14, 2019 [Page 4]
Internet-Draft RAINS January 2019
o There is 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]. As with 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 6).
1.1. About This Document
The source of this document is available in the repository
https://github.com/britram/rains-prototype, and a rendered working
copy is available at https://britram.github.io/rains-prototype. Open
issues can be seen and discussed at https://github.com/britram/rains-
prototype/issues.
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 Subject: A name or address about which Assertions can be made.
o Object: A type/value pair of information about a name within an
Assertion.
o Assertion: A signed statement about the existence or nonexistence
of a mapping from a Subject name and Context to an Object at a
given point in time. It is either a Singular Assertion, Shard, or
Zone.
o Singular Assertion: A mapping between a Subject and one or several
Objects, signed by the Authority for the namespace containing that
Subject. See Section 5.2.
Trammell & Fehlmann Expires July 14, 2019 [Page 5]
Internet-Draft RAINS January 2019
o Authority: An entity that has the right to determine which
Assertions exist within its Zone
o Delegation: An Assertion proving that an Authority has given the
right to make Assertions about names within the part of a
namespace identified by a Subject to a subordinate Authority.
This subordinate Authority holds a secret key which can generate
signatures verifiable using a public key associated with a
delegation to the Zone.
o Zone: A portion of a namespace rooted at a given point in the
namespace hierarchy. A Zone contains all the Assertions about
Subjects tha exist within its part of the namespace.
o Query: An expression of interest in certain types of objects
pertaining to a Subject name in one or more contexts. See
Section 5.5.
o Context: Additional information about the scope in which an
Assertion or Query is valid. See Section 5.2.7 and Section 5.5.3.
o Shard: A group of assertions common to a zone and valid at a given
point in time, scoped to a lexicographic range of Subject names
within the Zone, for purposes of proving nonexistence of an
Assertion. Shards may be encoded to provide either absolute proof
or probabilistic assurance of nonexistence. See Section 5.2.2 and
Section 5.2.4.
o RAINS Message: Unit of exchange in the RAINS protocol, containing
Assertions, Queries, and/or Notifications. See Section 5.1.
o Notification: A RAINS-internal message section carrying
information about the operation of the protocol itself. See
Section 5.6.
o Authority Service: A service provided by a RAINS Server for
publishing Assertions by an Authority. See Section 4.
o Query Service: A service provided by a RAINS Server for answering
Queries on behalf of a RAINS Client. See Section 4.
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 4.
o RAINS Server: A server that supports the RAINS Protocol, and
provides one or more services on behalf of other RAINS Servers
and/or RAINS Clients. See Section 4.
Trammell & Fehlmann Expires July 14, 2019 [Page 6]
Internet-Draft RAINS January 2019
o RAINS Client: A client that uses the Query Service of one or more
RAINS Servers to retrieve Assertions on behalf of applications
that e.g. wish to connect to named services in the Internet.
3. An Ideal Internet Naming Service
We begin by returning to first principles, to determine the
dimensions of the design space of desirable properties of an
Internet-scale naming service. We recognize that the choices made in
the evolution of the DNS since its initial design are only one path
through the design space of Internet-scale naming services. Many
other naming services have been proposed, though none has been
remotely as successful for general-purpose use in the Internet. The
following subsections outline the space more generally. It is, of
course, informed by decades of experience with the DNS, but
identifies a few key gaps which we then aim to address directly with
the design of RAINS.
Section 3.1 defines the set of operations a naming service should
provide for queriers and authorities, Section 3.2 defines a set of
desirable properties of the provision of this service, and
Section 3.3 examines implications of these properties.
3.1. Interfaces
At its core, a naming service must provide a few basic functions for
queriers that associate the subject of a query with information about
that subject. The naming service provides the information necessary
for a querier to establish a connection with some other entity in the
Internet, given a name identifying it.
o Name to Address: given a Subject name, the naming service returns
a set of addresses associated with that name, if such an
association exists. The association is determined by the
authority for that name. Names may be associated with addresses
in one or more address families (e.g. IP version 4, IP version
6). A querier may specify which address families it is interested
in. All address families are treated equally by the naming
system. This mapping is implemented in the DNS protocol via the A
and AAAA RRTYPES.
o Address to Name: given an Subject address, the naming service
returns a set of names associated with that address, if such an
association exists. The association is determined by the
authority for that address. This mapping is implemented in the
DNS protocol via the PTR RRTYPE. IPv4 mappings exist within the
in-addr.arpa. zone, and IPv6 mappings in the ip6.arpa. zone.
These mappings imply a limited set of boundaries on which
Trammell & Fehlmann Expires July 14, 2019 [Page 7]
Internet-Draft RAINS January 2019
delegations may be made (octet boundaries for IPv4, nybble
boundaries for IPv6).
o Name to Name: given a Subject name, the naming service returns a
set of object names associated with that name, if such an
association exists. The association is determined by the
authority for the subject name. This mapping is implemented in
the DNS protocol via the CNAME RRTYPE. CNAME does not allow the
association of multiple object names with a single subject, and
CNAME may not combine with other RRTYPEs (e.g. NS, MX)
arbitrarily.
o Name to Auxiliary Information: given a Subject name, the naming
service returns other auxiliary information associated with that
name that is useful for establishing communication over the
Internet with the entities associated with that name. Most of the
other RRTYPES in the DNS protocol implement these sort of
mappings.
A naming service also provides other interfaces besides the query
interface. The interface it presents to an Authority allows updates
to the set of Assertions and Delegations in that Authority's
namespace. Updates consist of additions of, changes to, and
deletions of Assertions and Delegations. In the present DNS, this
interface consists of the publication of a new zone file with an
incremented version number, but other authority interfaces are
possible.
3.2. Properties
The following properties are desirable in a naming service providing
the functions in Section 3.1.
3.2.1. Meaningfulness
A naming service must provide the ability to name objects that its
human users find more meaningful than the objects themselves.
3.2.2. Distinguishability
A naming service must make it possible to guarantee that two
different names are easily distinguishable from each other by its
human users.
Trammell & Fehlmann Expires July 14, 2019 [Page 8]
Internet-Draft RAINS January 2019
3.2.3. Minimal Structure
A naming service should impose as little structure on the names it
supports as practical in order to be universally applicable. Naming
services that impose a given organizational structure on names will
not translate well to societies where that organizational structure
is not prevalent.
3.2.4. Federation of Authority
An Authority can delegate some part of its namespace to some other
subordinate Authority. This property allows the naming service to
scale to the size of the Internet, and leads to a tree-structured
namespace, where each Delegation is itself identified with a Subject
at a given level in the namespace.
In the DNS protocol, this federation of authority is implemented
through delegation using the NS RRTYPE, redirecting queries to
subordinate authorities recursively to the final authority. When
DNSSEC is used, the DS RRTYPE is used to verify this delegation.
3.2.5. Uniqueness of Authority
For a given Subject, there is a single Authority that has the right
to determine the Assertions and/or Delegations for that subject. The
unitary authority for the root of the namespace tree may be special,
though; see Section 3.2.8.
In the DNS protocol as deployed, unitary authority is approximated by
the entity identified by the SOA RRTYPE. The existence of
registrars, which use the Extensible Provisioning Protocol (EPP)
[RFC5730] to modify entries in the zones under the authority of a
top-level domain registry, complicates this somewhat.
3.2.6. Transparency of Authority
A querier can determine the identity of the Authority for a given
Assertion. An Authority cannot delegate its rights or
responsibilities with respect to a subject without that Delegation
being exposed to the querier.
In DNS, the authoritative name server(s) to which a query is
delegated via the NS RRTYPE are known. However, we note that in the
case of authorities which delegate the ability to write to the zone
to other entities (i.e., the registry-registrar relationship), the
current DNS provides no facility for a querier to understand on whose
behalf an authoritative assertion is being made; this information is
instead available via WHOIS. To our knowledge, no present DNS name
Trammell & Fehlmann Expires July 14, 2019 [Page 9]
Internet-Draft RAINS January 2019
servers use WHOIS information retrieved out of band to make policy
decisions.
3.2.7. Revocability of Authority
An ideal naming service allows the revocation and replacement of an
authority at any level in the namespace, and supports the revocation
and replacement of authorities with minimal operational disruption.
The current DNS allows the replacement of any level of delegation
except the root through changes to the appropriate NS and DS records.
Authority revocation in this case is as consistent as any other
change to the DNS.
3.2.8. Consensus on Root of Authority
Authority at the top level of the namespace tree is delegated
according to a process such that there is universal agreement
throughout the Internet as to the subordinates of those Delegations.
3.2.9. Authenticity of Delegation
Given a Delegation from a superordinate to a subordinate Authority, a
querier can verify that the superordinate Authority authorized the
Delegation.
Authenticity of delegation in DNS is provided by DNSSEC [RFC4033].
3.2.10. Authenticity of Response
The authenticity of every answer is verifiable by the querier. The
querier can confirm that the Assertion returned in the answer is
correct according to the Authority for the Subject of the query.
Authenticity of response in DNS is provided by DNSSEC.
3.2.11. Authenticity of Negative Response
Some queries will yield no answer, because no such Assertion exists.
In this case, the querier can confirm that the Authority for the
Subject of the query asserts this lack of Assertion.
Authenticity of negative response in DNS is provided by DNSSEC.
Trammell & Fehlmann Expires July 14, 2019 [Page 10]
Internet-Draft RAINS January 2019
3.2.12. Dynamic Consistency
Consistency in a naming service is important. The naming service
should provide the most globally consistent view possible of the set
of Assertions that exist at a given point in time, within the limits
of latency and bandwidth tradeoffs.
When an Authority makes changes to an Assertion, every query for a
given Subject returns either the new valid result or a previously
valid result, with known and/or predictable bounds on "how
previously". Given that additions of, changes to, and deletions of
Assertions may have different operational causes, different bounds
may apply to different operations.
The time-to-live (TTL) on a resource record in DNS provides a
mechanism for expiring old resource records. We note that this
mechanism makes additions to the system propagate faster than changes
and deletions, which may not be a desirable property. However, as no
context information is explicitly available in DNS, the DNS cannot be
said to be dynamically consistent, as different implicitly
inconsistent views of an Assertion may be persistent.
3.2.13. Explicit Inconsistency
Some techniques require giving different answers to the same query,
even in the absence of changes: the stable state of the namespace is
not globally consistent. This inconsistency should be explicit: a
querier can know that an answer might be dependent on its identity,
network location, or other factors.
One example of such desirable inconsistency is the common practice of
"split horizon" DNS, where an organization makes internal names
available on its own network, but only the names of externally-
visible subjects available to the Internet at large.
Another is the common practice of DNS-based content distribution, in
which an authoritative name server gives different answers for the
same query depending on the network location from which the query was
received, or depending on the subnet in which the end client
originating a query is located (via the EDNS Client Subnet extension
{RFC7871}}). Such inconsistency based on client identity or network
address may increase query linkability (see Section 3.2.18).
These forms of inconsistency are implicit, not explicit, in the
current DNS. We note that while DNS can be deployed to allow
essentially unlimited kinds of inconsistency in its responses, there
is no protocol support for a query to express the kind of consistency
it desires, or for a response to explicitly note that it is
Trammell & Fehlmann Expires July 14, 2019 [Page 11]
Internet-Draft RAINS January 2019
inconsistent. [RFC7871] does allow a querier to note that it would
specifically like the view of the state of the namespace offered to a
certain part of the network, and as such can be seen as inchoate
support for this property.
3.2.14. Global Invariance
An Assertion which is not intended to be explicitly inconsistent by
the Authority issuing it must return the same result for every Query
for it, regardless of the identity or location of the querier.
This property is not provided by DNS, as it depends on the robust
support of the Explicit Inconsistency property above. Examples of
global invariance failures include geofencing and DNS-based
censorship ordered by a local jurisdiction.
3.2.15. Availability
The naming service as a whole is resilient to failures of individual
nodes providing the naming service, as well as to failures of links
among them. Intentional prevention by an adversary of a successful
answer to a query should be as hard as practical.
The DNS protocol was designed to be highly available through the use
of secondary name servers. Operational practices (e.g. anycast
deployment) also increase the availability of DNS as currently
deployed.
3.2.16. Lookup Latency
The time for the entire process of looking up a name and other
necessary associated data from the point of view of the querier,
amortized over all queries for all connections, should not
significantly impact connection setup or resumption latency.
3.2.17. Bandwidth Efficiency
The bandwidth cost for looking up a name and other associated data
necessary for establishing communication with a given Subject, from
the point of view of the querier, amortized over all queries for all
connections, should not significantly impact total bandwidth demand
for an application.
3.2.18. Query Linkability
It should be costly for an adversary to monitor the infrastructure in
order to link specific queries to specific queriers.
Trammell & Fehlmann Expires July 14, 2019 [Page 12]
Internet-Draft RAINS January 2019
DNS over TLS [RFC7858] and DNS over DTLS [RFC8094] provide this
property between a querier and a recursive resolver; mixing by the
recursive helps with mitigating upstream linkability.
3.2.19. Explicit Tradeoff
A querier should be able to indicate the desire for a benefit with
respect to one performance property by accepting a tradeoff in
another, including:
o Reduced latency for reduced dynamic consistency
o Increased dynamic consistency for increased latency
o Reduced request linkability for increased latency and/or reduced
dynamic consistency
o Reduced aggregate bandwidth use for increased latency and/or
reduced dynamic consistency
There is no support for explicit tradeoffs in performance properties
available to clients in the present DNS.
3.2.20. Trust in Infrastructure
A querier should not need to trust any entity other than the
authority as to the correctness of association information provided
by the naming service. Specifically, the querier should not need to
trust any intermediary of infrastructure between itself and the
authority, other than that under its own control.
DNS provides this property with DNSSEC. However, the lack of
mandatory DNSSEC, and the lack of a viable transition strategy to
mandatory DNSSEC (see [I-D.trammell-optional-security-not]), means
that trust in infrastructure will remain necessary for DNS even with
large scale DNSSEC deployment.
3.3. Observations
On a cursory examination, many of the properties of our ideal name
service can be met, or could be met, by the present DNS protocol or
extensions thereto. We note that there are further possibilities for
the future evolution of naming services meeting these properties.
This section contains random observations that might inform future
work.
Trammell & Fehlmann Expires July 14, 2019 [Page 13]
Internet-Draft RAINS January 2019
3.3.1. Delegation and redirection are separate operations
Any system which can provide the authenticity properties enumerated
above is freed from one of the design characteristics of the present
domain name system: the requirement to bind a zone of authority to a
specific set of authoritative servers. Since the authenticity of a
delegation must be protected by a chain of signatures back to the
root authority, the location within the infrastructure where an
authoritative mapping "lives" is no longer bound to a specific name
server. While the present design of DNS does have its own
scalability advantages, this implication allows a much larger design
space to be explored for future name service work, as a Delegation
need not always be implemented via redirection to another name
server.
3.3.2. Unicode alone may not be sufficient for distinguishable names
Allowing names to be encoded in Unicode goes a long way toward
meeting the meaningfulness property (see Section 3.2.1) for the
majority of speakers of human languages. However, as noted by the
Internet Architecture Board (see [IAB-UNICODE7]) and discussed at the
Locale-free Unicode Identifiers (LUCID) BoF at IETF 92 in Dallas in
March 2015 (see [LUCID]), it is not in the general case sufficient
for distinguishability (see Section 3.2.2). An ideal naming service
may therefore have to supplement Unicode by providing runtime support
for disambiguation of queries and assertions where the results may be
indistinguishable.
3.3.3. Implicit inconsistency makes global invariance challenging to
verify
DNS does not provide a generalized form of explicit inconsistency, so
efforts to verify global invariance, or rather, to discover
Assertions for which global invariance does not hold, are necessarily
effort-intensive and dynamic. For example, the Open Observatory of
Network Interference performs DNS consistency checking from multiple
volunteer vantage points for a set of targeted (i.e., likely to be
globally variant) domain names; see
https://ooni.torproject.org/nettest/dns-consistency/.
4. RAINS Protocol Architecture
The RAINS architecture is simple, and vaguely resembles the
architecture of DNS. A RAINS Server is an entity that provides
transient and/or permanent storage for assertions about names and
addresses, and a lookup function that finds assertions for a given
query about a name or address, either by searching local storage or
Trammell & Fehlmann Expires July 14, 2019 [Page 14]
Internet-Draft RAINS January 2019
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.
From the point of view of an authority (an entity owning some part of
the namespace by virtue of holding private keys associated with a
zone delegation), the RAINS protocol is used to publish signed
assertions toward one or more RAINS servers configured to provide
authority service for their domains. Since the signatures on these
assertions expire periodically, the authority must publish assertions
continuously toward the authority services. In order to provide a
DNS-like operational experience, a RAINS server providing authority
service may be colocated with the infrastructure for publishing
assertions; however, the architecture of the protocol means these
functions need not be colocated.
Clients are configured, or use some out-of-band discovery mechanism,
to contact one or more query services using the RAINS protocol, and
may trust those services to verify assertion signatures on the
client's behalf.
In this way, the same protocol is used between servers, from client
to server, and from publisher to server, with minor differences among
the interactions implemented as profiles. See Section 6 for details
The protocol itself is designed in terms of its information and data
model, detailed in Section 5. Since all RAINS information is carried
in messages containing assertions, and an assertion is not valid
unless it is signed, the validity of an assertion is separated from
whence the assertion was received. This means the RAINS protocol
itself is merely a means for moving RAINS assertions around, and
moving RAINS queries to places where they can be answered. This
document defines bindings for carrying RAINS messages over TLS over
Trammell & Fehlmann Expires July 14, 2019 [Page 15]
Internet-Draft RAINS January 2019
TCP, but bindings to other transports (e.g. QUIC [QUIC]) or session
layers (e.g. HTTP [RFC7540]) would be trivial to design, and the
protocol provides a capability mechanism for discovering alternate
transports.
5. Information and Data Model
The RAINS Protocol is based on an information model containing three
primary kinds of objects: Assertions, Queries, and Notifications. An
Assertion contains some information about a name or address, and a
Query contains a request for information about a name or address.
Queries are answered with Assertions. Notifications provide
information about the operation of the protocol itself. The protocol
exchanges RAINS Messages, which act as envelopes containing
Assertions, Queries, and Notifications. RAINS Messages also provide
for capabilities-based versioning of the protocol, and for
recognition of a chunk of CBOR-encoded binary data at rest to be
recognized as a RAINS message.
The RAINS data model is a relatively straightforward mapping of the
information model to the Concise Binary Object Representation (CBOR)
[RFC7049], such that Assertions are split into four subtypes
depending on their scope and purpose:
o Singular Assertions and Zones for a positive proof of the
existence of an association between a name and an Object;
o Shards and P-Shards for negative proof thereof.
Messages, Singular Assertions, Shards, P-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 any
data objects associated with map keys they 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, due to the
efficiency of representation of these values in CBOR.
Message and Assertion 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 4, and signature algorithms in
Table 10.
+------+-----------------+------------------------------------------+
Trammell & Fehlmann Expires July 14, 2019 [Page 16]
Internet-Draft RAINS January 2019
| 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, Shard, |
| | | P-Shard or Zone |
| | | |
| 4 | subject-zone | Zone name in an Assertion, Shard, |
| | | P-Shard or Zone |
| | | |
| 5 | subject-addr | Subject address in address assertion |
| | | |
| 6 | context | Context of an Assertion, Shard, P-Shard, |
| | | Zone or Query |
| | | |
| 7 | objects | Objects of an Assertion |
| | | |
| 8 | query-name | Fully qualified name for a Query |
| | | |
| 9 | reserved | Reserved for future use |
| | | |
| 10 | query-types | Acceptable object types for a Query |
| | | |
| 11 | range | Lexical range of Assertions in Shard or |
| | | P-Shard |
| | | |
| 12 | query-expires | Absolute timestamp for query expiration |
| | | |
| 13 | query-opts | Set of query options requested |
| | | |
| 14 | current-time | Querier's latest assertion timestamp for |
| | | a query |
| | | |
| 15 | reserved | Reserved for future use |
| | | |
| 16 | reserved | Reserved for future use |
| | | |
| 17 | query-keyphases | All requested key phases of a Query |
| | | |
| 19 | reserved | Reserved for future use |
| | | |
| 20 | assertions | Singular Assertion content of a Shard or |
| | | Zone |
| | | |
Trammell & Fehlmann Expires July 14, 2019 [Page 17]
Internet-Draft RAINS January 2019
| 21 | note-type | Notification type |
| | | |
| 22 | note-data | Additional notification data |
| | | |
| 23 | content | Content of a Message or a P-Shard |
+------+-----------------+------------------------------------------+
Table 1: CBOR Map Keys used in RAINS
The information model is designed to be representation-independent,
and can be rendered using alternate structured-data representations
that support the concepts of maps and arrays. For example, YAML or
JSON could be used to represent RAINS messages and data structures
for debugging purposes. However, signatures over messages and
assertions need a single canonical representation of the object to be
signed as a bitstream. For RAINS, this is the CBOR representation
canonicalized as in Section 5.7.1; therefore alternate
representations are always secondary to the CBOR data model.
The following subsections describe the information and data model of
a RAINS message from the top down.
5.1. Messages
A Message is a self-contained unit of exchange in the RAINS protocol.
Messages have some content (the Assertions, Queries, and/or
Notifications carried by the Message) tagged with a token (see
Section 5.8). They may also carry information about peer
capabilities, and an optional signature.
More concretely, a Message is represented as a CBOR map with the CBOR
tag value 15309736, which identifies the map as a RAINS message.
This map MUST contain a token key (2) and a content key (23), and MAY
contain a capabilities key (1) a signatures key (0).
The value of the content key is an array of zero or more Message
Sections, as defined in Section 5.1.1
The value of the token key is an opaque 16-byte octet array used to
link Messages, Queries, and Notifications; see Section 5.8 for
details.
The value of the signatures key, when present, is an array of
Signatures over the entire Message, generated as in Section 5.7, and
to be verified against an infrastructure key (see Section 5.3.11) for
the RAINS Server originating the message.
Trammell & Fehlmann Expires July 14, 2019 [Page 18]
Internet-Draft RAINS January 2019
The value of the capabilities key, when present, is an array of
Capabilities or the hash thereof. The first Message sent from one
peer to another MUST contain the capabilities key. The capabilities
mechanism is described in Section 5.9.
5.1.1. Message Section structure
Each Message Section in the Message's content value is represented as
a two-element array. The first element in the array is the message
section type, encoded as an integer as in Table 2. The second
element in the array is a message section body, a CBOR map defined as
in the subsections Section 5.2, Section 5.5, and Section 5.6
+------+--------------+----------------------------------------+
| Code | Name | Description |
+------+--------------+----------------------------------------+
| 1 | assertion | Singular Assertion (see Section 5.2.1) |
| | | |
| 2 | shard | Shard (see Section 5.2.2) |
| | | |
| 3 | p-shard | P-Shard (see Section 5.2.4) |
| | | |
| 4 | zone | Zone (see Section 5.2.3) |
| | | |
| 5 | query | Query (see Section 5.5) |
| | | |
| 23 | notification | Notification (see Section 5.6) |
+------+--------------+----------------------------------------+
Table 2: Message Section Type Codes
5.2. Assertions
Information about names in RAINS is carried by Assertions. An
Assertion is a statement about a mapping from a Subject name to one
or several Object values, signed by some Authority for the namespace
containing the Assertion, with a temporal validity determined by the
lifetime of the signature(s) on the Assertion.
The subject of an Assertion is identified by a name in three parts:
o the subject zone name, identifying the namespace within which the
subject is contained;
o the subject name, identifying the name of the subject within that
zone; and
Trammell & Fehlmann Expires July 14, 2019 [Page 19]
Internet-Draft RAINS January 2019
o the subject context, as in Section 5.2.7, identifying the context
for purposes of explicit inconsistency.
The types of Objects that can be associated with a Subject are
described in Section 5.3.
There are four kinds of Assertions, distinguished by their scope (how
many Subjects are covered by a single Assertion) and their utility
(whether the Assertion can be used for positive proof of a Subject-
Object association, for negative proof of the lack of such an
association, or both):
o Singular Assertions contain a set of Objects associated with a
single given subject name in a given zone in a given context. The
signature on a Singular Assertion can be used to prove the
existence of an association between the subject name and the
Objects within the Assertion. Singular Assertions are described
in detail in Section 5.2.1.
o Zones contain all Singular Assertions that have the same zone and
context values. The signature on a Zone can be used to prove both
the existence of an association between a subject name and an
Object, as well as the absence of such an association. Zones are
described in detail in Section 5.2.3. If signed, the Singular
Assertions within a Zone can also be used on their own, as if they
were contained within a Message directly; in this case they
inherit zone and context information from the containing zone.
o Shards contain Singular Assertions for every Object associated
with every subject name in a given lexicographic range of subject
names within a given zone in a given context. The signature on a
Shard can be used to prove the nonexistence of an Object for a
subject name within its range. Shards are described in detail in
Section 5.2.2. If a Singular Assertion within a Shard is signed,
it inherits zone and context information from the containing shard
and can also be used outside the Shard.
o P-Shards (or Probabilistic Shards) contain a data structure that
can be used to demonstrate, within predictable bounds of false-
negative probability, the nonexistence of an Object for a subject
name within a lexicographic range of subject names within a given
zone in a given context. They allow an efficiency-accuracy
tradeoff for negative proofs. P-Shards are described in detail in
Section 5.2.4
Trammell & Fehlmann Expires July 14, 2019 [Page 20]
Internet-Draft RAINS January 2019
5.2.1. Singular Assertions
A Singular Assertion contains a set of Objects associated with a
single given subject name in a given zone in a given context. A
Singular Assertion with a valid signature can be used as a positive
answer to a query for a name. It is represented as a CBOR map. The
keys present in this map depend on whether the Singular Assertion is
contained in a Message, Shard or Zone.
Singular Assertions contained directly within a Message's content
value cannot inherit any values from their containers, and therefore
MUST contain the signatures (0), subject-name (3), subject-zone (4),
context (6), and objects (7) keys.
Singular Assertions within a Shard or Zone can inherit values from
their containers. A contained Singular Assertion MUST contain the
subject-name (3), and objects (7) keys. It MAY contain the
signatures (0) key. 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.7.
The value of the signatures (0) key, if present, is an array of one
or more Signatures as defined in Section 5.7. Signatures on a
contained Assertion are generated as if the inherited subject-zone
and context values are present in the Assertion. The signatures on
the Assertion are to be verified against the appropriate key for the
Zone containing the Assertion in the given context.
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 may cover multiple levels of hierarchy, separated by the
'.' character. The fully-qualified name of an Assertion 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 (see Section 5.3.6).
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
and MUST end with '.' (the root zone). 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. Both the authority-part and the context-part MUST end with a
'.'. If not present, the context of the assertion is inherited from
the containing Shard or Zone. See Section 5.2.7 for more.
Trammell & Fehlmann Expires July 14, 2019 [Page 21]
Internet-Draft RAINS January 2019
The value of the objects (7) key is an array of objects, as defined
in Section 5.3.
5.2.2. Shards
A Shard contains Singular Assertions for every Object within a zone
in a given context whose subject name falls within a specified
lexicographic range. A Shard with a valid signature, within which a
subject name should fall (i.e. appearing within that Shard's range),
but within which there is no Singular Assertion for the specified
subject name and Object, can therefore be taken as a proof of
nonexistence for that subject name and Object. Shards are used
exclusively for negative proof; the individual signatures on their
contained Singular Assertions are used for positive proof of the
existence of an assertion.
The content of a Shard (in terms of the number of Singular Assertions
it covers) is chosen by the Authority of the zone for which the Shard
is valid. There is an inherent tradeoff between the number of
Singular Assertions within a Shard and the size of the Shard, and
therefore the size of the Message that must be presented as negative
proof. P-Shards ("Probabalistic Shards", see Section 5.2.4) allow a
different tradeoff, gaining space efficiency and coverage for a
fixed, predictable probability of a false positive (i.e., the
possibility that the P-Shard cannot be used to prove the nonexistence
of a subject which does not, in fact, exist).
A Shard is represented as a CBOR map. Shards MUST contain the
signatures (0), subject-zone (4), context (6), range (11), and
assertions (20) keys.
The value of the signatures (0) key is an array of one or more
Signatures as defined in Section 5.7. Signatures on the Shard are to
be verified against the appropriate key for the Shard in the given
context.
The value of the subject-zone (4) key is a UTF-8 encoded string
containing the name of the zone in which the Singular Assertions
within the Shard are made and MUST end with '.' (the root zone).
The value of the context (6) key is a UTF-8 encoded string containing
the name of the context in which the Singular Assertions within the
Shard are valid. Both the authority-part and the context-part MUST
end with a '.'.
The value of the range (11) key is a two element array of strings or
nulls (subject-name A, subject-name B). A MUST lexicographically
sort before B. If A is null, the shard begins at the beginning of
Trammell & Fehlmann Expires July 14, 2019 [Page 22]
Internet-Draft RAINS January 2019
the zone. If B is null, the shard ends at the end of the zone. The
shard MUST NOT contain any Singular Assertions whose subject names
are equal to or sort before A, or are equal to or sort after B.
The value of the assertions (20) key is a CBOR array of Singular
Assertions as defined in Section 5.2.1. These Singular Assertions
MUST be sorted (see Section 5.7.1); the set of allowable Singular
Assertions is restricted by the range, as above.
5.2.3. Zones
A Zone contains Singular Assertions for every Object associated with
every subject name within a given zone in a given context. A Zone
with a valid signature can be used either as a positive answer for a
query about a name (when its contained Singular Assertions are not
signed), or as a negative answer to prove that a given Object does
not exist for a given name.
Organizing Singular Assertions into Zones allows operators of zones
with few subject names (e.g., used only for simple web hosting, as is
the case with many zones in the current Internet naming system) to
minimize signing and zone management overhead.
A Zone is represented as a CBOR map. Zones MUST contain the
signatures (0), subject-zone (4), context (6), and assertions (20)
keys.
The value of the signatures (0) key is an array of one or more
Signatures on the Zone as defined in Section 5.7. Signatures on the
Zone are to be verified against the appropriate key for the Zone in
the given context.
The value of the subject-zone (4) key is a UTF-8 encoded string
containing the name of the Zone which MUST end with '.' (the root
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. Both the
authority-part and the context-part MUST end with a '.'. See
Section 5.2.7
The value of the assertions (20) key is a CBOR array of Singular
Assertions as defined in Section 5.2.1. The CBOR array contains all
Singular Assertions of this zone and context and they MUST be sorted
(see Section 5.7.1).
Trammell & Fehlmann Expires July 14, 2019 [Page 23]
Internet-Draft RAINS January 2019
5.2.4. P-Shards
Shards (Section 5.2.2) can be used as definitive proof of the
nonexistence of a name within a zone. P-Shards serve the same
purpose, but offer only a probabilistic guarantee of the nonexistence
of a name. Specifically, as they are based on Bloom filters, a
subject name which does not in fact exist may appear in the P-Shard;
in return for this uncertainty, they offer a much more space-
efficient way to demonstrate the nonexistence of an Object for a
subject name within the zone and context than Shards do. There is a
tradeoff between the size of the bit string storing the Bloom filter,
the number of names covered by the P-Shard, and the false positive
error rate. The zone Authority can determine how to weight them.
A P-Shard is represented as a CBOR map. This map MUST contain the
signatures (0), subject-zone (4), context (6), and content(23) keys.
It MAY contain the range(11) key.
The value of the signatures (0) key is an array of one or more
Signatures as defined in Section 5.7. The signatures on the P-Shard
are to be verified against the appropriate key for the Zone for which
the P-Shard is valid in the given context.
The value of the subject-zone (4) key is a UTF-8 encoded string
containing the name of the zone within which the names represented in
the P-Shard are contained, and MUST end with '.' (the root zone).
The value of the context (6) key is a UTF-8 encoded string containing
the name of the context for which the names represented in the
P-Shard are valid. Both the authority-part and the context-part MUST
end with a '.'.
The value of the range (11) key, if present, is a two element array
of strings or nulls (subject-name A, subject-name B). A MUST
lexicographically sort before B. If A is null, the P-Shard begins at
the beginning of the zone. If B is null, the P-Shard ends at the end
of the zone. The P-Shard MUST NOT be used to check the existence of
Assertions about subject names equal to or sort before A, or are
equal to or sort after B. If the range (11) key is not present, the
P-Shard covers then entire zone.
The value of the content (23) key is a three-element array. The
first element identifies the algorithm used for generating the
bitstring. The second element identifies the hash function in use
for generating the bitstring. The third element contains the
bitstring itself, as an octet array. The size of the bitstring must
be 0 mod 8.
Trammell & Fehlmann Expires July 14, 2019 [Page 24]
Internet-Draft RAINS January 2019
Table 3 enumerates supported generation algorithms; supported hash
functions are given in Section 5.4.
+------+-------------+--------------------------------------+
| Code | Name | Description |
+------+-------------+--------------------------------------+
| 1 | bloom-km-12 | KM-optimized bloom filter with nh=12 |
| | | |
| 2 | bloom-km-16 | KM-optimized bloom filter with nh=16 |
| | | |
| 3 | bloom-km-20 | KM-optimized bloom filter with nh=20 |
| | | |
| 4 | bloom-km-24 | KM-optimized bloom filter with nh=24 |
+------+-------------+--------------------------------------+
Table 3: P-shard generation algorithms
These datastructures generate a bitstring using a Bloom filter and
the Kirsch-Mitzenmacher optimization [BETTER-BLOOM-FILTER].
To add a subject-object mapping for a name to a bloom-km structure,
the mapping is first encoded as a four-element CBOR array. The first
element is the subject name. The second element is the subject zone.
The third element is the subject context. The fourth element is the
type code as in Table 4 in Section 5.3. This encoded object is then
hashed according to the specified hash algorithm. The hash
algorithm's output is then split into two parts of equal length x and
y. To obtain the nh indexes into the bitstring, the following
equation is used:
o (x + i*y) mod bsl, where bsl is the bitstring length and i ∈
[1,nh]
To add a subject-object mapping, all bits at the calculated indices
are set to one. To check wether such a mapping exists, all bits at
the calculated indices are checked, and the mapping is taken to be in
the filter if all bits are one.
5.2.5. Dynamic Assertion Validity
For a given {subject, zone, context, type} tuple, multiple Singular
Assertions can be valid at a given point in time; the union of the
object values of all of these Singular Assertions is considered to be
the set of valid values at that point in time.
Trammell & Fehlmann Expires July 14, 2019 [Page 25]
Internet-Draft RAINS January 2019
5.2.6. Semantic of nonexistence proofs
Shards, P-Shards and Zones can all be used to prove nonexistence
during their validity. However, real naming systems are dynamic: an
Assertion might be created, altered, expired or revoked during the
validity period of a Shard, P-Shard or Zone, leading to an
inconsistency. Thus, a section proving nonexistence only captures
the state at the point in time when it was signed.
5.2.7. Context in Assertions
Assertion contexts are used to provide explicit inconsistency, while
allowing Assertions themselves to be globally valid regardless of the
query to which they are given in reply. Explicit inconsistency is
the simultaneous validity of multiple sets of Assertions for a single
subject name at a given point in time. Explicit inconsistency is
implemented by using the context to select an alternate chain of
signatures to use to verify the validity of an Assertion, 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 zone. For example, assertions about the name
'ethz.ch.' in the global context are only valid if signed by the
relevant Authority which is either 'ethz.ch.', 'ch.', or '.'
depending on the value of the subject zone of the Assertion.
o A local context is associated with a given Authority. The local
context's name is divided into an authority-part and a context-
part 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. Both the authority-part and the
context-part must end with a '.'.
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' could at the same time be validly signed
in the global context by the Authority over that name to allow
external users access this workstation. The local context simply
Trammell & Fehlmann Expires July 14, 2019 [Page 26]
Internet-Draft RAINS January 2019
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 5.5.3 below.
Developing conventions for assertion contexts for different
situations will require implementation and deployment experience, and
is a subject for future work.
5.2.8. Zone-Reflexive Singular Assertions
A zone may make a Singular Assertion about itself by using the string
"@" as a subject name. This facility can be used for any object
type, but is especially useful for self-signing root zones, and for a
zone to make a subsequent key assertion about itself. If a Singular
Assertion for an Object about a zone is available both in the zone
itself and in the superordinate zone, the assertion in the
superordinate zone will take precedence.
5.3. Object Types and Encodings
Each Object associated with a given subject name in a Singular
Assertion (see Section 5.2.1) is represented as a CBOR array, where
the first element is the type of the object, encoded as an integer in
the following table:
Trammell & Fehlmann Expires July 14, 2019 [Page 27]
Internet-Draft RAINS January 2019
+------+--------------+------------------------------+--------------+
| Code | Name | Description | Reference |
+------+--------------+------------------------------+--------------+
| 1 | name | name associated with subject | Section |
| | | | 5.3.1 |
| | | | |
| 2 | ip6-addr | IPv6 address of subject | Section |
| | | | 5.3.2 |
| | | | |
| 3 | ip4-addr | IPv4 address of subject | Section |
| | | | 5.3.3 |
| | | | |
| 4 | redirection | name of zone authority | Section |
| | | server | 5.3.4 |
| | | | |
| 5 | delegation | public key for zone | Section |
| | | delgation | 5.3.5 |
| | | | |
| 6 | nameset | name set expression for zone | Section |
| | | | 5.3.6 |
| | | | |
| 7 | cert-info | certificate information for | Section |
| | | name | 5.3.7 |
| | | | |
| 8 | service-info | service information for | Section |
| | | srvname | 5.3.8 |
| | | | |
| 9 | registrar | registrar information | Section |
| | | | 5.3.9 |
| | | | |
| 10 | registrant | registrant information | Section |
| | | | 5.3.10 |
| | | | |
| 11 | infrakey | public key for RAINS | Section |
| | | infrastructure | 5.3.11 |
| | | | |
| 12 | extrakey | external public key for | Section |
| | | subject | 5.3.12 |
| | | | |
| 13 | nextkey | next public key for subject | Section |
| | | | 5.3.13 |
+------+--------------+------------------------------+--------------+
Table 4: Object type codes
Subsequent elements contain the object content, encoded as described
in the respective subsection below.
Trammell & Fehlmann Expires July 14, 2019 [Page 28]
Internet-Draft RAINS January 2019
5.3.1. Name Alias
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.5).
The name type is roughly equivalent to the DNS CNAME RRTYPE.
5.3.2. IPv6 Address
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.
The ip6-addr type is roughly equivalent to the DNS AAAA RRTYPE.
5.3.3. IPv4 Address
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.
The ip4-addr type is roughly equivalent to the DNS A RRTYPE.
5.3.4. Redirection
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.
The redirection type is used to point to a "last-resort" server or
server from which assertions about a zone can be retrieved; it
therefore approximately replaces the DNS NS RRTYPE.
5.3.5. Delegation
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 4-element array. The second element is a signature
algorithm identifier as in Section 5.7. The third element is a key
phase as in Section 5.7. The fourth element is the public key,
Trammell & Fehlmann Expires July 14, 2019 [Page 29]
Internet-Draft RAINS January 2019
formatted as defined in Section 5.7 for the given algorithm
identifier and RAINS delegation chain keyspace.
Delegations approximately replace the DNS DNSKEY RRTYPE.
5.3.6. Nameset
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.
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.
Trammell & Fehlmann Expires July 14, 2019 [Page 30]
Internet-Draft RAINS January 2019
Set operations (intersection and subtraction) are available on
character classes. Two character class or range expressions in a
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:]]+
Nameset expression support is experimental and subject to (radical)
change in future revisions of this specification.
5.3.7. Certificate Information
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.
The second element is the protocol family specifier, describing the
cryptographic protocol used to connect, as defined in Table 5. The
protocol family defines the format of certificate data to be hashed.
The third element is the certificate usage specifier as in Table 6,
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, as in Table 7. The fifth item is the data itself,
whose format is defined by the protocol family and hash algorithm.
Trammell & Fehlmann Expires July 14, 2019 [Page 31]
Internet-Draft RAINS January 2019
+------+--------+---------------------------------+-----------------+
| Code | Name | Protocol family | Certificate |
| | | | format |
+------+--------+---------------------------------+-----------------+
| 0 | unspec | Unspecified | Unspecified |
| | | | |
| 1 | tls | Transport Layer Security (TLS) | [RFC5280] |
| | | [RFC8446] | |
+------+--------+---------------------------------+-----------------+
Table 5: 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.3 [RFC8446] or a subsequent version, secured with PKIX [RFC5280]
certificates.
+------+------+--------------------------+
| Code | Name | Certificate usage |
+------+------+--------------------------+
| 2 | ta | Trust Anchor Certificate |
| | | |
| 3 | ee | End-Entity Certificate |
+------+------+--------------------------+
Table 6: 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 on a connection attempt.
Certificate information is hashed using an appropriate hash function
described in Section 5.4; hash functions are identified by a code as
in Table 7. 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.
The cert-info type replaces the TLSA DNS RRTYPE.
Trammell & Fehlmann Expires July 14, 2019 [Page 32]
Internet-Draft RAINS January 2019
5.3.8. Service Information
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.
The service-info type replaces the DNS SRV RRTYPE.
5.3.9. Registrar Information
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.
5.3.10. Registrant Information
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
registrant according to the registry's policy.
5.3.11. Infrastructure Key
An infrakey (11) object contains a public key used to generate
signatures on messages by a named RAINS server, by which a RAINS
message signature may be verified by a receiver. It is identical in
structure to a delegation object, as defined in Section 5.3.5.
Infrakey signatures are especially useful for clients which delegate
verification to their query servers to authenticate the messages sent
by the query server.
5.3.12. External Key
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.7. The fourth
element is the public key, as defined in Section 5.7 for the given
algorithm identifier. An extrakey may be matched with a public key
Trammell & Fehlmann Expires July 14, 2019 [Page 33]
Internet-Draft RAINS January 2019
obtained through other means for additional authentication of an
assertion.
5.3.13. Next Delegation Public Key
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 6-element array. The second element is a signature
algorithm identifier as in Section 5.7. The third element is a key
phase as in Section 5.7. The fourth element is the public key, as
defined in Section 5.7 for the given algorithm identifier. The fifth
element is the requested-valid-since time, and the sixth element is
the requested-valid-until time, formatted as for signatures as in
Section 5.7. See Section 7.6 for more.
5.4. Hash Functions
Hash algorithms are used in several places in the RAINS data model:
o hashing certificate data in cert-info objects (see Section 5.3.7)
o hashing assertions into Bloom filters and checking if a subject-
object mapping within a zone for the given context and type is
present in a Bloom filter (see Section 5.2.4)
o hashing Assertion and Message data as part of generating a MAC
(see Section 5.7)
Hash functions are identified by a code given in Table 7. The
Applicability column determines where in the RAINS Protocol a
specific hash function might be used. Applicability "C" means the
hash is valid for use in a certificate info object, "P" that it can
be used for hashing assertions for P-shards, "S" that it can be used
for hashing Assertions and Messages for signatures.
Trammell & Fehlmann Expires July 14, 2019 [Page 34]
Internet-Draft RAINS January 2019
+------+----------+-------------------+--------+---------------+
| Code | Name | Reference | Length | Applicability |
+------+----------+-------------------+--------+---------------+
| 0 | nohash | (data not hashed) | var. | C |
| | | | | |
| 1 | sha-256 | [RFC6234] | 32 | CPS |
| | | | | |
| 2 | sha-512 | [RFC6234] | 64 | CS |
| | | | | |
| 3 | sha-384 | [RFC6234] | 48 | CS |
| | | | | |
| 4 | shake256 | [RFC8419] | 32 | PS |
| | | | | |
| 5 | fnv-64 | [FNV] | 8 | P |
| | | | | |
| 6 | fnv-128 | [FNV] | 16 | P |
+------+----------+-------------------+--------+---------------+
Table 7: Hash algorithms
5.5. Queries
Information about requests for information about names is carried in
Queries. A Query specifies the name and object types about which
information is requested, information about how long the querier is
willing to wait for an answer, and additional options indicating the
querier's preferences about how the query should be handled.
In contrast to Singular Assertions, the subject in a Query is given
as a fully-qualified name - the subject name concatenated to the zone
name with a '.', since a querier may not know the zone name
associated with a fully-qualified name.
There are two kinds of queries supported by the RAINS data model:
o Query (or Normal Query): a request for information about one or
several types of a given subject, about which the querier
expresses no prior information.
o Confirmation Query: a request for information about one or several
types of a given subject, for which the querier already has a
valid cached Assertion, but for which the querier would like a new
Assertion if available. Confirmation queries are covered in
Section 5.5.2.
Both queries are carried in a Query message section. Each Query
contained in a Message represents a separate Query.
Trammell & Fehlmann Expires July 14, 2019 [Page 35]
Internet-Draft RAINS January 2019
A Query body is represented as a CBOR 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), query-keyphases (17)
keys, and/or current-time (14) keys.
The value of the query-name (8) key is a UTF-8 encoded string
containing the name for which the query is issued and MUST end with a
'.' (the root zone).
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.
The value of the query-types (10) key is an array of integers
encoding the type(s) of Objects (as in Section 5.3) acceptable in
answers to the query. All values in the query-type array are treated
at equal priority: for example, [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 epoch
timestamp 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 and can be ignored.
The value of the query-keyphases (17) key, if present, is an array of
integers representing all key phases (see Section 5.7) desired in
delegation and nextkey answers to queries (see Section 5.3.5 and
Section 5.3.13). The value of the query-keyphases key is ignored for
all Queries where query-types does not include delegation or nextkey.
A query for a delegation or nextkey object that does not contain a
query-keyphases key SHOULD return information for all available
keyphases.
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. See Section 5.5.1.
The value of the current-time (14) key, if present, is the timestamp
of the latest information available at the querier for the queried
subject and object types. See Section 5.5.2 for details of how
confirmation queries work.
Trammell & Fehlmann Expires July 14, 2019 [Page 36]
Internet-Draft RAINS January 2019
5.5.1. Query Options
RAINS supports a set of query options to allow a querier to express
preferences. Query options are advisory.
+------+------------------------------------------------------------+
| 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 |
| | |
| 9 | Maximize freshness of result |
+------+------------------------------------------------------------+
Table 8: Query Option Codes
Options 1-5 and 9 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.
Option 6 specifies that the token on the message containing the query
(see Section 5.8) should be used on all queries resulting from a
given query, allowing traceability through an entire RAINS
infrastructure. The resulting queries SHOULD also carry Option 6.
When Option 6 is not present, queries sent by a server in response to
an incoming query must use different tokens.
By default, a client service will perform verification on a negative
query response and return a 404 No Assertion Exists Notification for
queries with a valid and verified proof of nonexistence, within a
Message signed by the query service's infrakey. Option 7 disables
Trammell & Fehlmann Expires July 14, 2019 [Page 37]
Internet-Draft RAINS January 2019
this behavior, and causes the query service to return the Shard,
P-Shard or Zone 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.
Option 9 specifies that the querier would prefer a fresh result to
one from the server's cache. If the server is not running an
authority service for the queried subject, it can honor this request
by issuing a query toward the authority. As this could be used for
denial-of-service-attacks, a server honoring Option 9 SHOULD limit
the rate of "freshness" queries it issues.
5.5.2. Confirmation Queries
A Query containing a current-time key is a Confirmation Query, used
by a server to refresh a cached query result. The querier passes the
timestamp of the most recent result it has cached, taken from the
most recent start time of the validity of the signature(s) on the
Assertion(s) that may answer it. If the answer to a Confirmation
Query is not newer than the given timestamp, the server SHOULD answer
with a Notification of type 304 (see Section 5.6). Otherwise, the
most recent Assertion answering the query is returned.
The value of the current-time key is represented as a CBOR integer
epoch timestamp identified with tag value 1 and encoded as in section
2.4.1 of [RFC7049].
5.5.3. Context in Queries
Context is used in Queries as it is in Assertions (see
Section 5.2.7). 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. Assertion contexts in an answer to a Query that is not
about the "any" context MUST match the context in the Query.
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 & Fehlmann Expires July 14, 2019 [Page 38]
Internet-Draft RAINS January 2019
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. 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 of the
'cdn-zones.some-cdn.com.' Authority. 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.
5.6. Notifications
Notifications contain information about the operation of the RAINS
protocol itself. A Notification body is represented as a CBOR map,
which MUST contain the token (2) and note-type (21) keys, and MAY
contain the note-data (22) key.
The value of the token (2) key is a 16-byte array, which MUST contain
the token of the Message to which the Notification is a response.
See Section 5.8.
The value of the note-type key is encoded as an integer as in the
Table 9.
Trammell & Fehlmann Expires July 14, 2019 [Page 39]
Internet-Draft RAINS January 2019
+------+-----------------------------------+------------------------+
| Code | Description | See Also |
+------+-----------------------------------+------------------------+
| 100 | Connection heartbeat | Section 6.1.2 |
| | | |
| 304 | Confirmation query has latest | Section 5.5.2 |
| | answer | |
| | | |
| 399 | Send full capabilities | Section 5.9 |
| | | |
| 400 | Bad message received | |
| | | |
| 403 | Inconsistent message received | Section 6.5 |
| | | |
| 404 | No assertion exists | Section 6.3 |
| | | |
| 406 | Message not acceptable for | Section 6.3 Section |
| | service | 6.4 |
| | | |
| 413 | Message too large | Section 6.1.1 |
| | | |
| 500 | Unspecified server error | |
| | | |
| 504 | No assertion available | Section 6.3 |
+------+-----------------------------------+------------------------+
Table 9: Notification Type Codes
Note that the status codes are chosen to be mnemonically similar to
status codes for HTTP [RFC7231].
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 Notification.
Notification codes 400 and 500 signal error conditions. 400 is a
general message noting that a client or server could not parse a
message, and 500 notes that the server failed to process a message
due to some internal error. Sending these notifications is optional,
according to server policy and configuration.
5.7. Signatures
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
Trammell & Fehlmann Expires July 14, 2019 [Page 40]
Internet-Draft RAINS January 2019
the encodings of the signature values in Assertions 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 key phase, 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.7.2 |
| | | | |
| 2 | ed448 | shake256 | See Section 5.7.2 |
+--------+------------+-----------+-------------------+
Table 10: Defined signature algorithms
As noted in Section 5.7.2, 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.7 |
+-------------+-------+-----------------------------------------+
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].
Trammell & Fehlmann Expires July 14, 2019 [Page 41]
Internet-Draft RAINS January 2019
A signature in RAINS is generated over a byte stream representing the
data element to be signed. The signing process is defined as
follows:
o Render the element to be signed into a canonical byte stream as
specified in Section 5.7.1.
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 element.
To verify a signature, generate the byte stream as for signing, then
verify the signature according to the algorithm selected.
5.7.1. Canonicalization
The byte stream representing a data element over which signatures are
generated and verified is a canonicalized CBOR object representing
the data element.
Signatures may be attached to any form of Assertion, as well as to
Messages as a whole.
First, to canonicalize signature metadata to allow it to be protected
by the signature, regardless of the type of data element:
o recursively strip all signatures from the content of the data
element.
o add a single-element signatures array at the level in the data
structure where the generated signature will be attached,
containing the information common to all signatures: the algorithm
identifier, a keyspace identifier, a key phase, a valid-since
timestamp, and a valid-until timestamp, but omitting any signature
content.
Then follow the canonicalization steps below appropriate for the type
of data element to be signed:
To generate a canonicalized Singular Assertion:
o sort the objects array by ascending order of object type
(Table 4), then by ascending numeric or lexicographic order of
each subsequent array element in the object(s)' representation.
o sort the CBOR map by ascending order of its keys (Table 1).
Trammell & Fehlmann Expires July 14, 2019 [Page 42]
Internet-Draft RAINS January 2019
To generate a canonicalized Shard:
o sort the objects array in each Singular Assertion contained in the
assertions array as, above.
o sort the assertions array by lexicographic order of the serialized
canonicalized byte string representing the assertion. Note that
this will cause the assertions array to be sorted in lexicographic
order of subject name, as well.
o sort the CBOR map by ascending order of its keys (Table 1).
To generate a canonicalized Zone:
o sort the objects array in each Singular Assertion contained in the
assertions array as, above.
o sort the assertions array by lexicographic order of the serialized
canonicalized byte string representing the assertion. Note that
this will cause the assertions array to be sorted in lexicographic
order of subject name, as well.
o sort the CBOR map by ascending order of its keys (Table 1).
To generate a canonicalized P-Shard:
o sort the CBOR map by ascending order of its keys (Table 1).
To generate a canonicalized Message:
o preserve the order of the Message Sections within the Message.
o canonicalize each Section as appropriate by following the
canonicalization steps for the appropriate Section type, above.
It is RECOMMENDED that RAINS implementations generate and send only
Messages whose contents are sorted according to the canonicalization
rules in this section, since the sorting operation is in any case
necessary to generate and verify signatures. However, an
implementation MUST NOT assume that a Message it receives is sorted
according to these rules.
5.7.2. 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
Trammell & Fehlmann Expires July 14, 2019 [Page 43]
Internet-Draft RAINS January 2019
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
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.8. Tokens
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 (normal and update) 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
Trammell & Fehlmann Expires July 14, 2019 [Page 44]
Internet-Draft RAINS January 2019
the delegated query as on the received query, unless option 6 Enable
Tracing is present in the received query, in which case it MUST use
the same token.
5.9. Capabilities
The capabilities (1) key in a RAINS message allows the sender of that
message to communicate its capabilities to its peer. Capabilities
MUST be sent on the first message sent from one peer to another.
A peer's capabilities can be represented in one of two ways:
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.
If a peer receives a message from a counterpart for which it does not
have the hash of the capabilities, it can ask for the next message to
contain a list of these capabilities by sending a message containing
notification 399.
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,
The following URNs are presently defined; other URNs will specify
future optional features, support for alternate transport protocols
and new signature algorithms, and so on.
+--------------------+----------------------------------------------+
| URN | Meaning |
+--------------------+----------------------------------------------+
| urn:x-rains:tlssrv | Listens for TLS/TCP connections (see Section |
| | 6.1.1 |
+--------------------+----------------------------------------------+
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 redirection and service-info
Assertions for a named zone) or from external configurations.
Trammell & Fehlmann Expires July 14, 2019 [Page 45]
Internet-Draft RAINS January 2019
6. RAINS Protocol
RAINS is a message-exchange protocol based around a CBOR data model.
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 messages requires no external framing, and can be carried on a
variety of transport protocols.
These transport bindings serve to transfer Messages containing
Queries toward servers that can answer them, and to transfer
Assertions toward clients that have indicated an interest in them.
The interpretation and action implied by the arrival of a RAINS
Message at a peer is not affected by the transport used to send it.
6.1. Transport Bindings
This document defines one transport binding for RAINS: TLS-over-TCP
in Section 6.1.1. Each transport binding offers a different set of
tradeoffs. Carrying RAINS Messages over persistent TLS 1.3 (or
later) connections [RFC8446] over TCP [RFC0793] protects query
confidentiality and integrity while supporting implementation over a
ubiquitously-available and well-understood security and transport
layer.
6.1.1. TLS over TCP
RAINS servers listen on port 55553 by default. Note that no effort
has yet been made to assign this port at IANA; should RAINS be
standardized, another port may be chosen. Servers may listen on
other TCP ports subject to local configuration. Methods for
discovering servers and configuring clients MUST allow for the
specification of an alternate port. Servers providing authority
service should use service information records (Section 5.3.8) to
specify a port on a service name specified by redirection object(s)
for the zone; see Section 7.2.
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.
A RAINS client configured to use one or more servers for query
service should strive to keep connections open to those servers.
RAINS servers MUST accept Messages over TCP up to 65536 bytes in
length, but MAY accept messages of greater length, subject to
Trammell & Fehlmann Expires July 14, 2019 [Page 46]
Internet-Draft RAINS January 2019
resource limitations of the server. A server with resource
limitations MUST 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 singular 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.
6.1.2. Heartbeat Messages
TCP connections between RAINS clients and servers may be associated
with in-network state (such as firewall pinholes and/or network
address translation cache entries) with relatively short idle
timeouts. RAINS provides a simple heartbeat mechanism to refresh
this state for long-running connections.
A RAINS peer may send its peer a 100 Connection Heartbeat
notification at any time. This message is ignored by the receiving
peer.
6.2. Protocol Dynamics
This section illustrates how the RAINS protocol works with one
possible set of rules for handling incoming messages and sending
outgoing messages as a RAINS server; however, the actions here and
the sequence in which they are applied are meant only as one
possibility for implementors, and are not normative.
6.2.1. Message Processing
Once a transport connection 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 & Fehlmann Expires July 14, 2019 [Page 47]
Internet-Draft RAINS January 2019
If the server or client can parse the message, it:
o notes the token on the message to send on any message generated in
reply to the 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 6.3), and 404 No Assertion Exists
notifications are not accepted by servers. If a message contains
an unacceptable section, the server or client returns a 406
Message Not Acceptable for Service notification to its peer, and
ceases processing of the message.
It then processes each sections acoording to the rules below.
On receipt of an Assertion (Singular Assertion, Shard, P-Shard, or
Zone) section, a server:
o verifies its consistency (see Section 6.5). 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 (Singular Assertion, Shard, P-Shard, or
Zone) 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.
Trammell & Fehlmann Expires July 14, 2019 [Page 48]
Internet-Draft RAINS January 2019
On receipt of a query, a server:
1. determines whether it has expired by checking the query-expires
value. If so, it drops the query silently. If not, it
2. determines whether it has at least one stored assertion
containing a positive answer to the query. If so, it checks to
see if the assertion is newer than the current-time value in the
query, if present. If the assertion is not newer, it prepares to
send a notification of type 304 ("Querier Has Latest Answer") to
the peer. Otherwise, it prepares a message containing the stored
assertion(s) positively answering the query. If no positive
assertion is available, it
3. checks to see whether it has at least one stored proof of
nonexistence (shard or p-shard) for the query. If so, it
prepares a message containing the negative proof to the peer. It
prefers P-Shards to Shards for reasons of efficiency, but must
verify that any P-shard does indeed function as a negative proof
before sending it.
4. 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.5.1). 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:
5. 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.
Query options (see Section 5.5.1) change this handling. If query
option 4 ("cached answers only") is set, steps 4 and 5 above are
skipped, and the server returns a 504 ("No Assertion Available")
notification instead. If query option 9 ("Maximize Freshness") is
set, the server might forward a query even if it has a cached answer.
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 does not use the same token on
Trammell & Fehlmann Expires July 14, 2019 [Page 49]
Internet-Draft RAINS January 2019
the delegated query as on the received query, unless option 6
("Enable Tracing") is present in the received query, in which case it
does use the same token. The Enable Tracing option is designed to
allow debugging of query processing across multiple servers.
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
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, or logs the
error along with the note-data content.
o For type 400 "Bad message", type 403 "Inconsistent message", type
406 "not supported for service", or type 500 "Server error", 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 304 "Querier has newest assertion", the client notes that
its cache is up-to-date for the given query.
Trammell & Fehlmann Expires July 14, 2019 [Page 50]
Internet-Draft RAINS January 2019
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.
o For type 413 "Message too large" the client notes that large
messages may not be sent to a peer and tries again, or logs the
error along with the note-data content.
o For type 400 "Bad message", type 403 "Inconsistent message", type
406 "not acceptable for service", of type 500 "Server error", 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.9.
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 sends a message containing a type 100 Connection
Heartbeat notification after a configured idle time without any
messages containing other content being sent.
6.2.2. Message Transmission
As noted in Section 6.2.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.
Trammell & Fehlmann Expires July 14, 2019 [Page 51]
Internet-Draft RAINS January 2019
6.3. Client Protocol
The protocol used by clients to issue queries to and receive
responses from a 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 406
Unacceptable notification.
o Clients never listen for connections via TCP; 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 406 Unacceptable 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.
6.4. 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 406 Unacceptable
notification. Servers only process notifications for capability
negotiation purposes (see Section 5.9).
o Publishers only process notification sections; sending a query or
assertion to a publisher results in a 406 Unacceptable
notification.
6.5. Enforcing Assertion Consistency
The data model used by the RAINS protocol allows inconsistent
information to be asserted, all resulting from misconfigured or
Trammell & Fehlmann Expires July 14, 2019 [Page 52]
Internet-Draft RAINS January 2019
misbehaving authority servers. The following types of inconsistency
are possible:
o A Zone omits an Assertion which has the same validity start time
as said Assertion.
o A Shard omits an Assertion within its range which has the same
validity start time as said Assertion.
o A P-Shard with a given validity start time proves nonexistence of
an Assertion with the same validity start time.
o An Assertion prohibited by its Aone's nameset has the same
validity start time as the prohibiting nameset Assertion.
o A zone contains a valid reflexive assertion of a given object type
with the same validity start time as a valid assertion of the same
type for the same name within a supordinate zone, but with a
different object value.
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 inconsistent
assertions, shards, and zones in its cache, log the error, and send a
403 Inconsistent Message to the source of the message.
For RAINS to work in a highly dynamic environment, some time-bounded
inconsistencies are allowed to occur. On the one hand, the authority
wants to prove nonexistence of a name for a duration of time to make
caching possible to reduce query latency and reduce load on its
naming servers. On the other hand, the authority would like the
flexibility to issue new assertions about previously nonexistent
names without waiting for a previous negative proof to expire.
Therefore, the defintions of inconsistency above are strictly limited
to identical (and therefore non-orderable) validity start times.
7. Operational Considerations
The following subsections discuss issues that must be considered in
any deployment of RAINS at scale.
Trammell & Fehlmann Expires July 14, 2019 [Page 53]
Internet-Draft RAINS January 2019
7.1. Discovering RAINS servers
A client that will not do its own verification must be able to
discover the query server(s) it should trust for resolution. There
are three broad approaches to this discovery process: (1) static
client configuration; (2) server configuration as part of dynamic
host interface configuration, such as DHCP or provisioning domains;
(3) discovery of a RAINS server as an optional service, for example
using mDNS. Integration with any of these approaches is
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.
Servers providing query and intermediate service also discover other
intermediate servers through static configuration, or through an
external, unspecified discovery protocol.
Servers providing query and intermediate service discover servers
providing authority service as in Section 7.2, below.
7.2. Bootstrapping RAINS Services
At startup, a server performing recursive lookup MUST have access to
at least one of each of these three assertion types: a self-signed
delegation assertion of the root zone, a redirection assertion
containing the name of an authoritative root name server, and an ip4
or ip6 assertion of the root name server mentioned in the redirection
assertion. These assertions must be obtained through a secure out of
band mechanism. For a caching server, it is sufficient to have a
connection to a recursive resolver which does the lookup on its
behalf.
When a zone authority delegates a part of its namespace to a
subordinate, it MUST sign and serve the assertions of the three above
mentioned types. This information is necessary for a recursive
resolver to determine in a recursive lookup where to ask for a more
specific answer and to validate the response.
7.3. 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
Trammell & Fehlmann Expires July 14, 2019 [Page 54]
Internet-Draft RAINS January 2019
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.
7.4. 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.
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.
7.5. 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.
7.6. 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.
Trammell & Fehlmann Expires July 14, 2019 [Page 55]
Internet-Draft RAINS January 2019
7.6.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.
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.
7.6.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.
Trammell & Fehlmann Expires July 14, 2019 [Page 56]
Internet-Draft RAINS January 2019
8. 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.
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.
9. 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.
9.1. 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 6.3).
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 nonexistence of an assertion is not
designed to provide resistance against zone enumeration.
Trammell & Fehlmann Expires July 14, 2019 [Page 57]
Internet-Draft RAINS January 2019
On the other hand, confidentiality protection of query information is
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.
10. 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 by
default on TCP port 7753. This port has not been registered with
IANA, and is intended only for experimentation with RAINS on closed,
non-Internet-connected networks. Future revisions of this document
may specify a different port, registered with IANA via Expert Review
[RFC5226].
The urn:x-rains namespace used by the RAINS capability mechanism in
Section 5.9 may be a candidate for replacement with an IANA-
registered namespace in a future revision of this document.
11. Acknowledgments
Thanks to Daniele Asoni, Laurent Chuat, Markus Deshon, Ted Hardie,
Joe Hildebrand, Tobias Klausmann, Steve Matsumoto, Adrian Perrig,
Raphael Reischuk, Wendy Seltzer, Andrew Sullivan, and Suzanne Woolf
for the discussions leading to the design of this protocol, and the
definition of an ideal naming service on which it is based. Thanks
especially to Stephen Shirley for detailed feedback.
12. References
12.1. Normative References
[FIPS-186-3]
NIST, ., "Digital Signature Standard FIPS 186-3", June
2009.
Trammell & Fehlmann Expires July 14, 2019 [Page 58]
Internet-Draft RAINS January 2019
[FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen,
"The FNV Non-Cryptographic Hash Algorithm", draft-
eastlake-fnv-16 (work in progress), December 2018.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[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>.
[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>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[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>.
[RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature
Algorithm (EdDSA) Signatures in the Cryptographic Message
Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August
2018, <https://www.rfc-editor.org/info/rfc8419>.
Trammell & Fehlmann Expires July 14, 2019 [Page 59]
Internet-Draft RAINS January 2019
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
12.2. Informative References
[BETTER-BLOOM-FILTER]
Adam Kirsch, . and . Michael Mitzenmacher, "Building a
Better Bloom Filter", May 2008.
[I-D.ietf-dprive-dns-over-tls]
Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over TLS", draft-
ietf-dprive-dns-over-tls-09 (work in progress), March
2016.
[I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "Specification for DNS
over Datagram Transport Layer Security (DTLS)", draft-
ietf-dprive-dnsodtls-15 (work in progress), December 2016.
[I-D.trammell-optional-security-not]
Trammell, B., "Optional Security Is Not An Option", draft-
trammell-optional-security-not-00 (work in progress),
March 2018.
[IAB-UNICODE7]
IAB, ., "IAB Statement on Identifiers and Unicode 7.0.0",
n.d., <https://www.iab.org/documents/
correspondence-reports-documents/2015-2/
iab-statement-on-identifiers-and-unicode-7-0-0/>.
[LUCID] Freytag, A. and A. Sullivan, "LUCID problem (slides, IETF
92 LUCID BoF)", n.d.,
<https://www.ietf.org/proceedings/92/slides/
slides-92-lucid-0.pdf>.
[PARSER-BUGS]
Bratus, S., Patterson, M., and A. Shubina, "The Bugs We
Have To Kill (USENIX login)", August 2015.
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-17 (work
in progress), December 2018.
Trammell & Fehlmann Expires July 14, 2019 [Page 60]
Internet-Draft RAINS January 2019
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[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>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[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>.
[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>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
Trammell & Fehlmann Expires July 14, 2019 [Page 61]
Internet-Draft RAINS January 2019
[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>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>.
[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 Capabilities", February 2008.
Authors' Addresses
Brian Trammell
ETH Zurich
Universitaetstrasse 6
Zurich 8092
Switzerland
Email: ietf@trammell.ch
Trammell & Fehlmann Expires July 14, 2019 [Page 62]
Internet-Draft RAINS January 2019
Christian Fehlmann
ETH Zurich
Email: fehlmannch@gmail.com
Trammell & Fehlmann Expires July 14, 2019 [Page 63]