| Network Working Group | B. Trammell |
| Internet-Draft | ETH Zurich |
| Intended status: Experimental | September 20, 2017 |
| Expires: March 24, 2018 |
RAINS (Another Internet Naming Service) Protocol Specification
draft-trammell-rains-protocol-03
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].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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:
Instead of using a custom binary framing as DNS, RAINS uses Concise Binary Object Representation [RFC7049], partially in an effort to make implementations easier to verify and less likely to contain potentially dangerous parser bugs [PARSER-BUGS]. Like DNS, CBOR messages can be carried atop any number of substrate protocols; RAINS is presently defined to use TLS over persistent TCP connections (see Section 7).
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:
The RAINS architecture is simple, and resembles the architecture of DNS. A RAINS Server is an entity that provides transient and/or permanent storage for assertions about names, and a lookup function that finds assertions for a given query about a name, either by searching local storage or by delegating to another RAINS server. RAINS servers can take on any or all of three roles:
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.
The RAINS Protocol is based on an information model built around two kinds of information: Assertions and Queries. An Assertion contains some information about a name or address, and a Query contains a request for information about a name of address. The information model in this section omits information elements required by the resolution mechanism itself; these are defined in more detail in Section 5 and Section 7.
An Assertion is a signed statement about a mapping from a subject name to an object value, and consists of the following elements:
The Types supported for each assertion are:
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.
Assertion contexts are used to determine the validity of the signature by the declared authority as follows:
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:
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.
A signature over an assertion contains the following information elements:
The signature protects all the information in an assertion as well as its own algorithm identifier, keyspace, keyphase, valid-since, and valid-until values; it does not protect other signatures on the assertion.
Assertions may also be grouped and signed as a group. A shard is a set of assertions within the same zone and context, protected by one or more signatures over all assertions within the shard. Shards have an exclusive lexicographic range, and contain all assertions for names within a zone within that range. This lexicographic completeness leads to the property that given a subject and an authenticated shard, it can be shown that either an assertion with a given name and type exists within the shard or does not exist at all.
A shard has the following information elements:
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:
A zone has the following information elements:
A zone may make an assertion about itself by using the string “@” as a subject name. This facility can be used for any assertion type, but is especially useful for self-signing root zones, and for a zone to make a subsequent key assertion about itself. If an assertion of a given type about a zone is available both in the zone itself and in the superordinate zone, the assertion in the superordinate zone will take precedence.
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:
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.
Context is used in queries as it is in assertions (see Section 4.1.1). Assertion contexts in an answer to a query have to match the context in the query in order to respond to a query. The Context section of a query contains the context of desired assertions; a special “any” context (represented by the empty string) indicates that assertions in any context will be accepted.
Query contexts can also be used to provide additional information to RAINS servers about the query. For example, context can provide a method for explicit selection of a CDN server not based on either the client’s or the resolver’s address (see [RFC7871]). Here, the CDN creates a context for each of its content zones, and an external service selects appropriate contexts for the client based not just on client source address but passive and active measurement of performance. Queries for names at which content resides can then be made within these contexts, with the priority order of the contexts 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.
An answer consists of a set of assertions, shards, and/or zones which respond to a query. If the query contained a token, it is bound to that query via the token.
The content of an answer depends on whether the answer is positive or negative. A positive answer contains the information requested in the smallest atomic container that can be found, usually a single assertion. A negative answer contains the information used to verify it; either a Shard, an entire Zone, or a Zone-Nameset assertion showing the name is illegal within the zone.
A query is taken to have an inconclusive answer when no answer returns to the querier before the query’s Valid-Until time.
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:
The following object types are available:
Queries for addresses are similar to those for names, and consist of the following information elements:
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.
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.
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.
The meaning of each of the integer keys in message, zone, shard, assertion, and notification maps is given in the symbol table below:
| Code | Name | Description |
|---|---|---|
| 0 | signatures | Signatures on a message or section |
| 1 | capabilities | Capabilities of server sending message |
| 2 | token | Token for referring to a data item |
| 3 | subject-name | Subject name in an assertion |
| 4 | subject-zone | Zone name in an assertion |
| 5 | subject-addr | Subject address in address assertion or zone |
| 6 | context | Context of an assertion or query |
| 7 | objects | Objects of an assertion |
| 8 | query-name | Fully qualified name for a query |
| 10 | query-types | Acceptable object types for query |
| 11 | shard-range | Lexical range of Assertions in Shard |
| 12 | query-expires | Absolute timestamp for query expiration |
| 13 | query-opts | Set of query options requested |
| 21 | note-type | Notification type |
| 22 | note-data | Additional notification data |
| 23 | content | Content of a message, shard, or zone |
All interactions in RAINS take place in an outer envelope called a Message, which is a CBOR map tagged with the RAINS Message tag (hex 0xE99BA8, decimal 15309736).
A Message map MAY contain a signatures (0) key, whose value is an array of Signatures over the entire message as defined in Section 5.13, to be verified against the infrastructure key for the RAINS Server originating the message.
A Message map MAY contain a capabilities (1) key, whose value is described in Section 5.14.
A Message map MUST contain a token (2) key, whose value is a 16-byte array. See Section 5.12 for details.
A Message map MUST contain a content (23) key, whose value is an array of Message Sections; a Message Section is either an Assertion, Shard, Zone, or Query, or Notification.
Each Message Section in the Message’s content value MUST be a two-element array. The first element in the array is the message section type, encoded as an integer as in Section 5.1. The second element in the array is a message section body, a CBOR map defined as in the subsections shown in Section 5.1:
| Code | Name | Description |
|---|---|---|
| 1 | assertion | Assertion (see Section 5.4) |
| -1 | revassertion | Address Assertion (see Section 5.8) |
| 2 | shard | Shard (see Section 5.5) |
| 3 | zone | Zone (see Section 5.6) |
| 4 | query | Query (see Section 5.7) |
| -4 | revquery | Address Query (see Section 5.9 |
| 23 | notification | Notification (see Section 5.10) |
An Assertion body is a map. The keys present in this map depend on whether the Assertion is contained in a Message Section or in a Shard or Zone.
Assertions contained in Message Sections are “bare Assertions”. Since they cannot inherit any values from their containers, they MUST contain the signatures (0), subject-name (3), subject-zone (4), context (6), and objects (7) keys.
Assertions within a Shard or Zone are “contained Assertions”, and can inherit values from their containers. A contained Assertion MUST contain the subject- name (3) and objects (7) keys. The subject-zone (4) and context (6) keys MUST NOT be present. They are assumed to have the same value as the corresponding values in the containing Shard or Zone for signature generation and signature verification purposes; see Section 5.13.
A contained Assertion SHOULD contain the signatures (0) key, since an unsigned contained Assertion cannot be used by a RAINS server to answer a query; it must be returned in a signed Shard or Zone.
The value of the signatures (0) key, if present, is an array of one or more Signatures as defined in Section 5.13. If not present, the containing Shard or Zone MUST be signed. Signatures on a contained Assertion are generated as if the inherited subject-zone and context values are present in the Assertion, whether actually present or not. The signatures on the Assertion are to be verified against the appropriate key for the Zone containing the Assertion in the given context, as described in Section 4.1.2.
The value of the subject-name (3) key is a UTF-8 encoded [RFC3629] string containing the name of the subject of the assertion. The subject name never contains the zone in which the subject name; the fully-qualified name is obtained by joining the subject-name to the subject-zone with a ‘.’ character. The subject-name must be valid according to the nameset expression for the zone, if any.
The value of the subject-zone (4) key, if present, is a UTF-8 encoded string containing the name of the zone in which the assertion is made. If not present, the zone of the assertion is inherited from the containing Shard or Zone.
The value of the context (6) key, if present, is a UTF-8 encoded string containing the name of the context in which the assertion is valid. If not present, the context of the assertion is inherited from the containing Shard or Zone.
The value of the objects (7) key is an array of objects, as defined in Section 5.11.
A Shard body is a map. The keys present in the map depend on whether the Shard is contained in a Message Section or in a Zone.
Shards contained in Message Sections are “bare Shards”. Since they cannot inherit any values from their contained Zone, they MUST contain the content (23), signatures (0), subject-zone (4), context (6), and shard-range (11) keys.
Shards within a Zone are “contained Shards”, and can inherit values from their containing Zone. A contained Shard MUST contain the shard-range(11) and content (23) keys. The subject-zone (4) and context (6) keys MUST NOT be present. They are assumed to have the same value as the corresponding values in the containing Zone for signature generation and signature verification purposes; see Section 5.13.
A contained Shard SHOULD contain the signatures (0) key if it also contains a shard-range (11) key, since an unsigned contained Shard cannot be used by a RAINS server to answer a query for nonexistence; it must be returned in a signed Zone.
The value of the content (23) key is an array of Assertion bodies as defined in Section 5.4 .Assertions within a Shard SHOULD be sorted by name in ascending lexicographic order.
The value of the signatures (0) key, if present, is an array of one or more Signatures as defined in Section 5.13. If not present, the containing Zone MUST be signed. Signatures on a contained Shard are generated as if the inherited subject-zone and values are present in the Shard, whether actually present or not. The signatures on the Shard are to be verified against the appropriate key for the Zone containing the Shard in the given context, as described in Section 4.1.2.
The value of the subject-zone (4) key, if present, is a UTF-8 encoded string containing the name of the zone in which the Assertions within the Shard is made. If not present, the zone of the assertion is inherited from the containing Zone.
The value of the context (6) key, if present, is a UTF-8 encoded string containing the name of the context in which the Assertions within the Shard are valid. If not present, the context of the assertion is inherited from the containing Zone.
Shards are lexicographically complete within the range described in its the shard-range value: a mapping for a subject-name that should be between the two values given in the range but is not is asserted to not exist. Lexicographic sorting is done on subject names by ordering Unicode codepoints in ascending order.
The shard-range value MUST be a two element array of strings or nulls (subject-name A, subject-name B). A must lexicographically sort before B, but neither subject name need be present in the shard’s contents. If A is null, the shard begins at the beginning of the zone. If B is null, the shard ends at the end of the zone. The shard MUST NOT contain any assertions whose subject names sort before A or after B. In addition, the authority for the shard belongs to MUST NOT make any assertions during the period of validity of the shard’s signatures that would fall between subject-name A and subject-name B inclusive that are not contained within the shard (see Section 7.4).
A Zone body is a map. Zones MUST contain the content (23), signatures (0), subject-zone (4), and context (6) keys.
Signatures on the Zone are to be verified against the appropriate key for the Zone in the given context, as described in Section 4.1.2.
The value of the content (23) key is an array of Shard bodies as defined in Section 5.5 and/or Assertion bodies as defined in Section 5.4. Shards and Assertions in the content array SHOULD be sorted by shard range or name in ascending qlexicographic order.
The value of the subject-zone (4) key is a UTF-8 encoded string containing the name of the Zone.
The value of the context (6) key is a UTF-8 encoded string containing the name of the context for which the Zone is valid.
A Query body is a map. Queries MUST contain the query-name (8), context (6), query-types (10), and query-expires (12) keys. Queries MAY contain the query-opts (13) keys.
The value of the context (6) key is a UTF-8 encoded string containing the name of the context to which a query pertains. A zero-length string indicates that assertions will be accepted in any context.
The value of the query-types (10) key is an array of integers encoding the type(s) of objects (as in Section 5.11) acceptable in answers to the query. All values in the query-type array are treated at equal priority: [2,3] means the querier is equally interested in both IPv4 and IPv6 addresses for the query-name. An empty query-types array indicates that objects of any type are acceptable in answers to the query.
The value of the query-expires (12) key, is a CBOR integer counting seconds since the UNIX epoch UTC, identified with tag value 1 and encoded as in section 2.4.1 of [RFC7049]. After the query-expires time, the query will have been considered not answered by the original issuer.
The value of the query-opts (13) key, if present, is an array of integers in priority order of the querier’s preferences in tradeoffs in answering the query, as in Table 3.
| Code | Description |
|---|---|
| 1 | Minimize end-to-end latency |
| 2 | Minimize last-hop answer size (bandwidth) |
| 3 | Minimize information leakage beyond first hop |
| 4 | No information leakage beyond first hop: cached answers only |
| 5 | Expired assertions are acceptable |
| 6 | Enable query token tracing |
| 7 | Disable verification delegation (client protocol only) |
| 8 | Suppress proactive caching of future assertions |
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.12) should be used on all queries resulting from a given query, allowing traceability through an entire RAINS infrastructure. It is meant for debugging purposes.
By default, a client service will perform verification of negative queries and return a 404 No Assertion Exists for queries with a consistent proof of non- existence, within a message signed by the query service’s infrakey. Option 7 disables this behavior, and causes the query service to return the shard proving nonexistence for verification by the client. It is intended to be used with untrusted query services.
Option 8 specifies that a querier’s interest in a query is strictly ephemeral, and that future assertions related to this query SHOULD NOT be proactively pushed to the querier.
Assertions about addresses are similar to assertions about names, but keyed by address and restricted in terms of the objects they can contain. An Address Assertion body is a map which MUST contain the signatures (0), subject-addr (5), context (6), and objects (7) keys.
The value of the signatures (0) key is an array of one or more Signatures as defined in Section 5.13.
The value of the subject-addr (5) key is a three element CBOR array. The first element of the array is the address family encoded as an object type, 2 for IPv6 addresses and 3 for IPv4 addresses. The second element is the prefix length encoded as an integer, 0-128 for IPv6 and 0-32 for IPv4. The third element is the address, encoded as in Section 5.11. Subject addresses with the maximum prefix length for the address family are subject host addresses, and are nameable; subject addresses with less than the maximum prefix length are subject network addresses, and are delegatable.
The value of the context (6) key, if present, is a UTF-8 string containing the name of the context in which the Address Assertion is valid. See Section 4.3.1.
The value of the objects (7) key is an array of objects, as defined in Section 5.11. Only object types redirection, delegation, and registrant are available for subject network addresses, and only object type name is available for subject host addresses.
Queries for assertions about addresses are similar to queries for assertions about names, but have semantic restrictions similar to those for Address Assertions.
An Address Query body is a map. Queries MUST contain the subject-addr (5), context (6), query-types (10), and query-expires (12) keys. Address Queries MAY contain query-opts (13) key.
The value of the subject-addr (5) key is a three-element CBOR array. The first element of the array is the address family encoded as an object type, 2 for IPv6 addresses and 3 for IPv4 addresses. The second element is the prefix length encoded as an integer, 0-128 for IPv6 and 0-32 for IPv4. The third element is the address, encoded as in Section 5.11.
The value of the context (6) key is a UTF-8 encoded string containing the name of the context for which the Query is valid. Unlike queries for names, Address Queries can only pertain to a single context. See Section 4.3.1 for more.
The value of the query-types (10) key is an array of integers encoding the type(s) of objects (as in Section 5.11) acceptable in answers to the query. All values in the query-type array are treated at equal priority: [4,5] means the querier is equally interested in both redirection and delegation for the subject-addr. An empty query-types array indicates that objects of any type are acceptable in answers to the query.
The value of the query-expires (12) key is a CBOR integer counting seconds since the UNIX epoch UTC, identified with tag value 1 and encoded as in section 2.4.1 of [RFC7049]. After the query-expires time, the query will have been considered not answered by the original issuer.
The value of the query-opts (13) key, if present, is an array of integers in priority order of the querier’s preferences in tradeoffs in answering the query, as in Table 3. See Section 5.7 for more.
An Address Assertion with a more-specific prefix is preferred over a less-specific in response to a Address Query.
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 MAY contain the note-data (22) key. The value of the note-type key is encoded as an integer as in the Table 4.
| Code | Description |
|---|---|
| 100 | Connection heartbeat |
| 399 | Capability hash not understood |
| 400 | Bad message received |
| 403 | Inconsistent message received |
| 404 | No assertion exists (client protocol only) |
| 413 | Message too large |
| 500 | Unspecified server error |
| 501 | Server not capable |
| 504 | No assertion available |
Note that the status codes are chosen to be mnemonically similar to status codes for HTTP [RFC7231]. Details of the meaning of each status code are given in Section 7.
The value of the token (2) key is a 16-byte array, which MUST contain the token of the message or query to which the notification is a response. See Section 5.12.
The value of the note-data (22) key, if present, is a UTF-8 encoded string with additional information about the notification, intended to be displayed to an administrator to help debug the issue identified by the negotiation.
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:
| Code | Name | Description |
|---|---|---|
| 1 | name | name associated with subject |
| 2 | ip6-addr | IPv6 address of subject |
| 3 | ip4-addr | IPv4 address of subject |
| 4 | redirection | name of zone authority server |
| 5 | delegation | public key for zone delgation |
| 6 | nameset | name set expression for zone |
| 7 | cert-info | certificate information for name |
| 8 | service-info | service information for srvname |
| 9 | registrar | registrar information |
| 10 | registrant | registrant information |
| 11 | infrakey | public key for RAINS infrastructure |
| 12 | extrakey | external public key for subject |
| 13 | nextkey | next public key for subject |
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-element array. The second element is a fully-qualified name of an RAINS authority server as a UTF-8 encoded string.
A delegation (5) object contains a public key used to generate signatures on assertions in a named zone, and by which a delegation of a name within a zone to a subordinate zone may be verified. It is represented as an N-element array. The second element is a signature algorithm identifier as in Section 5.13. Additional elements are as defined in Section 5.13 for the given algorithm identifier and keyspace.
A nameset (6) object contains an expression defining which names are allowed and which names are disallowed in a given zone. It is represented as a two- element array. The second element is a nameset expression to be applied to each name element within the zone without an intervening delegation, as defined in Section 5.11.2
A cert-info (7) object contains an expression binding a certificate or certificate authority to a name, such that connections to the name must either use the bound certificate or a certificate signed by a bound authority. It is represented as an five-element array, as defined in Section 5.11.1.
A service-info (8) object gives information about a named service. Services are named as in [RFC2782]. It is represented as a four-element array. The second element is a fully-qualified name of a host providing the named service as a UTF-8 string. The third element is a transport port number as a positive integer in the range 0-65535. The fourth element is a priority as a positive integer, with lower numbers having higher priority.
A registrar (9) object gives the name and other identifying information of the registrar (the organization which caused the name to be added to the namespace) for organization-level names. It is represented as a two element array. The second element is a UTF-8 string of maximum length 256 bytes containing identifying information chosen by the registrar according to the registry’s policy.
A registrant (10) object gives information about the registrant of an organization-level name. It is represented as a two element array. The second element is a UTF-8 string with a maximum length of 4096 bytes containing this information, with a format chosen by the registrar according to the registry’s policy.
An infrakey (11) object contains a public key used to generate signatures on messages by a named RAINS server, by which a RAINS message signature may be verified by a receiver. It is identical in structure to a delegation object, as defined in Section 5.13. Infrakey signatures are especially useful for clients which delegate verification to their query servers to authenticate the messages sent by the query server.
An extrakey (12) object contains a public key used to generate signatures on assertions in a named zone outside of the normal delegation chain. It is represented as an 4-element array, where the second element is a signature algorithm identifier, and the third element is keyspace identifier, as in Section 5.13. The fourth element is the public key, as defined in Section 5.13 for the given algorithm identifier. An extrakey may be matched with a public key obtained through other means for additional authentication of an assertion. Extrakeys are different from delegation keys in that they may not be used in the delegation chain: an extrakey signature is valid only on assertions of object types other than delegation.
A nextkey (13) object contains the a public key that a zone owner would like its superordinate to delegate to in the future. It is represented as an 5-element array The second element is a signature algorithm identifier as in Section 5.13. The third element is the public key, as defined in Section 5.13 for the given algorithm identifier. The fourth element is the requested-valid-since time, and the fifth element is the requested-valid-until time, formatted as for signatures as in Section 5.13. See Section 10.3 for more.
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 | Name | Protocol family | Certificate format |
|---|---|---|---|
| 0 | unspec | Unspecified | Unspecified |
| 1 | tls | Transport Layer Security (TLS) [RFC5246] | [RFC5280] |
Protocol family 0 leaves the protocol family unspecified; client validation and usage of cert-info assertions, and the protocol used to connect, are up to the client, and no information is stored in RAINS. Protocol family 1 specifies Transport Layer Security version 1.2 [RFC5246] or a subsequent version, secured with PKIX [RFC5280] certificates.
| Code | Name | Certificate usage |
|---|---|---|
| 2 | ta | Trust Anchor Certificate |
| 3 | ee | End-Entity Certificate |
A trust anchor certificate constraint specifies a certificate that MUST appear as the trust anchor for the certificate presented by the subject of the assertion on a connection attempt. An end-entity certificate constraint specifies a certificate that MUST be presented by the subject of the assertion on a connection attempt.
| Code | Name | Notes |
|---|---|---|
| 0 | full | Data contains full certificate |
| 1 | sha-256 | Data contains SHA-256 hash (32 bytes) |
| 2 | sha-512 | Data contains SHA-512 hash (64 bytes) |
| 3 | sha-384 | Data contains SHA-384 hash (48 bytes) |
Code 0 is used to store full certificates in RAINS assertions, while other codes are used to store hashes for verification.
For example, in a cert-info object with values [ 7, 1, 3, 3, (data) ], the data would be a 48 SHA-384 hash of the ASN.1 DER-encoded X.509v3 certificate (see Section 4.1 of [RFC5280]) to be presented by the endpoint on a connection attempt with TLS version 1.2 or later.
The 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:
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:]]+
Messages and notifications contain an opaque token (2) key, whose content is a 16-byte array, and is used to link Messages to the Queries they respond to, and Notifications to the Messages they respond to. Tokens MUST be treated as opaque values by RAINS servers.
A Message sent in response to a Query MUST contain the token of the Message containing the Query. Otherwise, the Message MUST contain a token selected by the server originating it, so that future Notifications can be linked to the Message causing it. Likewise, a Notification sent in response to a Message MUST contain the token from the Message causing it (where the new Message contains a fresh token selected by the server). This allows sending multiple Notifications within one Message and the receiving server to respond to a Message containing Notifications (e.g. when it is malformed).
Since tokens are used to link queries to replies, and to link notifications to messages, regardless of the sender or recipient of a message, they MUST be chosen by servers to be hard to guess; e.g. generated by a cryptographic random number generator.
When a server creates a new query to forward to another server in response to a query it received, it MUST NOT use the same token on the delegated query as on the received query, unless option 6 Enable Tracing is present in the received, in which case it MUST use the same token.
RAINS supports multiple signature algorithms and hash functions for signing assertions for cryptographic algorithm agility [RFC7696]. A RAINS signature algorithm identifier specifies the signature algorithm; a hash function for generating the HMAC and the format of the encodings of the signature values in Assertions, Shards, Zones, and Messages, as well as of public key values in delegation objects.
RAINS signatures have five common elements: the algorithm identifier, a keyspace identifier, a keyphase identifier, a valid-since timestamp, and a valid-until timestamp. Signatures are represented as an array of these five values followed by additional elements containing the signature data itself, according to the algorithm identifier.
The following algorithms are supported:
| Alg ID | Signatures | Hash/HMAC | Format |
|---|---|---|---|
| 1 | ed25519 | sha-512 | See Section 5.13.1 |
| 2 | ed448 | shake256 | See Section 5.13.1 |
| 3 | ecdsa-256 | sha-256 | See Section 5.13.2 |
| 4 | ecdsa-384 | sha-384 | See Section 5.13.2 |
As noted in Section 5.13.1, support for Algorithm 1, ed25519, is REQUIRED; other algorithms are OPTIONAL.
The keyspace identifier associates the signature with a method for verifying signatures. This facility is used to support signatures on assertions from external sources (the extrakey object type). At present, one keyspace identifier is defined, and support for it is REQUIRED.
| Keyspace ID | Name | Signature Verification Algorithm |
|---|---|---|
| 0 | rains | RAINS delegation chain; see Section 5.13 |
Within the RAINS delegation chain keyspace, the key phase is an unbounded, unsigned integer matching a signature’s key phase to the delegation key phase. Multiple keys may be valid for a delegation at a given point in time, in order to support seamless rollover of keys, but only one per key phase and algorithm may be valid at once. The third element of delegation objects and signatures is the key phase.
Valid-since and valid-until timestamps are represented as CBOR integers counting seconds since the UNIX epoch UTC, identified with tag value 1 and encoded as in section 2.4.1 of [RFC7049]. A signature MUST have a valid-until timestamp. If a signature has no specified valid-since time (i.e., is valid from the beginning of time until its valid-until timestamp), the valid-since time MAY be null (as in Table 2 in Section 2.3 of [RFC7049]).
A signature in RAINS is generated over a byte stream representing the message in a canonical signing format. The signing process is defined as follows:
To verify a signature, generate the byte stream as for signing, then verify the signature according to the algorithm selected.
EdDSA public keys consist of a single value, a 32-byte bit string generated as in Section 5.1.5 of [RFC8032] for Ed25519, and a 57-byte bit string generated as in Section 5.2.5 of [RFC8032] for Ed448. The fourth element in a RAINS delegation object is this bit string encoded as a CBOR byte array. RAINS delegation objects for Ed25519 keys with value k are therefore represented by the array [5, 1, phase, k]; and for Ed448 keys as [5, 2, phase, k].
Ed25519 and Ed448 signatures are are a combination of two non-negative integers, called “R” and “S” in sections 5.1.6 and 5.2.6, respectively, of [RFC8032]. An Ed25519 signature is represented as a 64-byte array containing the concatenation of R and S, and an Ed448 signature is represented as a 114-byte array containing the concatenation of R and S. RAINS signatures using Ed25519 are therefore the array [1, 0, phase, valid-since, valid-until, R|S]; using Ed448 the array [2, 0, phase, valid-since, valid-until, R|S].
Ed25519 keys are generated as in Section 5.1.5 of [RFC8032], and Ed448 keys as in Section 5.2.5 of [RFC8032]. Ed25519 signatures are generated from a normalized serialized CBOR object as in Section 5.1.6 of [RFC8032], and Ed448 signatures as in section 5.2.6 of [RFC8032].
RAINS Server and Client implementations MUST support Ed25519 signatures for delegation.
ECDSA public keys consist of a single value, called “Q” in [FIPS-186-3]. Q is a simple bit string that represents the uncompressed form of a curve point, concatenated together as “x | y”. The fourth element in a RAINS delegation object is the Q bit string encoded as a CBOR byte array. RAINS delegation objects for ECDSA-256 public keys are therefore represented as the array [5, 3, phase, Q]; and for ECDSA-384 public keys as [5, 4, phase, Q].
ECDSA signatures are a combination of two non-negative integers, called “r” and “s” in [FIPS-186-3]. A Signature using ECDSA is represented using a four-element CBOR array, with the fourth element being “r | s” such that r is represented as a byte array as described in Section C.2 of [FIPS-186-3], and s represented as a byte array as described in Section C.2 of [FIPS-186-3]. For ECDSA-256 signatures, each integer MUST be represented as a 32-byte array. For ECDSA-384 signatures, each integer MUST be represented as a 48-byte array. RAINS signatures using ECDSA-256 are therefore the array [3, 0, phase, valid-since, valid-until, r|s]; and for ECDSA-384 the array [4, 0, phase, valid-since, valid-until, r|s].
ECDSA-256 signatures and public keys use the P-256 curve as defined in [FIPS-186-3]. ECDSA-384 signatures and public keys use the P-384 curve as defined in [FIPS-186-3].
ECDSA-256 and ECDSA-384 support are primarily meant for compatibility with and migration from existing DNSSEC deployments; see Section 10.6.
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:
This mechanism is inspired by [XEP0115], and is intended to be used to reduce the overhead in exposing common sets of capabilities. Each RAINS server can cache a set of recently-seen or common hashes, and only request the full URN set (using notification code 399) on a cache miss.
The following URNs are presently defined; other URNs will specify future optional features, support for alternate transport protocols and new signature algorithms, etc.
| URN | Meaning |
|---|---|
| urn:x-rains:tlssrv | Listens for connections on TLS over TCP from other RAINS servers. |
Since there are only two defined capabilities at this time, RAINS servers can be implemented with two hard-coded hashes to determine whether a peer is listening or not. The hash presented by a server supporting urn:x-rains:tlssrv is e5365a09be554ae55b855f15264dbc837b04f5831daeb321359e18cdabab5745; the hash presented by a server supporting no capabilities is 76be8b528d0075f7aae98d6fa57a6d3c83ae480a8469e668d7b0af968995ac71.
Servers MAY piggyback capability negotiation on other messages, or use dedicated messages for capability negotiation.
A RAINS server MUST NOT assume that a peer server supports a given capability unless it has received a message containing that capability from that server. An exception are the capabilities indicating that a server listens for connections using a given transport protocol; servers and clients can also learn this information from RAINS itself (given a redirection assertion for a named zone) or from external configuration values.
[EDITOR’S NOTE: to define, based on CBOR canonicalization, once this is implemented.]
As noted in Section 5, RAINS is a message-exchange protocol that uses CBOR [RFC7049] as its framing. Since CBOR is self-framing – a CBOR parser can determine when a CBOR object is complete at the point at which it has read its final byte – RAINS requires no external framing. It can therefore run over any streaming, multistreaming, or message-oriented transport protocol. In order to protect query confidentiality, and support rapid deployment over a ubiquitously implemented transport, RAINS is defined in this document to run over persistent TLS 1.2 connections [RFC5246] over TCP [RFC0793] with mutual authentication between servers, and authentication of servers by clients. The TLS certificates of RAINS server peers can be verified as specified in the cert-info assertions for those servers.
RAINS servers MUST support this transport; future transports can be negotiated using the capabilities mechanism after bootstrapping using TLS 1.2. As RAINS is an experimental protocol, RAINS servers listen on port 1022 [RFC4727] for connections from other RAINS servers and clients. RAINS servers should strive to keep connections open to peer servers, unless it is clear that no future messages will be exchanged with those peers, or in the face of resource limitations at either peer. If a RAINS server needs to send a message to another RAINS server to which it does not have an open connection, it attempts to open a connection with that server.
This section describes the operation of the protocol as used among RAINS servers. A simplified version of the protocol for client access is described in Section 8, and a simplified version of the protocol for publication by authorities is described in Section 9.
Once a transport is established, any server may validly send a message with any content to any other server. A client may send messages containing queries to servers, and a server may sent messages containing anything other than queries to clients.
Upon receipt of a message, a server or client attempts to parse it.
If the server or client cannot parse the message at all, it returns a 400 Bad Message notification to the peer. This notification may have a null token if the token cannot be retrieved from the message.
If the server or client can parse the message, it:
On receipt of an assertion, shard, or zone message section, a server:
On receipt of an assertion, shard, or zone message section, a client:
On receipt of a query, a server:
If query delegation fails to return an answer within the maximum of the valid-until time in the received query and a configured maximum timeout for a delegated query, the server prepares to send a 504 No assertion available response to the peer from which it received the query.
When a server creates a new query to forward to another server in response to a query it received, it SHOULD NOT use the same token on the delegated query as on the received query, unless option 6 Enable Tracing is present in the received, in which case it MUST use the same token. The Enable Tracing option is designed to allow debugging of query processing across multiple servers, It SHOULD only be enabled by clients designed explicitly for debugging RAINS itself, and MUST NOT be enabled by default by client resolvers.
When a server creates a new query to forward to another server in response to a query it received, and the received query contains a query-expires time, the delegated query MUST NOT have a query-expires time after that in the received query. If the received query 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:
On receipt of a notification, a client’s behavior depends on the notification type:
The first message a server or client sends to a peer after a new connection is established SHOULD contain a capabilities section, if the server or client supports any optional capabilities. See Section 5.14.
If the server is configured to keep long-running connections open, due to the presence of network behaviors that may drop state for idle connections, it SHOULD send a message containing a type 100 Connection Heartbeat notification after a configured idle time without any messages containing other content being sent.
In general, servers should follow the principles laid out in Sections 4.1 and 4.2 of [I-D.thomson-postel-was-wrong]. A malformed message section, or a message section with any invalid (but not expired) signature, should be dropped and log. A malformed message section or invalid signature should not, however, result in other sections in the same message being dropped, except as explicitly noted above.
As noted in Section 7.1 many messages are sent in reply to messages received from peers. Servers may also originate messages on their own, based on their configuration and policy:
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 Ed25519 signature requires on the order of 180 bytes, it is clear that many full zones won’t fit into a single minimum maximum-size message. Authorities are therefore encouraged to publish zones grouped into shards that will fit into 65536-byte messages, to allow servers to reply using these shards when full-zone transfers are not possible due to message size limitations.
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:
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.
Assertions are not valid unless they contain at least one signature that can be verified from the chain of authorities specified by the name and context on the assertion; integrity protection is built into the information model. The infrastructure key object type allows keys to be associated with RAINS servers in addition to zone authorities, which allows a client to delegate integrity verification of assertions to a trusted query service (see Section 8).
Since the job of an Internet naming service is to provide publicly-available information mapping names to information needed to connect to the services they name, confidentiality protection for assertions is not a goal of the system. Specifically, the information model and the mechanism for proving non-existence of an assertion is not designed to provide resistance against zone enumeration.
On the other hand, confidentiality protection of query information in crucial. Linking naming queries to a specific user can be nearly as useful to build a profile of that user for surveillance purposes as full access to the clear text of that client’s communications [RFC7624]. In this revision, RAINS uses TLS to protect communications between servers and between servers and clients, with certificate information for RAINS infrastructure stored in RAINS itself. Together with hop-by-hop confidentiality protection, query options, proactive caching, default use of non-persistent tokens, and redirection among servers can be used to mix queries and reduce the linkability of query information to specific clients.
Regardless of any other configuration directive, a RAINS server MUST be prepared to provide a full chain of delegation assertions from the appropriate delegation root to the signature on any assertion it gives to a peer or a client, whether as additional assertions on a message answering a query, or in reply to a subsequent query. This property allows RAINS servers to maintain a full delegation tree
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:
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.
The protocol used by authorities to publish assertions to an authority service is a subset of the full RAINS protocol, with the following differences:
The following subsections discuss issues that must be considered in any deployment of RAINS at scale.
An assertion can contain multiple signatures, each with a different lifetime. Signature lifetimes are equivalent to a time to live in the present DNS: authorities should compute a new signature for each validity period, and make these new signatures available when old ones are expiring.
Since assertion lifetime management is based on a real-time clock expressed in UTC, RAINS servers MUST use a clock synchronization protocol such as NTP [RFC5905].
RAINS servers MAY coalesce assertion lifetimes, e.g. using only the most recent valid-until time in their cache management. This implies that an assertion with valid signatures in time intervals (T1, T2) and (T3, T4) such that T3 > T2 may be cached during the interval (T2, T3) as well. Authorites MUST NOT rely on non-caching or non-availability of assertions during such intervals.
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.
As signature lifetime is used to manage assertion lifetime, and key rotation strategies may be used both for revocation as well as operational flexibility purposes, RAINS presents a much more dynamic key management environment than that presented by DNSSEC.
Each signature and public key in a RAINS message is associated with a key phase, allowing multiple keys to be valid for a given authority at any given time. For example, given two key phases and a key validity interval of one day, a phase 0 key would be valid from 00:00 on day 0 to 00:00 on day 1, and a phase 1 key valid from 12:00 on day 0 to 12:00 on day 1. When the phase 0 key expires, it would be replaced by a new phase 0 valid from 00:00 on day 1 to 00:00 on day 2, and so on.
Since the end time of the validity of a signature on an assertion is the maximum of the validity of the signatures on each of the delegations in the delegation chain from the root, key rotation avoids mass expiration of assertions, at the cost of requiring one valid signatures per key phase on at least all delegation assertions. Key rotation schedules are a matter of authority operational policy, but key validity intervals should be longer the closer in the delegation chain an assertion is to the root.
Another problem this dyanmic envrionment raises is how a zone authority communicates to its superordinate that it would like to begin using a new public key to sign its assertions.
This can be done out of band, using private APIs provided by the superordinate authority. Through the nextkey object type, RAINS provides a way for a future public key to be shared with the superordinate authority (and all other queriers) in-band. An authority that wishes to use a new key publishes a reflexive nextkey assertion (i.e., in its own zone, with subject @) with the new public key and a requested valid-since and valid-until time range. The superordinate issues periodic queries for nextkey assertions from its subordinate zone, or the subordinate pushes these assertions to an intermediate service designated to receive them. When the superordinate receives a nextkey, and it decides it wants to delegate to the new key, it creates and signs a delegation assertion.
This process is not mandatory: the superordinate is free to ignore the request, or to use a different time range, depending on its policy and/or the status of its business relationship with the subordinate. The subordinate can discover this, in turn, using its own RAINS queries, or through the delegation assertions being similarly pushed to a designated intermediate service.
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.
A client that will not do its own verification must be able to discover the query server(s) it should trust for resolution. Integration with DHCP is left to a future revision of this document.
In any case, clients MUST provide a configuration interface to allow a user to specify (by address or name) and/or constrain (by certificate property) a preferred/trusted query server. This would allow client on an untrusted network to use an untrusted locally-available query server to discover a preferred query server (doing key verification on its own for bootstrapping), before connecting to that query server for normal name resolution.
Full adoption of RAINS would require changes to every client device (replacing DNS stub resolvers with RAINS clients) and name server on the Internet. In addition, most client software would need to change, as well, to get the full benefits of explicit context in name resolution. This is an unrealistic goal.
RAINS servers can, however, coexist with Domain Name System servers and clients during an indefinite transition period. RAINS assertions can be algorithmically translated into DNS answers, and RAINS queries can be algorithmically translated into DNS queries, by RAINS to DNS gateways, given the mostly compatible information models used by the two.
While DNSSEC and RAINS keys for equivalent ciphersuites are compatible with each other, there is no equivalent to query option 7 for gateways, since the RAINS signatures are generated over the RAINS byte stream for an assertion, not the DNS byte stream. Therefore, RAINS to DNS gateways must provide verification services for DNS clients. DNS over TLS [RFC7858] SHOULD be used between the DNS client and gateway to ensure confidentiality and integrity for queries and answers.
Object type mappings are as follows:
There are a few object types without mappings:
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 “.”.
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.
The present revision of this document has no actions for IANA.
The authors have registered the CBOR tag 15309736 to identify RAINS messages in the CBOR tag registry at https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml.
RAINS servers currently listen for connections from other servers on Port 1022. Future revisions of this document may specify a different port, registered with IANA via Expert Review [RFC5226].
The symbol table in this document in Section 5.1, the notification code table in Section 5.10, and the signature algorithm table in Section 5.13 may be candidates for IANA registries in future revisions of this document.
The urn:x-rains namespace used by the RAINS capability mechanism in Section 5.14 may be a candidate for replacement with an IANA-registered namespace in a future revision of this document.
This document specifies a new, experimental protocol for Internet name resolution, with mandatory integrity protection for assertions about names built into the information model, and confidentiality for query information protected on a hop-by-hop basis. See especially Section 4.1.2, Section 7.5, Section 5.13, Section 5.11.1, and Section 10.2 for security-relevant details.
With respect to the resistance of the protocol itself to various attacks, we consider a few potential attacks against RAINS servers and RAINS clients in the subsections below:
[EDITOR’S NOTE: detail this attack: attacker can create domain, use long-validity queries to exhaust state at server. defense: server can consider shorter validity time than that requested, but not longer. attack: attacker can push garbage assertions proactively. defense: server doesn’t accept assertions it’s never seen a query for. how to handle an attacker that pushes assertions and queries? attack: attacker can push garbage delegations, exhausting delegation chain cache. defense: server doesn’t accept sigs for domains it doesn’t know about, but what about a domain with hundreds of valid delegations? in all cases, blacklisting both clients and domains seems like a good idea.]
[EDITOR’S NOTE: detail this attack: attacker can cause traffic overload at a targeted intermediate or authority service by crafting queries and sending them via multiple query services. There is no amplification here, but a concentration, with indirection that makes tracing difficult.]
Thanks to Daniele Asoni, Laurent Chuat, Markus Deshon, Ted Hardie, Joe Hildebrand, Tobias Klausmann, Steve Matsumoto, Adrian Perrig, Raphael Reischuk, Andrew Sullivan, and Suzanne Woolf for the discussions leading to the design of this protocol. Thanks especially to Stephen Shirley for detailed feedback, and to Christian Fehlmann for extensive implementation experience which has informed the further development of the protocol.