RAINS (Another Internet Naming Service) Protocol Specification
draft-trammell-rains-protocol-01
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".
|
|
|---|---|---|---|
| Author | Brian Trammell | ||
| Last updated | 2016-11-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-01
Names and Identifiers Program B. Trammell
Internet-Draft ETH Zurich NetSec
Intended status: Experimental November 23, 2016
Expires: May 27, 2017
RAINS (Another Internet Naming Service) Protocol Specification
draft-trammell-rains-protocol-01
Abstract
This document defines an alternate protocol for Internet name
resolution, designed as a prototype to facilitate conversation about
the evolution or replacement of the Domain Name System protocol. It
attempts to answer the question: "how would we design DNS knowing
what we do now," on the background of the properties of an ideal
naming service described in [I-D.trammell-inip-pins].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://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 May 27, 2017.
Copyright Notice
Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Trammell Expires May 27, 2017 [Page 1]
Internet-Draft RAINS November 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Information Model . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Context in Assertions . . . . . . . . . . . . . . . . 8
4.1.2. Signatures in Assertions . . . . . . . . . . . . . . 9
4.1.3. Shards and Zones . . . . . . . . . . . . . . . . . . 10
4.2. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Context in Queries . . . . . . . . . . . . . . . . . 11
4.2.2. Answers to Queries . . . . . . . . . . . . . . . . . 12
4.3. Address to Object Mapping . . . . . . . . . . . . . . . . 13
4.3.1. Context in Address Assertions . . . . . . . . . . . . 14
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Symbol Table . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Message Section header . . . . . . . . . . . . . . . . . 17
5.4. Assertion body . . . . . . . . . . . . . . . . . . . . . 18
5.5. Shard body . . . . . . . . . . . . . . . . . . . . . . . 19
5.6. Zone Message Section body . . . . . . . . . . . . . . . . 20
5.7. Query Message Section body . . . . . . . . . . . . . . . 20
5.8. Address Assertion Message Section body . . . . . . . . . 23
5.9. Address Zone Message Section body . . . . . . . . . . . . 24
5.10. Address Query Message Section body . . . . . . . . . . . 25
5.11. Notification Message Section body . . . . . . . . . . . . 25
5.12. Object . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.12.1. Certificate information format . . . . . . . . . . . 29
5.12.2. Name expression format . . . . . . . . . . . . . . . 30
5.13. Tokens in queries and messages . . . . . . . . . . . . . 31
5.14. Signatures, delegation keys, and RAINS infrastructure
keys . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.14.1. ECDSA signature and public key format . . . . . . . 33
5.15. Capabilities . . . . . . . . . . . . . . . . . . . . . . 34
6. RAINS Protocol Definition . . . . . . . . . . . . . . . . . . 35
6.1. Message processing . . . . . . . . . . . . . . . . . . . 35
6.2. Message Transmission . . . . . . . . . . . . . . . . . . 39
6.3. Message Limits . . . . . . . . . . . . . . . . . . . . . 39
6.4. Runtime Consistency Checking . . . . . . . . . . . . . . 40
6.5. Integrity and Confidentiality Protection . . . . . . . . 40
7. RAINS Client Protocol . . . . . . . . . . . . . . . . . . . . 41
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 41
8.1. Assertion Lifetime Management . . . . . . . . . . . . . . 41
8.2. Secret Key Management . . . . . . . . . . . . . . . . . . 42
Trammell Expires May 27, 2017 [Page 2]
Internet-Draft RAINS November 2016
8.3. Unsigned Contained Assertions . . . . . . . . . . . . . . 42
8.4. Query Service Discovery . . . . . . . . . . . . . . . . . 42
8.5. Transition using translation between RAINS and DNS
information models . . . . . . . . . . . . . . . . . . . 42
9. Experimental Design and Evaluation . . . . . . . . . . . . . 44
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
11. Security Considerations . . . . . . . . . . . . . . . . . . . 45
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Directions for future experimentation . . . . . . . 48
A.1. Revocation based on hash chains . . . . . . . . . . . . . 48
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 50
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction
This document defines an experimental protocol for providing Internet
name resolution services, as a replacement for DNS, called RAINS
(RAINS, Another Internet Naming Service). It is designed as a
prototype to facilitate conversation about the evolution or
replacement of the Domain Name System protocol, and was developed as
a name resolution system for the SCION ("Scalability, Control, and
Isolation on Next-Generation Networks") future Internet architecture
[SCION]. It attempts to answer the question: "how would we design
the DNS knowing what we do now," on the background of the properties
of an ideal naming service described in [I-D.trammell-inip-pins].
Its architecture (Section 3) and information model (Section 4) are
largely compatible with the existing Domain Name System. However, it
does take several radical departures from DNS as presently defined
and implemented:
o Delegation from a superordinate zone to a subordinate zone is done
solely with cryptography: a superordinate defines the key(s) that
are valid for signing assertions in the subordinate during a
particular time interval. Assertions about names can therefore
safely be served from any infrastructure.
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
Trammell Expires May 27, 2017 [Page 3]
Internet-Draft RAINS November 2016
context explicitly separates global usage of the DNS from local
usage thereof, and allows other application-specific naming
constraints to be bound to names; see Section 4.1.1. Queries are
valid in one or more contexts, with specific rules for determining
which assertions answer which queries; see Section 4.2.1.
o There is an explicit separation between registrant-level names and
sub-registrant-level names, and explicit information about
registrars and registrants available in the naming system at
runtime.
o Sets of valid characters and rules for valid names are defined on
a per-zone basis, and can be verified at runtime.
o Reverse lookups are done using a completely separate tree,
supporting delegations of any prefix length, in accordance with
CIDR [RFC4632] and the IPv6 addressing architecture [RFC4291].
Instead of using a custom binary framing as DNS, RAINS uses Concise
Binary Object Representation [RFC7049], partially in an effort to
make implementations easier to verify and less likely to contain
potentially dangerous parser bugs [PARSER-BUGS]. Like DNS, CBOR
messages can be carried atop any number of substrate protocols; RAINS
is presently defined to use TLS over persistent TCP connections (see
Section 6).
2. Terminology
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY, when they
appear in all-capitals, are to be interpreted as defined in
[RFC2119].
In addition, the following terms are used in this document as
defined:
o Authority: An entity which may make assertions about names in a
zone, by virtue of holding a secret key which can generate
signatures verifiable using a public key associated with a
delegation to the zone.
o Assertion: A mapping between a name and object(s) of specified
types describing the name, signed by an authority for the zone
containing the subject name. See Section 4.1.
o Subject: The name to which an assertion pertains.
o Object: A type/value pair of information about a name within an
assertion.
Trammell Expires May 27, 2017 [Page 4]
Internet-Draft RAINS November 2016
o Query: An expression of interest in certain types of objects
pertaining to a subject name in one or more contexts. See
Section 4.2.
o Context: Additional information about the scope in which an
assertion or query is valid. See Section 4.1.1 and Section 4.2.1.
o Shard: A group of assertions common to a zone, with common
signatures, which may be lexicographically complete for purposes
of proving nonexistence of an assertion. See Section 4.1.3.
o Zone: A group of all assertions valid at a given point in time,
with common signatures, for a given level of delegation and
context within the namespace. See Section 4.1.3.
o RAINS Message: Unit of exchange in the RAINS protocol, containing
assertions, shards, zones, queries, and notifications. See
Section 5.2.
o Notification: A RAINS-internal message section carrying
information about the operation of the protocol itself. See
Section 5.11.
o Authority Service: A service provided by a RAINS Server for
publishing assertions by an authority. See Section 3.
o Query Service: A service provided by a RAINS Server for answering
queries on behalf of a RAINS Client. See Section 3.
o Intermediary Service: A service provided by a RAINS Server for
answering queries and providing temporary storage for assertions
on behalf of other RAINS Servers. See Section 3.
o RAINS Server: A server that speaks the RAINS Protocol, and
provides on or more services on behalf of other RAINS Servers and/
or RAINS Clients. See Section 3.
o RAINS Client: A client that uses the Query Service of one or more
RAINS Servers to retrieve assertions on behalf of applications
that wish to connect to named services in the Internet.
3. Architecture
The RAINS architecture is simple, and resembles the architecture of
DNS. A RAINS Server is an entity that provides transient and/or
permanent storage for assertions about names, and a lookup function
that finds assertions for a given query about a name, either by
Trammell Expires May 27, 2017 [Page 5]
Internet-Draft RAINS November 2016
searching local storage or by delegating to another RAINS server.
RAINS servers can take on any or all of three roles:
o authority service, acting on behalf of an authority to ensure
properly signed assertions are made available to the system
(equivalent to an authoritative server in DNS);
o query service, acting on behalf of a client to answer queries with
relevant assertions (equivalent to a recursive resolver in DNS),
and to validate assertions on the client's behalf; and/or
o intermediary service, acting on behalf of neither but providing
storage and lookup for assertions with certain properties for
query and authority servers (partially replacing, but not really
equivalent to, caching resolvers in DNS).
RAINS Servers use the RAINS Protocol defined in this document to
exchange queries and assertions. RAINS Clients use a subset variant
of the RAINS Protocol (called the RAINS Client Protocol) to interact
with RAINS Servers providing query services on their behalf.
4. Information Model
Messages in the RAINS Protocol are made up of two kinds of elements:
Assertion and Query.
The information model in this section omits information elements
required by the resolution mechanism itself; these are defined in
more detail in Section 5 and Section 6.
4.1. Assertion
An Assertion is a signed statement about a mapping from a subject
name to an object value, and consists of the following elements:
o Context: name of the context in which the assertion is valid; see
Section 4.1.1 below.
o Subject: name about which the assertion is made.
o Zone: name of the zone in which the assertion is made. The fully
qualified name of the subject is made by appending the zone name
to the subject name with a domain name separator ('.').
o Type: the type of information about the Subject contained in the
assertion. Each Assertion is about a single type of data.
o Object: the data of the indicated type associated with the Subject
Trammell Expires May 27, 2017 [Page 6]
Internet-Draft RAINS November 2016
o Signatures: one or more signatures generated by the authority for
the Assertion. Signatures contain a time interval during which
they are considered valid, and may contain a revocation token
allowing them to be revoked before the end of the time interval.
See Section 4.1.2 below.
The Types supported for each assertion are:
o Delegation: the authority associated with the zone identified by
the name (roughly equivalent to the DNSSEC DS RRTYPE). The Object
contains a public key by which the authority can be identified.
o Redirection: The name(s) of one or more a RAINS servers providing
authority service for the authority associated with the zone
(roughly equivalent to the DNSSEC NS RRTYPE, but not always
consulted directly during resolution). The Object contains a set
of names.
o Address: one or more addresses associated with the name (replaces
DNS A and AAAA RTYPEs). The Object contains a set of Addresses.
An Address is an {address-family, value} tuple.
o Service-Info: one or more layer 4 ports and hostnames associated
with a service name (replaces DNS SRV RRTYPE). The object
contains a {hostname, port-number, priority tuple}.
o Name: one or more names associated with the name (roughly
equivalent to DNS CNAME). The Object contains a set of names.
o Certificate: a certificate which must appear at a specified
location in the certificate chain presented on a connection
attempt with the named entity (roughly equivalent to DNS TLSA).
The details of this type will be described in a separate document.
o Zone-Nameset: an expression of the set of names allowed within a
zone; e.g. Unicode scripts or codepages in which names in the
zone may be issued. This allows a zone to set policy on names in
support of the distinguishability property in
[I-D.trammell-inip-pins] that can be checked by RAINS servers at
runtime. An assertion about a Subject within a Zone whose name is
not allowed by a valid signed Zone-Nameset expression is taken to
be invalid, even if it has a valid signature. The details of this
type will be described in a separate document.
o Zone-Registrar: Information about the organization that caused a
Subject name to exist, for registrant-level names.
Trammell Expires May 27, 2017 [Page 7]
Internet-Draft RAINS November 2016
o Zone-Registrant: Information about the organization responsible
for a Subject name, for registrant-level names.
For a given {subject, type} tuple, multiple assertions can be valid
at a given point in time; the union of the object values of all of
these assertions is considered to be the set of valid values at that
point in time.
4.1.1. Context in Assertions
Assertion contexts are used to determine the validity of the
signature by the declared authority as follows:
o The global context is identified by the special context name `.'.
Assertions in the global context are signed by the authority for
the subject name. For example, assertions about the name
simplon.inf.ethz.ch in the global context are only valid if signed
by the relevant authority inf.ethz.ch.
o A local context is associated with a given authority. The
authority-part and the context-part of a local context name are
divided by a context marker ('cx-'). The authority-part directly
identifies the authority whose key was used to sign the assertion;
assertions within a local context are only valid if signed by the
identified authority. Authorities have complete control over how
the contexts under their namespaces are arranged, and over the
names within those contexts.
Assertion context is the mechanism by which RAINS provides explicit
inconsistency (see section 5.3.2 of [I-D.trammell-inip-pins]). Some
examples illustrate how context works:
o For the common split-DNS case, an enterprise could place names for
machines on its local networks within a separate context. E.g., a
workstation could be named simplon.cab.inf.ethz.ch within the
context staff-workstations.cx-.inf.ethz.ch. Assertions about this
name would be signed by the authority for inf.ethz.ch. Here, the
context serves simply as a marker, without enabling an alternate
signature chain: note that the name simplon.cab.inf.ethz.ch can be
validly signed by the authority for inf.ethz.ch if no delegation
exists for cab.inf.ethz.ch. The context simply marks this
assertion as internal. This allows a client making requests of
local names to know they are local, and for local resolvers to
manage visibility of assertions outside the enterprise: explicit
context makes accidental leakage of both queries and assertions
easier to detect and avoid.
Trammell Expires May 27, 2017 [Page 8]
Internet-Draft RAINS November 2016
o Contexts make captive-portal interactions more explicit: a captive
portal resolver could respond to a query for a common website
(e.g. www.google.ch) with a signed response directed at the
captive portal, but within a context identifying the location as
well as the ISP (e.g. sihlquai.zurich.ch.cx-
.starbucks.access.some-isp.net.). This response will be signed by
the authority for starbucks.access.some-isp.net. This signature
achieves two things: first, the client knows the result for
www.google.ch is not globally valid; second, it can present the
user with some indication as to the identity of the captive portal
it is connected to.
Further examples showing how context can be used in queries as well
are given in Section 4.2.1 below.
Developing conventions for assertion contexts for different
situations will require implementation and deployment experience, and
is a subject for future work.
4.1.2. Signatures in Assertions
A signature over an assertion contains the following information
elements:
o Algorithm: identifier of the algorithm used to generate the
signature.
o Valid-Since: a timestamp of the start of validity of this
signature.
o Valid-Until: a timestamp of the end of validity of this signature.
o Signature: the cryptographic signature itself, whose format is
determined by the algorithm used.
o Revocation-Token: an optional revocation token for this signature,
which allows a signature to be replaced or removed before the end
of its validity. Revocation tokens are generally based on hash
chains, meaning that a signature with a revocation token "down"
the chain from a given token supercedes it. The format and
mechanism used by the revocation token is determined by the
alogrithm used. (Note that revocation is a presently unspecified
feature in the protocol; see Appendix A.1.)
The signature protects all the information in an assertion as well as
its own valid-since and valid-until values and the revocation token;
it does not protect other signatures on the assertion.
Trammell Expires May 27, 2017 [Page 9]
Internet-Draft RAINS November 2016
4.1.3. Shards and Zones
Assertions may also be grouped and signed as a group. A shard is a
set of assertions subject to the same authority within the same
context, protected by one or more signatures over all assertions
within the shard. A shard may have an additional property that given
a subject and an authenticated shard, it can be shown that either an
assertion with a given name and type exists within the shard or does
not exist at all.
A shard has the following information elements:
o Context: name of the context in which the assertions in the shard
are valid; see Section 4.1.1 above.
o Zone: name of the zone in which the assertions are made.
o Content: a set of assertions sharing the context and zone.
o Signatures: one or more signatures generated by the authority for
the shard; see Section 4.1.2.
o Complete-Flag: if true, the shard is lexicographically complete,
and subject names that sort such that they would be within the
shard if they existed, but are not in the shard, can be assumed
not to exist.
For efficiency's sake, information elements within a shard common to
all assertions (zone, context, signature) within the shard may be
omitted from the assertions themselves.
A zone is the entire set of shards subject to a given authority
within a given context. There are three kinds of zones; treating
these zones differently may allow lookup protocol optimizations:
o Zones containing only delegation assertions are delegation-only
zones. Delegation-only zones are not relevant as part of an
assertion lookup, other than for discovering and verifying
authority. Top-level domains are generally delegation-only.
o Zones containing no delegation assertions are final zones. Final
zones are not relevant as part of an authority discovery.
o Zones containing at least one delegation assertion and at least
one assertion that is not a delegation assertion are mixed zones.
No optimizations are available for mixed zones.
A zone has the following information elements:
Trammell Expires May 27, 2017 [Page 10]
Internet-Draft RAINS November 2016
o Context: name of the context in which the assertions in the zone
are valid; see Section 4.1.1 above.
o Zone: name of the zone.
o Content: a set of assertions and/or shards sharing the context and
zone.
o Signatures: one or more signatures generated by the authority for
the shard; see Section 4.1.2.
o Kind: delegation-only, final, or mixed; see above.
4.2. Query
A query is a request for a set of assertions supporting a conclusion
about a given subject-object mapping. It consists of the following
information elements:
o Contexts: an expression of the context(s) in which assertions
answering the query will be accepted; see Section 4.2.1 below.
o Qualified-Subject: the name about which the query is made. The
subject name in a query must be fully-qualified.
o Types: a set of assertion types the querier is interested in.
o Valid-Until: an optional client-generated timestamp for the query
after which it expires and should not be answered.
o Query Token: a client-generated token for the query, which can be
used in the answer to refer to the query.
A query expresses interest about all the given types of assertion in
all the specified contexts; more complex expressions of which types
in which contexts must be asked using multiple queries. Preferences
for tradeoffs (freshness, bandwidth efficiency, latency, privacy
preservation) in servicing a query may be bound to the query using
query options.
4.2.1. Context in Queries
Contexts are used in queries as they are in assertions (see
Section 4.1.1). Assertion contexts in an answer to a query have to
match some context in the query in order to respond to a query.
However, there are a few additional considerations. An assertion can
only exist with a specific context, while queries may accept answers
in multiple contexts. The Contexts part of a query is a sequence of
Trammell Expires May 27, 2017 [Page 11]
Internet-Draft RAINS November 2016
context specifiers taken to be in order of decreasing priority. A
special null context (represented by the empty string) indicates that
assertions in any context will be accepted. Any context in the
Contexts part of a query may additionally be negated, in order to
note that assertions in those contexts are not acceptable. Negated
context name appearing in the Contexts part of a query before the
null context expresses "any context except these".
Query contexts can also be used to provide additional information to
RAINS servers about the query. For example, contexts 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
reflecting the goodness of the zone for the client. Here, a context
might be zrh.cx-.cdn-zones.some-cdn.com for names of servers hosting
content in a CDN's Zurich data center, and a client could represent
its desire to find content nearby by making queries in the zrh.cx-,
fra.cx- (Frankfurt), and ams.cx- (Amsterdam) contexts within cdn-
zones .some-cdn.com. In all cases, the assertions themselves will be
signed by the authority for cdn-zones.some-cdn.com, accurately
representing that it is the CDN, not the owner of the related name in
the global context, that is making the assertion.
As with assertion contexts, developing conventions for query contexts
for different situations will require implementation and deployment
experience, and is a subject for future work.
4.2.2. Answers to Queries
An answer consists of a set of assertions, shards, and/or zones which
respond to a query. If the query contained a token, it is bound to
that query via the token.
The content of an answer depends on whether the answer is positive or
negative. A positive answer contains the information requested in
the smallest atomic container that can be found, usually a single
assertion. A negative answer contains the information used to verify
it; either a shard with the Complete-Flag set, an entire Zone, or a
Zone-Nameset assertion showing the name is illegal within the zone.
A query is taken to have an inconclusive answer when no answer
returns to the querier before the query's Valid-Until time.
Trammell Expires May 27, 2017 [Page 12]
Internet-Draft RAINS November 2016
4.3. Address to Object Mapping
In contrast to the current domain name system, information about
addresses is stored in a completely separate tree, keyed by address
and prefix. An address assertion consists of the following elements:
o Context: name of the context in which the assertion is valid; see
Section 4.3.1.
o Subject: address about which the assertion is made, consisting of
an address family, address, and prefix length. A subject may be a
network address (where the prefix length is less than the address
length for the given address family) or a host address (where the
prefix length is equal to the address length for the given address
family)
o Type: the type of information about the Subject contained in the
assertion. Each Assertion is about a single type of data.
o Object: the data of the indicated type associated with the Subject
o Signatures: one or more signatures generated by the authority for
the Assertion. Signatures contain a time interval during which
they are considered valid, and may contain a revocation token
allowing them to be revoked before the end of the time interval,
as in Section 4.1.2.
The following object types are available:
o Delegation: the authority associated with the subject network
address. The Object contains a public key by which the authority
can be identified. Only available for network address subjects.
o Redirection: The name(s) of one or more a RAINS servers providing
authority service for the authority associated with the subject
network address. The Object contains a set of names. Only
available for network address subjects.
o Name: one or more names associated with the subject network
address. The Object contains a set of names. Only available for
host address subjects.
o Zone-Registrant: Information about the organization responsible
for a network. Only available for network address subjects.
Assertions about addresses can be grouped into Zones. An address
Zone has the following information elements:
Trammell Expires May 27, 2017 [Page 13]
Internet-Draft RAINS November 2016
o Context: name of the context in which the assertions in the zone
are valid; see Section 4.3.1.
o Zone: subject address of the zone, consisting of an address
family, address, and prefix length. The prefix length must be
less than the address length for the given address family.
o Content: a set of assertions and/or shards sharing the context and
zone.
o Signatures: one or more signatures generated by the authority for
the shard; see Section 4.1.2.
Queries for addresses are similar to those for names, and consist of
the following information elements:
o Context: Context in which the query is made; this must match the
assertion context as in Section 4.3.1.
o Subject: the address about which the query is made, consisting of
an address family, address, and prefix length.
o Types: a set of assertion types the querier is interested in, as
above.
o Valid-Until: an optional client-generated timestamp for the query
after which it expires and should not be answered.
o Query Token: a client-generated token for the query, which can be
used in the answer to refer to the query.
4.3.1. Context in Address Assertions
Just as in forward Assertions, Assertion contexts are used in address
assertions to determine the scope of an address assertion, and the
signature chain used to verify it.
o The global addressing context for each address family is
identified by the special context name `.'. For both IPv4 and
IPv6 addresses, this is rooted at IANA, which delegates to the
RIRs, which then delegates to LIRs and to address-holding
registries.
o Local contexts associated with a given authority in a forward tree
can also make assertions about addresses. As with contexts in
forward assertions, the authority-part and the context-part of a
local context name are divided by a context marker ('cx-'). The
authority-part directly identifies the authority whose key was
Trammell Expires May 27, 2017 [Page 14]
Internet-Draft RAINS November 2016
used to sign the assertion; assertions within a local context are
only valid if signed by the identified authority. Authorities
have complete control over how the contexts under their namespaces
are arranged, and over the names within those contexts.
Each local context may have a root address space zone (0/0), but
these root address spaces may only delegate addresses that are
reserved for local use [RFC1918] [RFC4193]. Local context assertions
for other addresses are invalid.
5. Data Model
The RAINS data model is a relatively straightforward mapping of the
information model in Section 4 to the Concise Binary Object
Representation (CBOR) [RFC7049], with an outer message type providing
a mechanism for future capabilities-based versioning and recognition
of a message as a RAINS message.
Messages, assertions, shards, zones, queries, and notifications are
each represented as a CBOR map of integer keys to values, which
allows each of these types to be extended in the future, as well as
the addition of non- standard, application-specific information to
RAINS messages and data items. A common registry of map keys is
given in Table 1. RAINS implementations MUST ignore map keys the do
not understand. Integer map keys in the range -22 to +23 are
reserved for the use of future versions or extensions to the RAINS
protocol.
Message contents, signatures and object values are implemented as
type- prefixed CBOR arrays with fixed meanings of each array element;
the structure of these lower-level elements can therefore not be
extended. Message section types are given in Table 2, object types
in Table 5, and signature algorithms in Table 9.
5.1. Symbol Table
The meaning of each of the integer keys in message, zone, shard,
assertion, and notification maps is given in the symbol table below:
Trammell Expires May 27, 2017 [Page 15]
Internet-Draft RAINS November 2016
+------+----------------+-------------------------------------------+
| Code | Name | Description |
+------+----------------+-------------------------------------------+
| 0 | signatures | Signatures on a message or section |
| | | |
| 1 | capabilities | Capabilities of server sending message |
| | | |
| 2 | token | Token for referring to a data item |
| | | |
| 3 | subject-name | Subject name in an assertion |
| | | |
| 4 | subject-zone | Zone name in an assertion |
| | | |
| 5 | subject-addr | Subject address in address assertion or |
| | | zone |
| | | |
| 6 | context | Context of an assertion |
| | | |
| 7 | objects | Objects of an assertion |
| | | |
| 8 | query-name | Fully qualified name for a query |
| | | |
| 9 | query-contexts | Contexts acceptable in query answers |
| | | |
| 10 | query-types | Acceptable object types for query |
| | | |
| 11 | shard-range | Lexical range of Assertions in Shard |
| | | |
| 12 | query-expires | Absolute timestamp for query expiration |
| | | |
| 13 | query-opts | Set of query options requested |
| | | |
| 21 | note-type | Notification type |
| | | |
| 22 | note-data | Additional notification data |
| | | |
| 23 | content | Content of a message, shard, or zone |
+------+----------------+-------------------------------------------+
Table 1: CBOR Map Keys used in RAINS
5.2. Message
All interactions in RAINS take place in an outer envelope called a
Message, which is a CBOR map tagged with the RAINS Message tag (hex
0xE99BA8, decimal 15309736).
Trammell Expires May 27, 2017 [Page 16]
Internet-Draft RAINS November 2016
A Message map MAY contain a signatures (0) key, whose value is an
array of Signatures over the entire message as defined in
Section 5.14, to be verified against the infrastructure key for the
RAINS Server originating the message.
A Message map MAY contain a capabilities (1) key, whose value is
described in {#cbor-capabilities}.
A Message map MUST contain a token (2) key, whose value is a byte
array of maximum length 32. See Section 5.13.
A Message map MUST contain a content (23) key, whose value is an
array of Message Sections; a Message Section is either an Assertion,
Shard, Zone, or Query.
5.3. Message Section header
Each Message Section in the Message's content value MUST be a two-
element array. The first element in the array is the message section
type, encoded as an integer as in Section 5.1. The second element in
the array is a message section body, a CBOR map defined as in the
subsections shown in Section 5.1:
+------+--------------+-------------------------------------+
| Code | Name | Description |
+------+--------------+-------------------------------------+
| 1 | assertion | Assertion (see Section 5.4) |
| | | |
| -1 | revassertion | Address Assertion (see Section 5.8) |
| | | |
| 2 | shard | Shard (see Section 5.5) |
| | | |
| 3 | zone | Zone (see Section 5.6) |
| | | |
| -3 | revzone | Address Zone (see Section 5.9) |
| | | |
| 4 | query | Query (see Section 5.7) |
| | | |
| -4 | revquery | Address Query (see Section 5.10 |
| | | |
| 23 | notification | Notification (see Section 5.11) |
+------+--------------+-------------------------------------+
Table 2: Message Section Type Codes
Trammell Expires May 27, 2017 [Page 17]
Internet-Draft RAINS November 2016
5.4. Assertion body
An Assertion body is a map. The keys present in this map depend on
whether the Assertion is contained in a Message Section or in a Shard
or Zone.
Assertions contained in Message Sections are "bare Assertions".
Since they cannot inherit any values from their containers, they MUST
contain the signatures (0), subject-name (3), subject-zone (4),
context (6), and objects (7) keys.
Assertions within a Shard or Zone are "contained Assertions", and can
inherit values from their containers. A contained Assertion MUST
contain the subject- name (3) and objects (7) keys. It MAY contain
subject-zone (4) and context (6) keys, but in this case the values of
these keys MUST be identical to the values in the containing Shard or
Zone.
A contained Assertion SHOULD contain the signatures (0) key, since an
unsigned contained Assertion cannot be used by a RAINS server to
answer a query; it must be returned in a signed Shard or Zone.
The value of the signatures (0) key, if present, is an array of one
or more Signatures as defined in Section 5.14. If not present, the
containing Shard or Zone MUST be signed. Signatures on a contained
Assertion are generated as if the inherited subject-zone and context
values are present in the Assertion, whether actually present or not.
The signatures on the Assertion are to be verified against the
appropriate key for the Zone containing the Assertion in the given
context, as described in Section 4.1.2.
The value of the subject-name (3) key is a UTF-8 encoded [RFC3629]
string containing the name of the subject of the assertion. The
subject name never contains the zone in which the subject name; the
fully-qualified name is obtained by joining the subject-name to the
subject-zone with a '.' character. The subject-name must be valid
according to the nameset expression for the zone, if any.
The value of the subject-zone (4) key, if present, is a UTF-8 encoded
string containing the name of the zone in which the assertion is
made. If not present, the zone of the assertion is inherited from
the containing Shard or Zone.
The value of the context (6) key, if present, is a UTF-8 encoded
string containing the name of the context in which the assertion is
valid. If not present, the context of the assertion is inherited
from the containing Shard or Zone.
Trammell Expires May 27, 2017 [Page 18]
Internet-Draft RAINS November 2016
The value of the objects (7) key is an array of objects, as defined
in Section 5.12.
5.5. Shard body
A Shard body is a map. The keys present in the map depend on whether
the Shard is contained in a Message Section or in a Zone.
Shards contained in Message Sections are "bare Shards". Since they
cannot inherit any values from their contained Zone, they MUST
contain the content (23), signatures (0), subject-zone (4), context
(6), and may contain the shard-range (11) key.
Shards within a Zone are "contained Shards", and can inherit values
from their containing Zone. A contained Shard MUST contain the
content (23) key, and MAY contain the shard-range(11) key. It MAY
contain subject- zone (4) and context (6) keys, but in this case the
values of these keys MUST be identical to the values in the
containing Zone.
A contained Shard SHOULD contain the signatures (0) key if it also
contains a shard-range (11) key, since an unsigned contained Shard
cannot be used by a RAINS server to answer a query for nonexistence;
it must be returned in a signed Zone.
The value of the content (23) key is an array of Assertion bodies as
defined in {#cbor-assertion}.
The value of the signatures (0) key, if present, is an array of one
or more Signatures as defined in Section 5.14. If not present, the
containing Zone MUST be signed. Signatures on a contained Shard are
generated as if the inherited subject-zone and values are present in
the Shard, whether actually present or not. The signatures on the
Shard are to be verified against the appropriate key for the Zone
containing the Shard in the given context, as described in
Section 4.1.2.
The value of the subject-zone (4) key, if present, is a UTF-8 encoded
string containing the name of the zone in which the Assertions within
the Shard is made. If not present, the zone of the assertion is
inherited from the containing Zone.
The value of the context (6) key, if present, is a UTF-8 encoded
string containing the name of the context in which the Assertions
within the Shard are valid. If not present, the context of the
assertion is inherited from the containing Zone.
Trammell Expires May 27, 2017 [Page 19]
Internet-Draft RAINS November 2016
If the shard-range (11) key is present, the the shard is
lexicographically complete within the range described in its value: a
mapping for a (subject-name, object-type) pair that should be between
the two values given in the range but is not is asserted to not
exist. Lexicographic sorting is done on subject names by ordering
Unicode codepoints in ascending order; ordering on object types is
done via their code values in Section 5.12 in ascending order.
The shard-range value MUST be a two element array of strings or nulls
(subject-name A, subject-name B). A must lexicographically sort
before B, but neither subject name need be present in the shard's
contents. If A is null, the shard begins at the beginning of the
zone. If B is null, the shard ends at the end of the zone. The
shard MUST NOT contain any assertions whose subject names sort before
A or after B. In addition, the authority for the shard belongs to
MUST NOT make any assertions during the period of validity of the
shard's signatures that would fall between subject-name A and
subject-name B inclusive that are not contained within the shard (see
Section 6.4).
If the shard-range key is not present, the shard is not
lexicographically complete and MUST NOT be used to make assertions
about nonexistance.
5.6. Zone Message Section body
A Zone body is a map. Zones MUST contain the content (23),
signatures (0), subject-zone (4), and context (6) keys.
Signatures on the Zone are to be verified against the appropriate key
for the Zone in the given context, as described in Section 4.1.2.
The value of the content (23) key is an array of Shard bodies as
defined in {#cbor-shard} and/or Assertion bodies as defined in
{#cbor-assertion}.
The value of the subject-zone (4) key is a UTF-8 encoded string
containing the name of the Zone.
The value of the context (6) key is a UTF-8 encoded string containing
the name of the context for which the Zone is valid.
5.7. Query Message Section body
A Query body is a map. Queries MUST contain the the token (2),
query-name (8), query-contexts (9), and query-types (10) keys.
Queries MAY contain the query- expires (12) and query-opts (13) keys.
Trammell Expires May 27, 2017 [Page 20]
Internet-Draft RAINS November 2016
The value of the token (2) key, is a byte array of maximum length 32.
Future messages or notifications containing answers to this query
MUST contain this token, if present. See Section 5.13.
The value of the query-name (8) key is a UTF-8 encoded string
containing the fully qualified name that is the subject of the query.
The value of the query-contexts (9) key is an allowable context
expression, as an array of context names as UTF-8 encoded strings.
The allowable context expression is evaluated in-order, as follows:
o Context names appearing earlier in the expression are given
priority over context names appearing later in the expression.
o A context name may be negated by prepending the context negation
marker 'cx-0-.' to the context name; a negated context name means
the named context is not acceptable in answers to this query.
o The special context name '.' refers to the global context.
o The special context name 'cx-any-' means 'any context is
acceptable'.
Some examples:
o ['cx-.inf.ethz.ch.', 'cx-any-'] means that answers in the
'cx-.inf.ethz.ch.' context are preferred, but any context is
acceptable;
o ['.', 'cx-.inf.ethz.ch.'] means that only answers in the
'cx-.inf.ethz.ch.' or global contexts are acceptable, with the
global context preferred;
o ['.', cx-0-.cx-.inf.ethz.ch.', 'cx-any-'] means that answers in
any context except 'cx-.inf.ethz.ch.' are acceptable, with the
global context preferred.
An empty context array in a query is taken to be equivalent to an
array containing only ['.', 'cx-any-']; i.e. any context acceptable,
global context preferred.
The value of the query-types (10) key is an array of integers
encoding the type(s) of objects (as in Section 5.12) acceptable in
answers to the query. All values in the query-type array are treated
at equal priority: [2,3] means the querier is equally interested in
both IPv4 and IPv6 addresses for the query-name. An empty query-
types array indicates that objects of any type are acceptable in
answers to the query.
Trammell Expires May 27, 2017 [Page 21]
Internet-Draft RAINS November 2016
The value of the query-expires (12) key, if present, is a CBOR
integer counting seconds since the UNIX epoch UTC, identified with
tag value 1 and encoded as in section 2.4.1 of [RFC7049]. After the
query-expires time, the query will have been considered not answered
by the original issuer.
The value of the query-opts (13) key, if present, is an array of
integers in priority order of the querier's preferences in tradeoffs
in answering the query, as in Table 3.
+------+------------------------------------------------------------+
| Code | Description |
+------+------------------------------------------------------------+
| 1 | Minimize end-to-end latency |
| | |
| 2 | Minimize last-hop answer size (bandwidth) |
| | |
| 3 | Minimize information leakage beyond first hop |
| | |
| 4 | No information leakage beyond first hop: cached answers |
| | only |
| | |
| 5 | Expired assertions are acceptable |
| | |
| 6 | Enable query token tracing |
| | |
| 7 | Disable verification delegation (client protocol only) |
| | |
| 8 | Suppress proactive caching of future assertions |
+------+------------------------------------------------------------+
Table 3: Query Option Codes
Options 1-5 specify performance/privacy tradeoffs. Each server is
free to determine how to minimize each performance metric requested;
however, servers MUST NOT generate queries to other servers if "no
information leakage" is specified, and servers MUST NOT return
expired assertions unless "expired assertions acceptable" is
specified.
Option 6 specifies that a given token (see Section 5.13) should be
used on all queries resulting from a given query, allowing
traceability through an entire RAINS infrastructure. It is meant for
debugging purposes.
By default, a client service will perform verification of negative
queries and return a 404 No Assertion Exists for queries with a
consistent proof of non- existence, within a message signed by the
Trammell Expires May 27, 2017 [Page 22]
Internet-Draft RAINS November 2016
query service's infrakey. Option 7 disables this behavior, and
causes the query service to return the shard proving nonexistence for
verification by the client. It is intended to be used with untrusted
query services.
Option 8 specifies that a querier's interest in a query is strictly
ephemeral, and that future assertions related to this query SHOULD
NOT be proactively pushed to the querier.
5.8. Address Assertion Message Section body
Assertions about addresses are similar to assertions about names, but
keyed by address and restricted in terms of the objects they can
contain. An Address Assertion body is a map. The keys present in
this map depend on whether the Assertion is contained in a Message
Section or in an Address Zone.
Address Assertions contained in Message Sections are "bare Address
Assertions", and MUST contain the signatures (0), subject-addr (5),
context (6), and objects (7) keys.
Address Assertions contained in an Address Zone are "contained
Address Assertions", and can inherit their context from and be signed
within their containing Zone. A contained Address Assertion MUST
contain the subject-addr (5) and objects (7) keys. It MAY contain
the context (6) key, but in this case the value of this keys MUST be
identical to the value in the containing Address Zone.
A contained Address Assertion SHOULD contain the signatures (0) key,
since an unsigned contained Address Assertion cannot be used by a
RAINS server to answer a query; it must be returned in a signed
Address Zone.
The value of the signatures (0) key, if present, is an array of one
or more Signatures as defined in Section 5.14. If not present, the
containing Address Zone MUST be signed. Signatures on a contained
Address Assertion are generated as if the inherited context value are
present in the Assertion, whether actually present or not. The
signatures on the Assertion are to be verified against the
appropriate key for the Address Zone containing the Assertion in the
given context, as described in Section 4.1.2.
The value of the subject-addr (5) key is a three element CBOR array.
The first element of the array is the address family encoded as an
object type, 2 for IPv6 addresses and 3 for IPv4 addresses. The
second element is the prefix length encoded as an integer, 0-128 for
IPv6 and 0-32 for IPv4. The third element is the address, encoded as
in Section 5.12. Subject addresses with the maximum prefix length
Trammell Expires May 27, 2017 [Page 23]
Internet-Draft RAINS November 2016
for the address family are subject host addresses, and are nameable;
subject addresses with less than the maximum prefix length are
subject network addresses, and are delegatable.
The value of the context (6) key, if present, is a UTF-8 string
containing the name of the context in which the Address Assertion is
valid. If not present, the context of the Address Assertion is
inherited from the containing Address Zone. See Section 4.3.1.
The value of the objects (7) key is an array of objects, as defined
in Section 5.12. Only object types redirection, delegation, and
registrant are available for subject network addresses, and only
object type name is available for subject host addresses.
5.9. Address Zone Message Section body
Assertions about addresses can be grouped into zones, where all the
assertions within the zone are contained within the zone's address.
These Address Zones are similar to Zones containing assertions about
names, but are keyed by network address and restricted in their
semantics.
An Address Zone body is a map. Zones MUST contain the content (23),
signatures (0), subject-addr (5), and context (6) keys.
Signatures on the Zone are to be verified against the appropriate key
for the Zone in the given context, as described in Section 4.1.2.
The value of the subject-addr (5) key is a three element CBOR array.
The first element of the array is the address family encoded as an
object type, 2 for IPv6 addresses and 3 for IPv4 addresses. The
second element is the prefix length encoded as an integer, 0-127 for
IPv6 and 0-31 for IPv4. The third element is the address, encoded as
in Section 5.12. Only subject network addresses are acceptable for
Address Zones.
The value of the content (23) key is an array of Address Assertion
bodies as defined in {#cbor-revassert}. The Address Assertions within
the content array MUST fall completely within the network designated
by the subject-addr value.
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.
Trammell Expires May 27, 2017 [Page 24]
Internet-Draft RAINS November 2016
5.10. Address Query Message Section body
Queries for assertions about addresses are similar to queries for
assertions about names, but have semantic restrictions similar to
those for Address Assertions and Address Zones. An address query may
have only one context.
An Address Query body is a map. Queries MUST contain the the token
(2), subject-addr (5), context (6), and query-types (10) keys.
Queries MAY contain query-opts (13) and query-expires (12) keys.
The value of the token (2) key, is a byte array of maximum length 32.
Future messages or notifications containing answers to this query
MUST contain this token, if present. See Section 5.13.
The value of the subject-addr (5) key is a three-element CBOR array.
The first element of the array is the address family encoded as an
object type, 2 for IPv6 addresses and 3 for IPv4 addresses. The
second element is the prefix length encoded as an integer, 0-128 for
IPv6 and 0-32 for IPv4. The third element is the address, encoded as
in Section 5.12.
The value of the context (6) key is a UTF-8 encoded string containing
the name of the context for which the Query is valid. Unlike queries
for names, queries for Address Queries can only pertain to a single
context.
See Section 4.3.1 for more.
The value of the query-expires (12) key, if present, is a CBOR
integer counting seconds since the UNIX epoch UTC, identified with
tag value 1 and encoded as in section 2.4.1 of [RFC7049]. After the
query-expires time, the query will have been considered not answered
by the original issuer.
The value of the query-opts (13) key, if present, is an array of
integers in priority order of the querier's preferences in tradeoffs
in answering the query, as in Table 3. See Section 5.7 for more.
Any Address Assertion relating to an address containing the address
queried for is considered to respond to the query, with more-specific
prefixes being preferred over less-specific.
5.11. Notification Message Section body
Notification Message Sections contain information about the operation
of the RAINS protocol itself. A Notification Message Section body is
a map which MUST contain the token (2) and note-type (21) keys and
Trammell Expires May 27, 2017 [Page 25]
Internet-Draft RAINS November 2016
MAY contain the note-data (22) key. The value of the note-type key
is encoded as an integer as in the Table 4.
+------+--------------------------------------------+
| Code | Description |
+------+--------------------------------------------+
| 100 | Connection heartbeat |
| | |
| 399 | Capability hash not understood |
| | |
| 400 | Malformed message received |
| | |
| 403 | Inconsistent message received |
| | |
| 404 | No assertion exists (client protocol only) |
| | |
| 413 | Message too large |
| | |
| 500 | Unspecified server error |
| | |
| 501 | Server not capable |
| | |
| 504 | No assertion available |
+------+--------------------------------------------+
Table 4: Notification Type Codes
Note that the status codes are chosen to be mnemonically similar to
status codes for HTTP [RFC7231]. Details of the meaning of each
status code are given in Section 6.
The value of the token (2) key is a byte array of maximum length 32,
which MUST contain the token of the message or query to which the
notification is a response. See Section 5.13.
The value of the note-data (22) key, if present, is a UTF-8 encoded
string with additional information about the notification, intended
to be displayed to an administrator to help debug the issue
identified by the negotiation.
5.12. Object
Objects are encoded as arrays in CBOR, where the first element is the
type of the object, encoded as an integer in the following table:
Trammell Expires May 27, 2017 [Page 26]
Internet-Draft RAINS November 2016
+------+--------------+-------------------------------------+
| Code | Name | Description |
+------+--------------+-------------------------------------+
| 1 | name | name associated with subject |
| | | |
| 2 | ip6-addr | IPv6 address of subject |
| | | |
| 3 | ip4-addr | IPv4 address of subject |
| | | |
| 4 | redirection | name of zone authority server |
| | | |
| 5 | delegation | public key for zone delgation |
| | | |
| 6 | nameset | name set expression for zone |
| | | |
| 7 | cert-info | certificate information for name |
| | | |
| 8 | service-info | service information for srvname |
| | | |
| 9 | registrar | registrar information |
| | | |
| 10 | registrant | registrant information |
| | | |
| 11 | infrakey | public key for RAINS infrastructure |
+------+--------------+-------------------------------------+
Table 5: Object type codes
A name (1) object contains a name associated with a name as an alias.
It is represented as a three-element array. The second element is a
fully-qualified name as a UTF-8 encoded string. The third type is an
array of object type codes for which the alias is valid, with the
same semantics as the query-types (9) key in queries (see
Section 5.7).
An ip6-addr (2) object contains an IPv6 address associated with a
name. It is represented as a two element array. The second element
is a byte array of length 16 containing an IPv6 address in network
byte order.
An ip4-addr (3) object contains an IPv4 address associated with a
name. It is represented as a two element array. The second element
is a byte array of length 4 containing an IPv4 address in network
byte order.
A redirection (4) object contains the fully-qualified name of a RAINS
authority server for a named zone. It is represented as a two-
Trammell Expires May 27, 2017 [Page 27]
Internet-Draft RAINS November 2016
element array. The second element is a fully-qualified name of an
RAINS authority server as a UTF-8 encoded string.
A delegation (5) object contains the public key used to generate
signatures on assertions in a named zone, and by which a delegation
of a name within a zone to a subordinate zone may be verified. It is
represented as an N-element array. The second element is a signature
algorithm identifier as in Section 5.14. Additional elements are as
defined in Section 5.14 for the given algorithm identifier.
A nameset (6) object contains an expression defining which names are
allowed and which names are disallowed in a given zone. It is
represented as a two- element array. The second element is a nameset
expression to be applied to each name element within the zone without
an intervening delegation, as defined in Section 5.12.2
A cert-info (7) object contains an expression binding a certificate
or certificate authority to a name, such that connections to the name
must either use the bound certificate or a certificate signed by a
bound authority. It is represented as an five-element array, as
defined in Section 5.12.1.
A service-info (8) object gives information about a named service.
Services are named as in [RFC2782]. It is represented as a four-
element array. The second element is a fully-qualified name of a
host providing the named service as a UTF-8 string. The third
element is a transport port number as a positive integer in the range
0-65535. The fourth element is a priority as a positive integer,
with lower numbers having higher priority.
A registrar (9) object gives the name and other identifying
information of the registrar (the organization which caused the name
to be added to the namespace) for organization-level names. It is
represented as a UTF-8 string of maximum length 256 bytes containing
identifying information chosen by the registrar according to the
registry's policy.
A registrant (10) object gives information about the registrant of an
organization-level name. It is represented as a UTF-8 string with a
maximum length of 4096 bytes containing this information, with a
format chosen by the registrar according to the registry's policy.
An infrakey (11) object contains the 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.14.
Trammell Expires May 27, 2017 [Page 28]
Internet-Draft RAINS November 2016
5.12.1. Certificate information format
A cert-info object contains information about the certificate(s) that
can be used to authenticate a transport-layer association with a
named entity. It is encoded as a file-element array. The first
element is the RAINS object type (7). The second element is the
protocol family specifier, describing the cryptographic protocol used
to connect, as defined in Table 6. The protocol family defines the
format of certificate data to be hashed. The third element is the
certificate usage specifier as in Table 7, describing the constraint
imposed by the assertion. These are defined to be compatible with
Certificate Usages in the TLSA RRTYPE for DANE [RFC6698]. The fourth
element is the hash algorithm identifier, defining the hash algorithm
used to generate the certificate data. The fifth item is the data
itself, whose format is defined by the protocol family and hash
algorithm.
+------+---------------------------------------+--------------------+
| Code | Protocol family | Certificate format |
+------+---------------------------------------+--------------------+
| 0 | Unspecified | Unspecified |
| | | |
| 1 | Transport Layer Security (TLS) | [RFC5280] |
| | [RFC5246] | |
+------+---------------------------------------+--------------------+
Table 6: Certificate information protocol families
Protocol family 0 leaves the protocol family unspecified; client
validation and usage of cert-info assertions, and the protocol used
to connect, are up to the client, and no information is stored in
RAINS. Protocol family 1 specifies Transport Layer Security version
1.2 [RFC5246] or a subsequent version, secured with PKIX [RFC5280]
certificates.
+------+--------------------------+
| Code | Certificate usage |
+------+--------------------------+
| 2 | Trust Anchor Certificate |
| | |
| 3 | End-Entity Certificate |
+------+--------------------------+
Table 7: Certificate information usage values
A trust anchor certificate constraint specifies a certificate that
MUST appear as the trust anchor for the certificate presented by the
subject of the assertion on a connection attempt. An end-entity
Trammell Expires May 27, 2017 [Page 29]
Internet-Draft RAINS November 2016
certificate constraint specifies a certificate that MUST be presented
by the subject of the assertion on a connection attempt.
+------+-----------+---------------------------------------+
| Code | Hash/HMAC | Notes |
+------+-----------+---------------------------------------+
| 0 | None | Data contains full certificate |
| | | |
| 1 | sha-256 | Data contains SHA-256 hash (32 bytes) |
| | | |
| 2 | sha-512 | Data contains SHA-512 hash (64 bytes) |
| | | |
| 3 | sha-384 | Data contains SHA-384 hash (48 bytes) |
+------+-----------+---------------------------------------+
Table 8: Certificate information hash algorithms
Code 0 is used to store full certificates in RAINS assertions, while
other codes are used to store hashes for verification.
For example, in a cert-info object with values [ 7, 1, 3, 3, (data)
], the data would be a 48 SHA-384 hash of the ASN.1 DER-encoded
X.509v3 certificate (see Section 4.1 of [RFC5280]) to be presented by
the endpoint on a connection attempt with TLS version 1.2 or later.
5.12.2. Name expression format
The nameset expression is represented as a UTF-8 string encoding a
modified POSIX Extended Regular Expression format (see POSIX.2) to be
applied to each element of a name within the zone. A name containing
an element that does not match the valid nameset expression for a
zone is not valid within the zone, and the nameset assertion can be
used to prove nonexistence.
The POSIX character classes :alnum:, :alpha:, :ascii:, :digit:,
:lower:, and :upper: are available in these regular expressions,
where:
o :lower: matches all codepoints within the Unicode general category
"Letter, lowercase"
o :upper: matches all codepoints within the Unicode general category
"Letter, uppercase"
o :alpha: matches all codepoints within the Unicode general category
"Letter".
Trammell Expires May 27, 2017 [Page 30]
Internet-Draft RAINS November 2016
o :digit: matches all codepoints within the Unicode general category
"Number, decimal digit"
o :alnum: is the union of :alpha: and :digit:
o :ascii: matches all codepoints in the range 0x20-0x7f
In addition, each Unicode block is available as a character class,
with the syntax :ublkXXXX: where XXXX is a 4 or 5 digit, zero-
prefixed hex encoding of the first codepoint in the block. For
example, the Cyrillic block is available as :ublk0400:.
Unicode escapes are supported in these regular expressions; the
sequence \uXXXX where XXXX is a 4 or 5 digit, possibly zero-prefixed
hex encoding of the codepoint, is substituted with that codepoint.
Set operations (intersection and subtraction) are available on
character classes. Two character class or range expressions in a
bracket expression joined by the sequence && are equivalent to the
intersection of the two character classes or ranges. Two character
class or range expressions in a bracket expression joined by the
sequence - are equivalent to the subtraction of the second character
class or range from the first.
For example, the nameset expression:
[[:ublk0400:]&&[:lower:][:digit:]]+
matches any name made up of one or more lowercase Cyrillic letters
and digits. The same expression can be implemented with a range
instead of a character class:
[\u0400-\u04ff&&[:lower:][:digit:]]+
5.13. Tokens in queries and messages
Messages, queries, and notifications all contain an opaque token (2)
key, whose content is a byte array of maximum length 32, and is used
to link Messages to the Queries they respond to, and Notifications to
the Messages they respond to. Tokens MUST be treated as opaque
values by RAINS servers.
A Message sent in response to a Query MUST contain the token in that
Query. Otherwise, the Message SHOULD 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.
Trammell Expires May 27, 2017 [Page 31]
Internet-Draft RAINS November 2016
When a server creates a new query to forward to another server in
response to a query it received, it MUST NOT use the same token on
the delegated query as on the received query, unless option 6 Enable
Tracing is present in the received, in which case it MUST use the
same token.
5.14. Signatures, delegation keys, and RAINS infrastructure keys
RAINS supports multiple signature algorithms and hash functions for
signing assertions for cryptographic algorithm agility [RFC7696]. A
RAINS signature algorithm identifier specifies the signature
algorithm; a hash function for generating the HMAC and the format of
the encodings of the signature values in Assertions, Shards, Zones,
and Messages, as well as of public key values in delegation objects.
RAINS signatures have three common elements: the algorithm
identifier, a valid-since timestamp, and a valid-until timestamp.
Signatures are represented as an array of these three values followed
by additional elements containing the signature data itself,
according to the algorithm identifier.
Valid-since and valid-until timestamps are represented as CBOR
integers counting seconds since the UNIX epoch UTC, identified with
tag value 1 and encoded as in section 2.4.1 of [RFC7049]. A
signature MUST have a valid-until timestamp. If a signature has no
specified valid-since time (i.e., is valid from the beginning of time
until its valid-until timestamp), the valid-since time MAY be null
(as in Table 2 in Section 2.3 of [RFC7049]).
Signatures in RAINS are generated over a normalized serialized CBOR
object (a Message; or an Assertion, Shard, or Zone section body). To
normalize and serialize an object for signing:
o Serialize the object with a stub for the signature to be
generated:
* Strip all other signatures during serialization by omitting all
signatures (0) keys and their values. When signing a shard or
zone, the signatures on contained assertions, if present, must
be omitted too. When signing a message, the signatures on
contained assertions, shards, and zones must be omitted.
* Add subject zone and context to contained shards and assertions
if not present, inheriting them from their containing shard or
zone.
* Create a stub signature within an array within a signatures (0)
key at the appropriate place in the object, containing the
Trammell Expires May 27, 2017 [Page 32]
Internet-Draft RAINS November 2016
algorithm ID, timestamps and hash chain token, if present, but
a null value in the place of the signature content.
* Normalize the serialized object by emitting all keys in CBOR
maps in ascending numerical order. Note that when serializing
anything with a Content array, the order of the content array
is preserved.
* If the serialized object is a Message, it should be tagged with
the RAINS tag.
o Generate a signature on the resulting byte stream according to the
algorithm selected.
o Add the full signature to the signatures array at the appropriate
point in the object.
To verify a signature, generate the byte stream as for signing, then
verify the signature according to the algorithm selected.
The following algorithms are supported:
+------+------------+-----------+--------------------+
| Code | Signatures | Hash/HMAC | Format |
+------+------------+-----------+--------------------+
| 2 | ecdsa-256 | sha-256 | See Section 5.14.1 |
| | | | |
| 3 | ecdsa-384 | sha-384 | See Section 5.14.1 |
+------+------------+-----------+--------------------+
Table 9: Defined signature algorithms
5.14.1. ECDSA signature and public key format
ECDSA public keys consist of a single value, called "Q" in
[FIPS-186-3]. Q is a simple bit string that represents the
uncompressed form of a curve point, concatenated together as "x | y".
The third element in a RAINS delegation object is the Q bit string
encoded as a CBOR byte array. RAINS delegation objects for ECDSA-256
public keys are therefore represented as the array [5, 2, Q]; and for
ECDSA-384 public keys as [5, 3, Q].
ECDSA signatures are a combination of two non-negative integers,
called "r" and "s" in [FIPS-186-3]. A Signature using ECDSA is
represented using a four-element CBOR array, with the fourth element
being "r | s" such that r is represented as a byte array as described
in Section C.2 of [FIPS-186-3], and s represented as a byte array as
described in Section C.2 of [FIPS-186-3]. For ECDSA-256 signatures,
Trammell Expires May 27, 2017 [Page 33]
Internet-Draft RAINS November 2016
each integer MUST be represented as a 32-byte array. For ECDSA-384
signatures, each integer MUST be represented as a 48-byte array.
RAINS signatures using ECDSA-256 are therefore the array [2, valid-
from, valid-until, r|s]; and for ECDSA-384 the array [3, valid-from,
valid-until, r|s].
ECDSA-256 signatures and public keys use the P-256 curve as defined
in [FIPS-186-3]. ECDSA-384 signatures and public keys use the P-384
curve as defined in [FIPS-186-3].
All RAINS servers MUST implement ECDSA-256 and ECDSA-384.
5.15. Capabilities
When a RAINS server or client sends the first message in a stream to
a peer, it MAY expose optional capabilities to its peer using the
capabilities (1) key. This key contains either:
o an array of uniform resource names specifying capabilities
supported by the sending server, taken from the table below, with
each name encoded as a UTF-8 string.
o a SHA-256 hash of the CBOR byte stream derived from normalizing
such an array by sorting it in lexicographically increasing order,
then serializing it.
This mechanism is inspired by [XEP0115], and is intended to be used
to reduce the overhead in exposing common sets of capabilities. Each
RAINS server can cache a set of recently-seen or common hashes, and
only request the full URN set (using notification code 399) on a
cache miss.
The following URNs are presently defined; other URNs will specify
future optional features, support for alternate transport protocols
and new signature algorithms, etc.
+--------------------+----------------------------------------------+
| URN | Meaning |
+--------------------+----------------------------------------------+
| urn:x-rains:tlssrv | Listens for connections on TLS over TCP from |
| | other RAINS servers. |
+--------------------+----------------------------------------------+
Since there are only two defined capabilities at this time, RAINS
servers can be implemented with two hard-coded hashes to determine
whether a peer is listening or not. The hash presented by a server
supporting urn:x-rains:tlssrv is
e5365a09be554ae55b855f15264dbc837b04f5831daeb321359e18cdabab5745; the
Trammell Expires May 27, 2017 [Page 34]
Internet-Draft RAINS November 2016
hash presented by a server supporting no capabilities is
76be8b528d0075f7aae98d6fa57a6d3c83ae480a8469e668d7b0af968995ac71.
A RAINS server MUST NOT assume that a peer server supports a given
capability unless it has received a message containing that
capability from that server. An exception are the capabilities
indicating that a server listens for connections using a given
transport protocol; servers and clients can also learn this
information from RAINS itself (given a redirection assertion for a
named zone) or from external configuration values.
6. RAINS Protocol Definition
As noted in Section 5, RAINS is a message-exchange protocol that uses
CBOR [RFC7049] as its framing. Since CBOR is self-framing - a CBOR
parser can determine when a CBOR object is complete at the point at
which it has read its final byte - RAINS requires no external
framing. It can therefore run over any streaming, multistreaming, or
message-oriented transport protocol. In order to protect query
confidentiality, and support rapid deployment over a ubiquitously
implemented transport, RAINS is defined in this document to run over
persistent TLS 1.2 connections [RFC5246] over TCP [RFC0793] with
mutual authentication between servers, and authentication of servers
by clients. The TLS certificates of RAINS server peers can be
verified as specified in the cert-info assertions for those servers.
RAINS servers MUST support this transport; future transports can be
negotiated using the capabilities mechanism after bootstrapping using
TLS 1.2. As RAINS is an experimental protocol, RAINS servers listen
on port 1022 [RFC4727] for connections from other RAINS servers and
clients. RAINS servers should strive to keep connections open to
peer servers, unless it is clear that no future messages will be
exchanged with those peers, or in the face of resource limitations at
either peer. If a RAINS server needs to send a message to another
RAINS server to which it does not have an open connection, it
attempts to open a connection with that server.
This section describes the operation of the protocol as used among
RAINS servers. A simplified version of the protocol for client
access is described in Section 7.
6.1. Message processing
Once a transport is established, any server may validly send a
message with any content to any other server. A client may send
messages containing queries to servers, and a server may sent
messages containing anything other than queries to clients.
Trammell Expires May 27, 2017 [Page 35]
Internet-Draft RAINS November 2016
Upon receipt of a message, a server or client parses it, and:
o notes the token on the message. This token MUST be present on any
messages sent in reply to this message.
o processes any capabilities present, replacing the set of
capabilities known for the peer with the set present in the
message. If the present capabilities are represented by a hash
that the server does not have in its cache, it prepares a
notification of type 399 "Capability hash not understood" to send
to its peer.
o splits the contents into its constituent message sections,
processing them independently.
On receipt of an assertion, shard, or zone message section, a server:
o verifies its consistency (see Section 6.4). If the section is not
consistent, it prepares to send a notification of type 403
Inconsistent Message to the peer, and discards the section.
Otherwise, it:
o determines whether it answers an outstanding query; if so, it
prepares to forward the section to the server that issued the
query.
o determines whether it is likely to answer a future query,
according to its configuration, policy, and query history; if so,
it caches the section.
On receipt of an assertion, shard, or zone message section, a client:
o determines whether it answers an outstanding query; if so, it
considers the query answered. It then:
o determines whether it is likely to answer a future query,
according to its configuration, policy, and query history; if so,
it caches the section.
On receipt of a query, a server:
o determines whether it has expired by checking the query-expires
value. If so, it drops the query silently. If not, it:
o determines whether it has a stored assertion, shard, and/or zone
message section which answers the query. If so, it prepares to
return the most specific such section with the signature of the
Trammell Expires May 27, 2017 [Page 36]
Internet-Draft RAINS November 2016
longest remaining validity to the peer that issued the query. If
not, it:
o checks to see whether the query specifies option 4 (cached answers
only). If so, and if option 5 (expired assertions acceptable) is
also specified, it then checks to see if it has any cached
sections that answer the query on which signatures are expired;
otherwise, processing stops. If the query does not specify option
4, delegation proceeds as follows: the server:
o determines whether it has other non-authoritative servers it can
forward the query to, according to its configuration and policy,
and in compliance with any query options (see Section 5.7). If
so, it prepares to forward the query to those servers, noting the
reply for the received query depends on the replies for the
forwarded query. If not, it:
o determines the responsible authority servers for the zone
containing the query name in the query for contexts requested, and
forwards the query to those authority servers, noting the reply
for the received query depends on the reply for the forwarded
query.
If query delegation fails to return an answer within a configured
timeout for a delegated query, the server prepares to send a 504 No
assertion available response to the peer from which it received the
query.
When a server creates a new query to forward to another server in
response to a query it received, it SHOULD NOT use the same token on
the delegated query as on the received query, unless option 6 Enable
Tracing is present in the received, in which case it MUST use the
same token. The Enable Tracing option is designed to allow debugging
of query processing across multiple servers, It SHOULD only be
enabled by clients designed explicitly for debugging RAINS itself,
and MUST NOT be enabled by default by client resolvers.
When a server creates a new query to forward to another server in
response to a query it received, and the received query contains a
query-expires time, the delegated query MUST contain the same query-
expires time. 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:
Trammell Expires May 27, 2017 [Page 37]
Internet-Draft RAINS November 2016
o For type 100 "Connection Heartbeat", the server does nothing:
these null messages are used to keep long-lived connections open
in the presence of network behaviors that may drop state for idle
connections.
o For type 399 "Capability hash not understood", the server prepares
to send a full capabilities list on the next message it sends to
the peer.
o For type 504 "No assertion available", the server checks the token
on the message, and prepares to forward the assertion to the
associated query.
o For type 413 "Message too large" the server notes that large
messages may not be sent to a peer and tries again (see
Section 6.3), or logs the error along with the note-data content.
o For type 400 "Malformed message", type 403 "Inconsistent message",
type 500 "Server error", or type 501 "Server not capable", the
server logs the error along with the note-data content, as these
notifications generally represent implementation or configuration
error conditions which will require human intervention to
mitigate.
On receipt of a notification, a client's behavior depends on the
notification type:
o For type 100 "Connection Heartbeat", the client does nothing, as
above.
o For type 399 "Capability hash not understood", the client prepares
to send a full capabilities list on the next message it sends to
the peer.
o For type 404 "No assertion exists", the client takes the query to
be unanswerable. It may reissue the query with query option 7 to
do the verification of nonexistence again, if the server from
which it received the notification is untrusted.
o For type 413 "Message too large" the client notes that large
messages may not be sent to a peer and tries again (see
Section 6.3), or logs the error along with the note-data content.
o For type 400 "Malformed message", type 403 "Inconsistent message",
type 500 "Server error", or type 501 "Server not capable", the
client logs the error along with the note-data content, as these
notifications generally represent implementation or configuration
Trammell Expires May 27, 2017 [Page 38]
Internet-Draft RAINS November 2016
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.15.
If the server is configured to keep long-running connections open,
due to the presence of network behaviors that may drop state for idle
connections, it SHOULD send a message containing a type 100
Connection Heartbeat notification after a configured idle time
without any messages containing other content being sent.
6.2. Message Transmission
As noted in Section 6.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.
6.3. Message Limits
RAINS servers MUST accept messages up to 65536 bytes in length, but
MAY accept messages of greater length, subject to resource
limitations of the server. A server with resource limitations MUST
respond to a message rejected due to length restrictions with a
notification of type 413 (Message Too Large). A server that receives
a type 413 notification must note that the peer sending the message
only accepts messages smaller than the largest message it's
successfully sent that peer, or cap messages to that peer to 65536
bytes in length.
Since a bare assertion with a single ECDSA 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.
Trammell Expires May 27, 2017 [Page 39]
Internet-Draft RAINS November 2016
6.4. Runtime Consistency Checking
The data model used by the RAINS protocol allows inconsistent
information to be asserted, all resulting from misconfigured or
misbehaving authority servers. The following types of inconsistency
are possible:
o A lexically complete shard may omit an assertion within its shard-
range which is valid at the same time as the shard.
o A zone may omit an assertion within its zone which is valid at the
same time as the zone.
o An assertion prohibited by its zone's nameset may be valid at the
same time as the zone's nameset assertion.
RAINS relies on runtime consistency checking to mitigate
inconsistency: each server receiving an assertion, shard, or zone
SHOULD, subject to resource constraints, ensure that it is consistent
with other information it has, and if not, discard all assertions,
shards, and zones in its cache, log the error, and send a 403
Inconsistent Message to the source of the message.
6.5. Integrity and Confidentiality Protection
Assertions are not valid unless they contain at least one signature
that can be verified from the chain of authorities specified by the
name and context on the assertion; integrity protection is built into
the information model. The infrastructure key object type allows
keys to be associated with RAINS servers in addition to zone
authorities, which allows a client to delegate integrity verification
of assertions to a trusted query service (see Section 7).
Since the job of an Internet naming service is to provide publicly-
available information mapping names to information needed to connect
to the services they name, confidentiality protection for assertions
is not a goal of the system. Specifically, the information model and
the mechanism for proving non-existence of an assertion is not
designed to provide resistance against zone enumeration.
On the other hand, confidentiality protection of query information in
crucial. Linking naming queries to a specific user can be nearly as
useful to build a profile of that user for surveillance purposes as
full access to the clear text of that client's communications
[RFC7624]. In this revision, RAINS uses TLS to protect
communications between servers and between servers and clients, with
certificate information for RAINS infrastructure stored in RAINS
itself. Together with hop-by-hop confidentiality protection, query
Trammell Expires May 27, 2017 [Page 40]
Internet-Draft RAINS November 2016
options, proactive caching, default use of non-persistent tokens, and
redirection among servers can be used to mix queries and reduce the
linkability of query information to specific clients.
7. RAINS Client Protocol
The protocol used by clients to issue queries to and receive
responses from an query service is a subset of the full RAINS
protocol, with the following differences:
o Clients only process assertion, shard, zone, and notification
sections; sending a query to a client results in a 400 Malformed
Message notification.
o Clients never listen for connections; a client must initiate and
maintain a transport session to the query server(s) it uses for
name resolution.
o Servers only process query and notification sections when
connected to clients; a client sending assertions to a server
results in a 400 Malformed Message notification.
Since signature verification is resource-intensive, clients delegate
signature verification to query servers by default. The query server
signs the message containing results for a query using its own key
(published as an infrakey object associated with the query server's
name), and a validity time corresponding to the signature it verified
with the longest lifetime, stripping other signatures from the reply.
This behavior can be disabled by a client by specifying query option
7, allowing the client to do its own verification.
8. Deployment Considerations
The following subsections discuss issues that must be considered in
any deployment of RAINS at scale.
8.1. Assertion Lifetime Management
An assertion can contain multiple signatures, each with a different
lifetime. Signature lifetimes are equivalent to a time to live in
the present DNS: authorities should compute a new signature for each
validity period, and make these new signatures available when old
ones are expiring.
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].
Trammell Expires May 27, 2017 [Page 41]
Internet-Draft RAINS November 2016
8.2. Secret Key Management
The secret keys associated with public keys for each RAINS server
(via infrakey objects) must be available on that server, whether
through a hardware or software security device, so they can sign
messages on demand; this is particularly important for query servers.
In addition, the secret keys associated with TLS certificates for
each server (published via certinfo objects) must be available as
well in order to establish TLS sessions.
However, storing zone secret keys (associated via delegation objects)
on RAINS servers would represent a more serious operational risk. To
keep this from being necessary, authority servers have an additional
signer interface, from which they will accept and cache any
assertion, shard, or zone for which they are authority servers until
at least the end of validity of the last signature, provided the
signature is verifiable.
8.3. Unsigned Contained Assertions
Although RAINS supports Shards and Zones containing unsigned
assertions, protecting the integrity of those Assertions by the
signature on the Shard or Zone, it is RECOMMENDED that authorities
sign each Assertion, even those contained within a Shard or Zone, in
order to minimize the size of positive answers to queries.
8.4. Query Service Discovery
A client that will not do its own verification must be able to
discover the oracle server(s) it should trust for resolution.
Integration with e.g. DHCP or selection of a local multicast
discovery method are left to a future revision of this document.
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 oracle. This would allow
client on an untrusted network to use an untrusted locally-available
oracle to discover a preferred oracle (doing key verification on its
own for bootstrapping), before connecting to that oracle for normal
name resolution.
8.5. Transition using translation between RAINS and DNS information
models
Full adoption of RAINS would require changes to every client device
(replacing DNS stub resolvers with RAINS clients) and name server on
the Internet. In addition, most client software would need to
Trammell Expires May 27, 2017 [Page 42]
Internet-Draft RAINS November 2016
change, as well, to get the full benefits of explicit context in name
resolution. This is a wholly unrealistic goal.
RAINS servers can, however, coexist with Domain Name System servers
and clients during an indefinite transition period. RAINS assertions
can be algorithmically translated into DNS answers, and RAINS queries
can be algorithmically translated into DNS queries, by RAINS to DNS
gateways, given the mostly compatible information models used by the
two.
While DNSSEC and RAINS keys for equivalent ciphersuites are
compatible with each other, there is no equivalent to query option 7
for gateways, since the RAINS signatures are generated over the RAINS
bytestream for an assertion, not the DNS bytestream. Therefore,
RAINS to DNS gateways must provide verification services for DNS
clients. DNS over TLS [RFC7858] SHOULD be used between the DNS
client and gateway to ensure confidentiality and integrity for
queries and answers.
Object type mappings are as follows:
o Objects of type name can (largely) be represented as CNAME RRs.
o Objects of type ip6-addr can be represented as AAAA RRs.
o Objects of type ip4-addr can be represented as A RRs.
o Objects of type redirection can be represented as NS RRs.
o Objects of type cert-info can be represented as TLSA RRs
o Objects of type service-info can be represented as SRV RRs.
There are a few object types without mappings:
o Objects of type delegation can be represented as DS RRs, and
signatures as RRSIG RRs, but since these keys are verified by the
gateway, there is no need to represent this information to the
client.
o Objects of type infrakey cannot be represented in DNS, but are
irrelevant for DNS translation of RAINS messages, since DNS does
not support server signing of responses.
o Objects of type registrar and registrant cannot be represented in
DNS; clients can use WHOIS instead. In addition, RRTYPEs could be
added for them in the future if RAINS sees significant deployment
with DNS as a front-end protocol.
Trammell Expires May 27, 2017 [Page 43]
Internet-Draft RAINS November 2016
o Objects of type nameset cannot be represented in DNS; the current
equivalent are the IDNA parameters maintained by IANA (for the DNS
root zone only) at https://www.iana.org/assignments/idna-tables-
6.3.0/idna-tables-6.3.0.xhtml.
When translating a DNS query from a client to a RAINS query for that
client, client options can be set on a per-server, per-client, or
per-query basis using some out of band configuration options.
When translating a RAINS assertion to a DNS answer, the gateway can
use the time to expiry for the verified signature as the TTL.
There is no method for exposing context information in a DNS query or
answer. Therefore, queries and answers at a RAINS gateway are only
supported for the global context ".".
9. 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.
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.
Trammell Expires May 27, 2017 [Page 44]
Internet-Draft RAINS November 2016
RAINS servers currently listen for connections from other servers on
Port 1022. Future revisions of this document may specify a different
port, registered with IANA via Expert Review [RFC5226].
The symbol table in this document in Section 5.1, the notification
code table in Section 5.11, and the signature algorithm table in
Section 5.14 may be candidates for IANA registries in future
revisions of this document.
The urn:x-rains namespace used by the RAINS capability mechanism in
Section 5.15 may be a candidate for replacement with an IANA-
registered namespace in a future revision of this document.
11. Security Considerations
This document specifies a new, experimental protocol for Internet
name resolution, with mandatory integrity protection for assertions
about names built into the information model, and confidentiality for
query information protected on a hop-by-hop basis. See especially
Section 4.1.2, Section 6.5, Section 5.14, Section 5.12.1, and
Section 8.2 for security-relevant details.
12. Acknowledgments
Thanks to Daniele Asoni, Laurent Chuat, Markus Deshon, Ted Hardie,
Joe Hildebrand, Tobias Klausmann, Steve Matsumoto, Adrian Perrig,
Raphael Reischuk, Stephen Shirley, Andrew Sullivan, and Suzanne Woolf
for the discussions leading to the design of this protocol.
13. References
13.1. Normative References
[FIPS-186-3]
NIST, ., "Digital Signature Standard FIPS 186-3", June
2009.
[I-D.trammell-inip-pins]
Trammell, B., "Properties of an Ideal Naming Service",
draft-trammell-inip-pins-02 (work in progress), September
2016.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
Trammell Expires May 27, 2017 [Page 45]
Internet-Draft RAINS November 2016
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://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,
<http://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, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727,
DOI 10.17487/RFC4727, November 2006,
<http://www.rfc-editor.org/info/rfc4727>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <http://www.rfc-editor.org/info/rfc7049>.
13.2. Informative References
[PARSER-BUGS]
Bratus, S., Patterson, M., and A. Shubina, "The Bugs We
Have To Kill (USENIX login)", August 2015.
Trammell Expires May 27, 2017 [Page 46]
Internet-Draft RAINS November 2016
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://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, <http://www.rfc-editor.org/info/rfc4632>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605,
DOI 10.17487/RFC6605, April 2012,
<http://www.rfc-editor.org/info/rfc6605>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://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,
<http://www.rfc-editor.org/info/rfc7231>.
[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,
<http://www.rfc-editor.org/info/rfc7624>.
Trammell Expires May 27, 2017 [Page 47]
Internet-Draft RAINS November 2016
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<http://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, <http://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,
<http://www.rfc-editor.org/info/rfc7871>.
[SCION] Barrera, D., Reischuk, R., Szalachowski, P., and A.
Perrig, "SCION Five Years Later - Revisiting Scalability,
Control, and Isolation Next-Generation Networks
(arXiv:1508.01651v1)", August 2015.
[XEP0115] Hildebrand, J., Saint-Andre, P., Troncon, R., and J.
Konieczny, "XEP-0115 Entity Capababilities", February
2008.
Appendix A. Directions for future experimentation
The following features were suggested during the design of RAINS, but
have been left out of the current revision of the specification to
allow additional experimentation with them before they are completely
specified.
A.1. Revocation based on hash chains
RAINS assertions are scoped in temporal validity by the lifetimes on
their signatures. This is operationally equivalent to TTL in the
current DNS. An assertion which becomes invalid can simply not be
renewed by its authority. However, very dynamic infrastructures may
require impractical numbers of signatures, and could benefit from
longer validity times. Allowing an assertion to be revoked would
make this possible.
Hash-chain based revocation allows a signature (and the Assertion,
Shard, or Zone it protects) to be replaced before it expires. To use
hash-chain based revocation, a signing entity generates a hash chain
from a known seed using the hash function specified by the signature
algorithm in use, and places the Nth value derived therefrom in the
hash chain revocation token on a signature. When used, this token
Trammell Expires May 27, 2017 [Page 48]
Internet-Draft RAINS November 2016
appears as a byte array after the signature data in the signature
array.
A revocation can be issued by generating a new section and signing
it, revealing the N-1st value from the hash chain in the revocation
token. To allow a recipient of a revoked section to verify the
revocation, the following restrictions on what can replace what
apply:
o An Assertion can only be replaced by another Assertion with the
same Subject within the same Context and Zone, containing an
Objects array of the same length containing the same types of
Objects. To delete Object values, those values can be replaced
with Null in the replacing Assertion.
o A Shard can only be replaced by another Shard with an identical
shard-range key, within the same Context and Zone. Incomplete
Shards cannot be replaced.
o A Zone can only be replaced by another Zone with an identical name
within the same Context.
Two codepoints have been reserved to support experimentation with
this mechanism, as shown in Table 10.
+------+------------+-----------+--------------------+------------+
| Code | Signatures | Hash/HMAC | Format | Revocation |
+------+------------+-----------+--------------------+------------+
| 23 | ecdsa-256 | sha-256 | See Section 5.14.1 | hash-chain |
| | | | | |
| 24 | ecdsa-384 | sha-384 | See Section 5.14.1 | hash-chain |
+------+------------+-----------+--------------------+------------+
Table 10: Defined signature algorithms
The main open question for experimentation is how to ensure that a
revocation is properly propagated through a RAINS infrastructure;
this may require protocol changes to work reliably.
To support this experiment, a server must additionally evaluate an
assertion it receives to determine whether it replaces any
information presently in its cache. If so, it discards the old
information, and caches the new section.
Trammell Expires May 27, 2017 [Page 49]
Internet-Draft RAINS November 2016
Appendix B. Open Issues
o A method for clients to discover local oracles needs to be
specified.
o Reverse DNS must be added. Instead of in-addr.arpa., the RAINS
facility should treat reverse lookups as first-order, with
subject-addr instead of subject-name in assertions and queries.
o Consider making negative answers less expensive by allowing a hash
of a shard with a negative answer proof to be sent back, and
checked with a "no hashed negative answers" query option. This
would increase complexity somewhat, because it would require the
(re-)addition of an Answer section, which could contain such a
beast.
o Consider adding semantics to note-data for automated reaction to
an error. Specifically, notification codes 400, 403, and 413
could use additional data.
Author's Address
Brian Trammell
ETH Zurich NetSec
Universitaetstrasse 6
Zurich 8092
Switzerland
Email: ietf@trammell.ch
Trammell Expires May 27, 2017 [Page 50]