idnits 2.17.1 draft-trammell-rains-protocol-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 10, 2019) is 1932 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 1649 -- Looks like a reference, but probably isn't: '3' on line 1649 == Unused Reference: 'FIPS-186-3' is defined on line 2702, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dprive-dns-over-tls' is defined on line 2763, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dprive-dnsodtls' is defined on line 2769, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-eastlake-fnv-16 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-02) exists of draft-trammell-optional-security-not-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-17 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Trammell 3 Internet-Draft C. Fehlmann 4 Intended status: Experimental ETH Zurich 5 Expires: July 14, 2019 January 10, 2019 7 RAINS (Another Internet Naming Service) Protocol Specification 8 draft-trammell-rains-protocol-04 10 Abstract 12 This document defines an alternate protocol for Internet name 13 resolution, designed as a prototype to facilitate conversation about 14 the evolution or replacement of the Domain Name System protocol. It 15 attempts to answer the question: "how would we design DNS knowing 16 what we do now," on the background of a set of properties of an 17 idealized Internet naming service. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 14, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. About This Document . . . . . . . . . . . . . . . . . . . 5 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. An Ideal Internet Naming Service . . . . . . . . . . . . . . 7 57 3.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.2.1. Meaningfulness . . . . . . . . . . . . . . . . . . . 8 60 3.2.2. Distinguishability . . . . . . . . . . . . . . . . . 8 61 3.2.3. Minimal Structure . . . . . . . . . . . . . . . . . . 9 62 3.2.4. Federation of Authority . . . . . . . . . . . . . . . 9 63 3.2.5. Uniqueness of Authority . . . . . . . . . . . . . . . 9 64 3.2.6. Transparency of Authority . . . . . . . . . . . . . . 9 65 3.2.7. Revocability of Authority . . . . . . . . . . . . . . 10 66 3.2.8. Consensus on Root of Authority . . . . . . . . . . . 10 67 3.2.9. Authenticity of Delegation . . . . . . . . . . . . . 10 68 3.2.10. Authenticity of Response . . . . . . . . . . . . . . 10 69 3.2.11. Authenticity of Negative Response . . . . . . . . . . 10 70 3.2.12. Dynamic Consistency . . . . . . . . . . . . . . . . . 11 71 3.2.13. Explicit Inconsistency . . . . . . . . . . . . . . . 11 72 3.2.14. Global Invariance . . . . . . . . . . . . . . . . . . 12 73 3.2.15. Availability . . . . . . . . . . . . . . . . . . . . 12 74 3.2.16. Lookup Latency . . . . . . . . . . . . . . . . . . . 12 75 3.2.17. Bandwidth Efficiency . . . . . . . . . . . . . . . . 12 76 3.2.18. Query Linkability . . . . . . . . . . . . . . . . . . 12 77 3.2.19. Explicit Tradeoff . . . . . . . . . . . . . . . . . . 13 78 3.2.20. Trust in Infrastructure . . . . . . . . . . . . . . . 13 79 3.3. Observations . . . . . . . . . . . . . . . . . . . . . . 13 80 3.3.1. Delegation and redirection are separate operations . 14 81 3.3.2. Unicode alone may not be sufficient for 82 distinguishable names . . . . . . . . . . . . . . . . 14 83 3.3.3. Implicit inconsistency makes global invariance 84 challenging to verify . . . . . . . . . . . . . . . . 14 85 4. RAINS Protocol Architecture . . . . . . . . . . . . . . . . . 14 86 5. Information and Data Model . . . . . . . . . . . . . . . . . 16 87 5.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 18 88 5.1.1. Message Section structure . . . . . . . . . . . . . . 19 89 5.2. Assertions . . . . . . . . . . . . . . . . . . . . . . . 19 90 5.2.1. Singular Assertions . . . . . . . . . . . . . . . . . 21 91 5.2.2. Shards . . . . . . . . . . . . . . . . . . . . . . . 22 92 5.2.3. Zones . . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.2.4. P-Shards . . . . . . . . . . . . . . . . . . . . . . 24 94 5.2.5. Dynamic Assertion Validity . . . . . . . . . . . . . 25 95 5.2.6. Semantic of nonexistence proofs . . . . . . . . . . . 26 96 5.2.7. Context in Assertions . . . . . . . . . . . . . . . . 26 97 5.2.8. Zone-Reflexive Singular Assertions . . . . . . . . . 27 98 5.3. Object Types and Encodings . . . . . . . . . . . . . . . 27 99 5.3.1. Name Alias . . . . . . . . . . . . . . . . . . . . . 29 100 5.3.2. IPv6 Address . . . . . . . . . . . . . . . . . . . . 29 101 5.3.3. IPv4 Address . . . . . . . . . . . . . . . . . . . . 29 102 5.3.4. Redirection . . . . . . . . . . . . . . . . . . . . . 29 103 5.3.5. Delegation . . . . . . . . . . . . . . . . . . . . . 29 104 5.3.6. Nameset . . . . . . . . . . . . . . . . . . . . . . . 30 105 5.3.7. Certificate Information . . . . . . . . . . . . . . . 31 106 5.3.8. Service Information . . . . . . . . . . . . . . . . . 33 107 5.3.9. Registrar Information . . . . . . . . . . . . . . . . 33 108 5.3.10. Registrant Information . . . . . . . . . . . . . . . 33 109 5.3.11. Infrastructure Key . . . . . . . . . . . . . . . . . 33 110 5.3.12. External Key . . . . . . . . . . . . . . . . . . . . 33 111 5.3.13. Next Delegation Public Key . . . . . . . . . . . . . 34 112 5.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 34 113 5.5. Queries . . . . . . . . . . . . . . . . . . . . . . . . . 35 114 5.5.1. Query Options . . . . . . . . . . . . . . . . . . . . 37 115 5.5.2. Confirmation Queries . . . . . . . . . . . . . . . . 38 116 5.5.3. Context in Queries . . . . . . . . . . . . . . . . . 38 117 5.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 39 118 5.7. Signatures . . . . . . . . . . . . . . . . . . . . . . . 40 119 5.7.1. Canonicalization . . . . . . . . . . . . . . . . . . 42 120 5.7.2. EdDSA signature and public key format . . . . . . . . 43 121 5.8. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 44 122 5.9. Capabilities . . . . . . . . . . . . . . . . . . . . . . 45 123 6. RAINS Protocol . . . . . . . . . . . . . . . . . . . . . . . 46 124 6.1. Transport Bindings . . . . . . . . . . . . . . . . . . . 46 125 6.1.1. TLS over TCP . . . . . . . . . . . . . . . . . . . . 46 126 6.1.2. Heartbeat Messages . . . . . . . . . . . . . . . . . 47 127 6.2. Protocol Dynamics . . . . . . . . . . . . . . . . . . . . 47 128 6.2.1. Message Processing . . . . . . . . . . . . . . . . . 47 129 6.2.2. Message Transmission . . . . . . . . . . . . . . . . 51 130 6.3. Client Protocol . . . . . . . . . . . . . . . . . . . . . 52 131 6.4. Publication Protocol . . . . . . . . . . . . . . . . . . 52 132 6.5. Enforcing Assertion Consistency . . . . . . . . . . . . . 52 133 7. Operational Considerations . . . . . . . . . . . . . . . . . 53 134 7.1. Discovering RAINS servers . . . . . . . . . . . . . . . . 54 135 7.2. Bootstrapping RAINS Services . . . . . . . . . . . . . . 54 136 7.3. Cooperative Delegation Distribution . . . . . . . . . . . 54 137 7.4. Assertion Lifetime Management . . . . . . . . . . . . . . 55 138 7.5. Secret Key Management . . . . . . . . . . . . . . . . . . 55 139 7.6. Public Key Management . . . . . . . . . . . . . . . . . . 55 140 7.6.1. Key Phase and Key Rotation . . . . . . . . . . . . . 56 141 7.6.2. Next Key Assertions . . . . . . . . . . . . . . . . . 56 142 8. Experimental Design and Evaluation . . . . . . . . . . . . . 57 143 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57 144 9.1. Integrity and Confidentiality Protection . . . . . . . . 57 145 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 146 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 147 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 148 12.1. Normative References . . . . . . . . . . . . . . . . . . 58 149 12.2. Informative References . . . . . . . . . . . . . . . . . 60 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 152 1. Introduction 154 This document defines an experimental protocol for providing Internet 155 name resolution services, as a replacement for DNS, called RAINS 156 (RAINS, Another Internet Naming Service). It is designed as a 157 prototype to facilitate conversation about the evolution or 158 replacement of the Domain Name System protocol, and was developed as 159 a name resolution system for the SCION ("Scalability, Control, and 160 Isolation on Next-Generation Networks") future Internet architecture 161 [SCION]. It attempts to answer the question: "how would we design 162 the DNS knowing what we do now," on the background of the properties 163 of an ideal naming service defined in Section 3. 165 Its architecture (Section 4) and information model (Section 5) are 166 largely compatible with the existing Domain Name System. However, it 167 does take several radical departures from DNS as presently defined 168 and implemented: 170 o Delegation from a superordinate zone to a subordinate zone is done 171 solely with cryptography: a superordinate defines the key(s), 172 created by the subordinate, that are valid for signing assertions 173 in the subordinate during a particular time interval. Assertions 174 about names can therefore safely be served from any 175 infrastructure. 177 o All time references in RAINS are absolute: instead of a time to 178 live, each assertion's temporal validity is defined by the 179 temporal validity of the signature(s) on it. 181 o All assertions have validity within a specific context. A context 182 determines the rules for chaining signatures to verify validity of 183 an assertion. The global context is a special case of context, 184 which uses chains from the global naming root key. The use of 185 context explicitly separates global usage of the DNS from local 186 usage thereof, and allows other application-specific naming 187 constraints to be bound to names; see Section 5.2.7. Queries are 188 valid in one or more contexts, with specific rules for determining 189 which assertions answer which queries; see Section 5.5.3. 191 o There is explicit information about registrars and registrants 192 available in the naming system at runtime. 194 o Sets of valid characters and rules for valid names are defined on 195 a per-zone basis, and can be verified at runtime. 197 o Reverse lookups are done using a completely separate tree, 198 supporting delegations of any prefix length, in accordance with 199 CIDR [RFC4632] and the IPv6 addressing architecture [RFC4291]. 201 Instead of using a custom binary framing as DNS, RAINS uses Concise 202 Binary Object Representation [RFC7049], partially in an effort to 203 make implementations easier to verify and less likely to contain 204 potentially dangerous parser bugs [PARSER-BUGS]. As with DNS, CBOR 205 messages can be carried atop any number of substrate protocols. 206 RAINS is presently defined to use TLS over persistent TCP connections 207 (see Section 6). 209 1.1. About This Document 211 The source of this document is available in the repository 212 https://github.com/britram/rains-prototype, and a rendered working 213 copy is available at https://britram.github.io/rains-prototype. Open 214 issues can be seen and discussed at https://github.com/britram/rains- 215 prototype/issues. 217 2. Terminology 219 The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY, when they 220 appear in all-capitals, are to be interpreted as defined in 221 [RFC2119]. 223 In addition, the following terms are used in this document as 224 defined: 226 o Subject: A name or address about which Assertions can be made. 228 o Object: A type/value pair of information about a name within an 229 Assertion. 231 o Assertion: A signed statement about the existence or nonexistence 232 of a mapping from a Subject name and Context to an Object at a 233 given point in time. It is either a Singular Assertion, Shard, or 234 Zone. 236 o Singular Assertion: A mapping between a Subject and one or several 237 Objects, signed by the Authority for the namespace containing that 238 Subject. See Section 5.2. 240 o Authority: An entity that has the right to determine which 241 Assertions exist within its Zone 243 o Delegation: An Assertion proving that an Authority has given the 244 right to make Assertions about names within the part of a 245 namespace identified by a Subject to a subordinate Authority. 246 This subordinate Authority holds a secret key which can generate 247 signatures verifiable using a public key associated with a 248 delegation to the Zone. 250 o Zone: A portion of a namespace rooted at a given point in the 251 namespace hierarchy. A Zone contains all the Assertions about 252 Subjects tha exist within its part of the namespace. 254 o Query: An expression of interest in certain types of objects 255 pertaining to a Subject name in one or more contexts. See 256 Section 5.5. 258 o Context: Additional information about the scope in which an 259 Assertion or Query is valid. See Section 5.2.7 and Section 5.5.3. 261 o Shard: A group of assertions common to a zone and valid at a given 262 point in time, scoped to a lexicographic range of Subject names 263 within the Zone, for purposes of proving nonexistence of an 264 Assertion. Shards may be encoded to provide either absolute proof 265 or probabilistic assurance of nonexistence. See Section 5.2.2 and 266 Section 5.2.4. 268 o RAINS Message: Unit of exchange in the RAINS protocol, containing 269 Assertions, Queries, and/or Notifications. See Section 5.1. 271 o Notification: A RAINS-internal message section carrying 272 information about the operation of the protocol itself. See 273 Section 5.6. 275 o Authority Service: A service provided by a RAINS Server for 276 publishing Assertions by an Authority. See Section 4. 278 o Query Service: A service provided by a RAINS Server for answering 279 Queries on behalf of a RAINS Client. See Section 4. 281 o Intermediary Service: A service provided by a RAINS Server for 282 answering Queries and providing temporary storage for Assertions 283 on behalf of other RAINS Servers. See Section 4. 285 o RAINS Server: A server that supports the RAINS Protocol, and 286 provides one or more services on behalf of other RAINS Servers 287 and/or RAINS Clients. See Section 4. 289 o RAINS Client: A client that uses the Query Service of one or more 290 RAINS Servers to retrieve Assertions on behalf of applications 291 that e.g. wish to connect to named services in the Internet. 293 3. An Ideal Internet Naming Service 295 We begin by returning to first principles, to determine the 296 dimensions of the design space of desirable properties of an 297 Internet-scale naming service. We recognize that the choices made in 298 the evolution of the DNS since its initial design are only one path 299 through the design space of Internet-scale naming services. Many 300 other naming services have been proposed, though none has been 301 remotely as successful for general-purpose use in the Internet. The 302 following subsections outline the space more generally. It is, of 303 course, informed by decades of experience with the DNS, but 304 identifies a few key gaps which we then aim to address directly with 305 the design of RAINS. 307 Section 3.1 defines the set of operations a naming service should 308 provide for queriers and authorities, Section 3.2 defines a set of 309 desirable properties of the provision of this service, and 310 Section 3.3 examines implications of these properties. 312 3.1. Interfaces 314 At its core, a naming service must provide a few basic functions for 315 queriers that associate the subject of a query with information about 316 that subject. The naming service provides the information necessary 317 for a querier to establish a connection with some other entity in the 318 Internet, given a name identifying it. 320 o Name to Address: given a Subject name, the naming service returns 321 a set of addresses associated with that name, if such an 322 association exists. The association is determined by the 323 authority for that name. Names may be associated with addresses 324 in one or more address families (e.g. IP version 4, IP version 325 6). A querier may specify which address families it is interested 326 in. All address families are treated equally by the naming 327 system. This mapping is implemented in the DNS protocol via the A 328 and AAAA RRTYPES. 330 o Address to Name: given an Subject address, the naming service 331 returns a set of names associated with that address, if such an 332 association exists. The association is determined by the 333 authority for that address. This mapping is implemented in the 334 DNS protocol via the PTR RRTYPE. IPv4 mappings exist within the 335 in-addr.arpa. zone, and IPv6 mappings in the ip6.arpa. zone. 336 These mappings imply a limited set of boundaries on which 337 delegations may be made (octet boundaries for IPv4, nybble 338 boundaries for IPv6). 340 o Name to Name: given a Subject name, the naming service returns a 341 set of object names associated with that name, if such an 342 association exists. The association is determined by the 343 authority for the subject name. This mapping is implemented in 344 the DNS protocol via the CNAME RRTYPE. CNAME does not allow the 345 association of multiple object names with a single subject, and 346 CNAME may not combine with other RRTYPEs (e.g. NS, MX) 347 arbitrarily. 349 o Name to Auxiliary Information: given a Subject name, the naming 350 service returns other auxiliary information associated with that 351 name that is useful for establishing communication over the 352 Internet with the entities associated with that name. Most of the 353 other RRTYPES in the DNS protocol implement these sort of 354 mappings. 356 A naming service also provides other interfaces besides the query 357 interface. The interface it presents to an Authority allows updates 358 to the set of Assertions and Delegations in that Authority's 359 namespace. Updates consist of additions of, changes to, and 360 deletions of Assertions and Delegations. In the present DNS, this 361 interface consists of the publication of a new zone file with an 362 incremented version number, but other authority interfaces are 363 possible. 365 3.2. Properties 367 The following properties are desirable in a naming service providing 368 the functions in Section 3.1. 370 3.2.1. Meaningfulness 372 A naming service must provide the ability to name objects that its 373 human users find more meaningful than the objects themselves. 375 3.2.2. Distinguishability 377 A naming service must make it possible to guarantee that two 378 different names are easily distinguishable from each other by its 379 human users. 381 3.2.3. Minimal Structure 383 A naming service should impose as little structure on the names it 384 supports as practical in order to be universally applicable. Naming 385 services that impose a given organizational structure on names will 386 not translate well to societies where that organizational structure 387 is not prevalent. 389 3.2.4. Federation of Authority 391 An Authority can delegate some part of its namespace to some other 392 subordinate Authority. This property allows the naming service to 393 scale to the size of the Internet, and leads to a tree-structured 394 namespace, where each Delegation is itself identified with a Subject 395 at a given level in the namespace. 397 In the DNS protocol, this federation of authority is implemented 398 through delegation using the NS RRTYPE, redirecting queries to 399 subordinate authorities recursively to the final authority. When 400 DNSSEC is used, the DS RRTYPE is used to verify this delegation. 402 3.2.5. Uniqueness of Authority 404 For a given Subject, there is a single Authority that has the right 405 to determine the Assertions and/or Delegations for that subject. The 406 unitary authority for the root of the namespace tree may be special, 407 though; see Section 3.2.8. 409 In the DNS protocol as deployed, unitary authority is approximated by 410 the entity identified by the SOA RRTYPE. The existence of 411 registrars, which use the Extensible Provisioning Protocol (EPP) 412 [RFC5730] to modify entries in the zones under the authority of a 413 top-level domain registry, complicates this somewhat. 415 3.2.6. Transparency of Authority 417 A querier can determine the identity of the Authority for a given 418 Assertion. An Authority cannot delegate its rights or 419 responsibilities with respect to a subject without that Delegation 420 being exposed to the querier. 422 In DNS, the authoritative name server(s) to which a query is 423 delegated via the NS RRTYPE are known. However, we note that in the 424 case of authorities which delegate the ability to write to the zone 425 to other entities (i.e., the registry-registrar relationship), the 426 current DNS provides no facility for a querier to understand on whose 427 behalf an authoritative assertion is being made; this information is 428 instead available via WHOIS. To our knowledge, no present DNS name 429 servers use WHOIS information retrieved out of band to make policy 430 decisions. 432 3.2.7. Revocability of Authority 434 An ideal naming service allows the revocation and replacement of an 435 authority at any level in the namespace, and supports the revocation 436 and replacement of authorities with minimal operational disruption. 438 The current DNS allows the replacement of any level of delegation 439 except the root through changes to the appropriate NS and DS records. 440 Authority revocation in this case is as consistent as any other 441 change to the DNS. 443 3.2.8. Consensus on Root of Authority 445 Authority at the top level of the namespace tree is delegated 446 according to a process such that there is universal agreement 447 throughout the Internet as to the subordinates of those Delegations. 449 3.2.9. Authenticity of Delegation 451 Given a Delegation from a superordinate to a subordinate Authority, a 452 querier can verify that the superordinate Authority authorized the 453 Delegation. 455 Authenticity of delegation in DNS is provided by DNSSEC [RFC4033]. 457 3.2.10. Authenticity of Response 459 The authenticity of every answer is verifiable by the querier. The 460 querier can confirm that the Assertion returned in the answer is 461 correct according to the Authority for the Subject of the query. 463 Authenticity of response in DNS is provided by DNSSEC. 465 3.2.11. Authenticity of Negative Response 467 Some queries will yield no answer, because no such Assertion exists. 468 In this case, the querier can confirm that the Authority for the 469 Subject of the query asserts this lack of Assertion. 471 Authenticity of negative response in DNS is provided by DNSSEC. 473 3.2.12. Dynamic Consistency 475 Consistency in a naming service is important. The naming service 476 should provide the most globally consistent view possible of the set 477 of Assertions that exist at a given point in time, within the limits 478 of latency and bandwidth tradeoffs. 480 When an Authority makes changes to an Assertion, every query for a 481 given Subject returns either the new valid result or a previously 482 valid result, with known and/or predictable bounds on "how 483 previously". Given that additions of, changes to, and deletions of 484 Assertions may have different operational causes, different bounds 485 may apply to different operations. 487 The time-to-live (TTL) on a resource record in DNS provides a 488 mechanism for expiring old resource records. We note that this 489 mechanism makes additions to the system propagate faster than changes 490 and deletions, which may not be a desirable property. However, as no 491 context information is explicitly available in DNS, the DNS cannot be 492 said to be dynamically consistent, as different implicitly 493 inconsistent views of an Assertion may be persistent. 495 3.2.13. Explicit Inconsistency 497 Some techniques require giving different answers to the same query, 498 even in the absence of changes: the stable state of the namespace is 499 not globally consistent. This inconsistency should be explicit: a 500 querier can know that an answer might be dependent on its identity, 501 network location, or other factors. 503 One example of such desirable inconsistency is the common practice of 504 "split horizon" DNS, where an organization makes internal names 505 available on its own network, but only the names of externally- 506 visible subjects available to the Internet at large. 508 Another is the common practice of DNS-based content distribution, in 509 which an authoritative name server gives different answers for the 510 same query depending on the network location from which the query was 511 received, or depending on the subnet in which the end client 512 originating a query is located (via the EDNS Client Subnet extension 513 {RFC7871}}). Such inconsistency based on client identity or network 514 address may increase query linkability (see Section 3.2.18). 516 These forms of inconsistency are implicit, not explicit, in the 517 current DNS. We note that while DNS can be deployed to allow 518 essentially unlimited kinds of inconsistency in its responses, there 519 is no protocol support for a query to express the kind of consistency 520 it desires, or for a response to explicitly note that it is 521 inconsistent. [RFC7871] does allow a querier to note that it would 522 specifically like the view of the state of the namespace offered to a 523 certain part of the network, and as such can be seen as inchoate 524 support for this property. 526 3.2.14. Global Invariance 528 An Assertion which is not intended to be explicitly inconsistent by 529 the Authority issuing it must return the same result for every Query 530 for it, regardless of the identity or location of the querier. 532 This property is not provided by DNS, as it depends on the robust 533 support of the Explicit Inconsistency property above. Examples of 534 global invariance failures include geofencing and DNS-based 535 censorship ordered by a local jurisdiction. 537 3.2.15. Availability 539 The naming service as a whole is resilient to failures of individual 540 nodes providing the naming service, as well as to failures of links 541 among them. Intentional prevention by an adversary of a successful 542 answer to a query should be as hard as practical. 544 The DNS protocol was designed to be highly available through the use 545 of secondary name servers. Operational practices (e.g. anycast 546 deployment) also increase the availability of DNS as currently 547 deployed. 549 3.2.16. Lookup Latency 551 The time for the entire process of looking up a name and other 552 necessary associated data from the point of view of the querier, 553 amortized over all queries for all connections, should not 554 significantly impact connection setup or resumption latency. 556 3.2.17. Bandwidth Efficiency 558 The bandwidth cost for looking up a name and other associated data 559 necessary for establishing communication with a given Subject, from 560 the point of view of the querier, amortized over all queries for all 561 connections, should not significantly impact total bandwidth demand 562 for an application. 564 3.2.18. Query Linkability 566 It should be costly for an adversary to monitor the infrastructure in 567 order to link specific queries to specific queriers. 569 DNS over TLS [RFC7858] and DNS over DTLS [RFC8094] provide this 570 property between a querier and a recursive resolver; mixing by the 571 recursive helps with mitigating upstream linkability. 573 3.2.19. Explicit Tradeoff 575 A querier should be able to indicate the desire for a benefit with 576 respect to one performance property by accepting a tradeoff in 577 another, including: 579 o Reduced latency for reduced dynamic consistency 581 o Increased dynamic consistency for increased latency 583 o Reduced request linkability for increased latency and/or reduced 584 dynamic consistency 586 o Reduced aggregate bandwidth use for increased latency and/or 587 reduced dynamic consistency 589 There is no support for explicit tradeoffs in performance properties 590 available to clients in the present DNS. 592 3.2.20. Trust in Infrastructure 594 A querier should not need to trust any entity other than the 595 authority as to the correctness of association information provided 596 by the naming service. Specifically, the querier should not need to 597 trust any intermediary of infrastructure between itself and the 598 authority, other than that under its own control. 600 DNS provides this property with DNSSEC. However, the lack of 601 mandatory DNSSEC, and the lack of a viable transition strategy to 602 mandatory DNSSEC (see [I-D.trammell-optional-security-not]), means 603 that trust in infrastructure will remain necessary for DNS even with 604 large scale DNSSEC deployment. 606 3.3. Observations 608 On a cursory examination, many of the properties of our ideal name 609 service can be met, or could be met, by the present DNS protocol or 610 extensions thereto. We note that there are further possibilities for 611 the future evolution of naming services meeting these properties. 612 This section contains random observations that might inform future 613 work. 615 3.3.1. Delegation and redirection are separate operations 617 Any system which can provide the authenticity properties enumerated 618 above is freed from one of the design characteristics of the present 619 domain name system: the requirement to bind a zone of authority to a 620 specific set of authoritative servers. Since the authenticity of a 621 delegation must be protected by a chain of signatures back to the 622 root authority, the location within the infrastructure where an 623 authoritative mapping "lives" is no longer bound to a specific name 624 server. While the present design of DNS does have its own 625 scalability advantages, this implication allows a much larger design 626 space to be explored for future name service work, as a Delegation 627 need not always be implemented via redirection to another name 628 server. 630 3.3.2. Unicode alone may not be sufficient for distinguishable names 632 Allowing names to be encoded in Unicode goes a long way toward 633 meeting the meaningfulness property (see Section 3.2.1) for the 634 majority of speakers of human languages. However, as noted by the 635 Internet Architecture Board (see [IAB-UNICODE7]) and discussed at the 636 Locale-free Unicode Identifiers (LUCID) BoF at IETF 92 in Dallas in 637 March 2015 (see [LUCID]), it is not in the general case sufficient 638 for distinguishability (see Section 3.2.2). An ideal naming service 639 may therefore have to supplement Unicode by providing runtime support 640 for disambiguation of queries and assertions where the results may be 641 indistinguishable. 643 3.3.3. Implicit inconsistency makes global invariance challenging to 644 verify 646 DNS does not provide a generalized form of explicit inconsistency, so 647 efforts to verify global invariance, or rather, to discover 648 Assertions for which global invariance does not hold, are necessarily 649 effort-intensive and dynamic. For example, the Open Observatory of 650 Network Interference performs DNS consistency checking from multiple 651 volunteer vantage points for a set of targeted (i.e., likely to be 652 globally variant) domain names; see 653 https://ooni.torproject.org/nettest/dns-consistency/. 655 4. RAINS Protocol Architecture 657 The RAINS architecture is simple, and vaguely resembles the 658 architecture of DNS. A RAINS Server is an entity that provides 659 transient and/or permanent storage for assertions about names and 660 addresses, and a lookup function that finds assertions for a given 661 query about a name or address, either by searching local storage or 662 by delegating to another RAINS server. RAINS servers can take on any 663 or all of three roles: 665 o authority service, acting on behalf of an authority to ensure 666 properly signed assertions are made available to the system 667 (equivalent to an authoritative server in DNS); 669 o query service, acting on behalf of a client to answer queries with 670 relevant assertions (equivalent to a recursive resolver in DNS), 671 and to validate assertions on the client's behalf; and/or 673 o intermediary service, acting on behalf of neither but providing 674 storage and lookup for assertions with certain properties for 675 query and authority servers (partially replacing, but not really 676 equivalent to, caching resolvers in DNS). 678 RAINS Servers use the RAINS Protocol defined in this document to 679 exchange queries and assertions. 681 From the point of view of an authority (an entity owning some part of 682 the namespace by virtue of holding private keys associated with a 683 zone delegation), the RAINS protocol is used to publish signed 684 assertions toward one or more RAINS servers configured to provide 685 authority service for their domains. Since the signatures on these 686 assertions expire periodically, the authority must publish assertions 687 continuously toward the authority services. In order to provide a 688 DNS-like operational experience, a RAINS server providing authority 689 service may be colocated with the infrastructure for publishing 690 assertions; however, the architecture of the protocol means these 691 functions need not be colocated. 693 Clients are configured, or use some out-of-band discovery mechanism, 694 to contact one or more query services using the RAINS protocol, and 695 may trust those services to verify assertion signatures on the 696 client's behalf. 698 In this way, the same protocol is used between servers, from client 699 to server, and from publisher to server, with minor differences among 700 the interactions implemented as profiles. See Section 6 for details 702 The protocol itself is designed in terms of its information and data 703 model, detailed in Section 5. Since all RAINS information is carried 704 in messages containing assertions, and an assertion is not valid 705 unless it is signed, the validity of an assertion is separated from 706 whence the assertion was received. This means the RAINS protocol 707 itself is merely a means for moving RAINS assertions around, and 708 moving RAINS queries to places where they can be answered. This 709 document defines bindings for carrying RAINS messages over TLS over 710 TCP, but bindings to other transports (e.g. QUIC [QUIC]) or session 711 layers (e.g. HTTP [RFC7540]) would be trivial to design, and the 712 protocol provides a capability mechanism for discovering alternate 713 transports. 715 5. Information and Data Model 717 The RAINS Protocol is based on an information model containing three 718 primary kinds of objects: Assertions, Queries, and Notifications. An 719 Assertion contains some information about a name or address, and a 720 Query contains a request for information about a name or address. 721 Queries are answered with Assertions. Notifications provide 722 information about the operation of the protocol itself. The protocol 723 exchanges RAINS Messages, which act as envelopes containing 724 Assertions, Queries, and Notifications. RAINS Messages also provide 725 for capabilities-based versioning of the protocol, and for 726 recognition of a chunk of CBOR-encoded binary data at rest to be 727 recognized as a RAINS message. 729 The RAINS data model is a relatively straightforward mapping of the 730 information model to the Concise Binary Object Representation (CBOR) 731 [RFC7049], such that Assertions are split into four subtypes 732 depending on their scope and purpose: 734 o Singular Assertions and Zones for a positive proof of the 735 existence of an association between a name and an Object; 737 o Shards and P-Shards for negative proof thereof. 739 Messages, Singular Assertions, Shards, P-Shards, Zones, Queries, and 740 Notifications are each represented as a CBOR map of integer keys to 741 values, which allows each of these types to be extended in the 742 future, as well as the addition of non-standard, application-specific 743 information to RAINS messages and data items. A common registry of 744 map keys is given in Table 1. RAINS implementations MUST ignore any 745 data objects associated with map keys they do not understand. 746 Integer map keys in the range -22 to +23 are reserved for the use of 747 future versions or extensions to the RAINS protocol, due to the 748 efficiency of representation of these values in CBOR. 750 Message and Assertion contents, signatures and object values are 751 implemented as type- prefixed CBOR arrays with fixed meanings of each 752 array element; the structure of these lower-level elements can 753 therefore not be extended. Message section types are given in 754 Table 2, object types in Table 4, and signature algorithms in 755 Table 10. 757 +------+-----------------+------------------------------------------+ 758 | Code | Name | Description | 759 +------+-----------------+------------------------------------------+ 760 | 0 | signatures | Signatures on a message or section | 761 | | | | 762 | 1 | capabilities | Capabilities of server sending message | 763 | | | | 764 | 2 | token | Token for referring to a data item | 765 | | | | 766 | 3 | subject-name | Subject name in an Assertion, Shard, | 767 | | | P-Shard or Zone | 768 | | | | 769 | 4 | subject-zone | Zone name in an Assertion, Shard, | 770 | | | P-Shard or Zone | 771 | | | | 772 | 5 | subject-addr | Subject address in address assertion | 773 | | | | 774 | 6 | context | Context of an Assertion, Shard, P-Shard, | 775 | | | Zone or Query | 776 | | | | 777 | 7 | objects | Objects of an Assertion | 778 | | | | 779 | 8 | query-name | Fully qualified name for a Query | 780 | | | | 781 | 9 | reserved | Reserved for future use | 782 | | | | 783 | 10 | query-types | Acceptable object types for a Query | 784 | | | | 785 | 11 | range | Lexical range of Assertions in Shard or | 786 | | | P-Shard | 787 | | | | 788 | 12 | query-expires | Absolute timestamp for query expiration | 789 | | | | 790 | 13 | query-opts | Set of query options requested | 791 | | | | 792 | 14 | current-time | Querier's latest assertion timestamp for | 793 | | | a query | 794 | | | | 795 | 15 | reserved | Reserved for future use | 796 | | | | 797 | 16 | reserved | Reserved for future use | 798 | | | | 799 | 17 | query-keyphases | All requested key phases of a Query | 800 | | | | 801 | 19 | reserved | Reserved for future use | 802 | | | | 803 | 20 | assertions | Singular Assertion content of a Shard or | 804 | | | Zone | 805 | | | | 806 | 21 | note-type | Notification type | 807 | | | | 808 | 22 | note-data | Additional notification data | 809 | | | | 810 | 23 | content | Content of a Message or a P-Shard | 811 +------+-----------------+------------------------------------------+ 813 Table 1: CBOR Map Keys used in RAINS 815 The information model is designed to be representation-independent, 816 and can be rendered using alternate structured-data representations 817 that support the concepts of maps and arrays. For example, YAML or 818 JSON could be used to represent RAINS messages and data structures 819 for debugging purposes. However, signatures over messages and 820 assertions need a single canonical representation of the object to be 821 signed as a bitstream. For RAINS, this is the CBOR representation 822 canonicalized as in Section 5.7.1; therefore alternate 823 representations are always secondary to the CBOR data model. 825 The following subsections describe the information and data model of 826 a RAINS message from the top down. 828 5.1. Messages 830 A Message is a self-contained unit of exchange in the RAINS protocol. 831 Messages have some content (the Assertions, Queries, and/or 832 Notifications carried by the Message) tagged with a token (see 833 Section 5.8). They may also carry information about peer 834 capabilities, and an optional signature. 836 More concretely, a Message is represented as a CBOR map with the CBOR 837 tag value 15309736, which identifies the map as a RAINS message. 838 This map MUST contain a token key (2) and a content key (23), and MAY 839 contain a capabilities key (1) a signatures key (0). 841 The value of the content key is an array of zero or more Message 842 Sections, as defined in Section 5.1.1 844 The value of the token key is an opaque 16-byte octet array used to 845 link Messages, Queries, and Notifications; see Section 5.8 for 846 details. 848 The value of the signatures key, when present, is an array of 849 Signatures over the entire Message, generated as in Section 5.7, and 850 to be verified against an infrastructure key (see Section 5.3.11) for 851 the RAINS Server originating the message. 853 The value of the capabilities key, when present, is an array of 854 Capabilities or the hash thereof. The first Message sent from one 855 peer to another MUST contain the capabilities key. The capabilities 856 mechanism is described in Section 5.9. 858 5.1.1. Message Section structure 860 Each Message Section in the Message's content value is represented as 861 a two-element array. The first element in the array is the message 862 section type, encoded as an integer as in Table 2. The second 863 element in the array is a message section body, a CBOR map defined as 864 in the subsections Section 5.2, Section 5.5, and Section 5.6 866 +------+--------------+----------------------------------------+ 867 | Code | Name | Description | 868 +------+--------------+----------------------------------------+ 869 | 1 | assertion | Singular Assertion (see Section 5.2.1) | 870 | | | | 871 | 2 | shard | Shard (see Section 5.2.2) | 872 | | | | 873 | 3 | p-shard | P-Shard (see Section 5.2.4) | 874 | | | | 875 | 4 | zone | Zone (see Section 5.2.3) | 876 | | | | 877 | 5 | query | Query (see Section 5.5) | 878 | | | | 879 | 23 | notification | Notification (see Section 5.6) | 880 +------+--------------+----------------------------------------+ 882 Table 2: Message Section Type Codes 884 5.2. Assertions 886 Information about names in RAINS is carried by Assertions. An 887 Assertion is a statement about a mapping from a Subject name to one 888 or several Object values, signed by some Authority for the namespace 889 containing the Assertion, with a temporal validity determined by the 890 lifetime of the signature(s) on the Assertion. 892 The subject of an Assertion is identified by a name in three parts: 894 o the subject zone name, identifying the namespace within which the 895 subject is contained; 897 o the subject name, identifying the name of the subject within that 898 zone; and 900 o the subject context, as in Section 5.2.7, identifying the context 901 for purposes of explicit inconsistency. 903 The types of Objects that can be associated with a Subject are 904 described in Section 5.3. 906 There are four kinds of Assertions, distinguished by their scope (how 907 many Subjects are covered by a single Assertion) and their utility 908 (whether the Assertion can be used for positive proof of a Subject- 909 Object association, for negative proof of the lack of such an 910 association, or both): 912 o Singular Assertions contain a set of Objects associated with a 913 single given subject name in a given zone in a given context. The 914 signature on a Singular Assertion can be used to prove the 915 existence of an association between the subject name and the 916 Objects within the Assertion. Singular Assertions are described 917 in detail in Section 5.2.1. 919 o Zones contain all Singular Assertions that have the same zone and 920 context values. The signature on a Zone can be used to prove both 921 the existence of an association between a subject name and an 922 Object, as well as the absence of such an association. Zones are 923 described in detail in Section 5.2.3. If signed, the Singular 924 Assertions within a Zone can also be used on their own, as if they 925 were contained within a Message directly; in this case they 926 inherit zone and context information from the containing zone. 928 o Shards contain Singular Assertions for every Object associated 929 with every subject name in a given lexicographic range of subject 930 names within a given zone in a given context. The signature on a 931 Shard can be used to prove the nonexistence of an Object for a 932 subject name within its range. Shards are described in detail in 933 Section 5.2.2. If a Singular Assertion within a Shard is signed, 934 it inherits zone and context information from the containing shard 935 and can also be used outside the Shard. 937 o P-Shards (or Probabilistic Shards) contain a data structure that 938 can be used to demonstrate, within predictable bounds of false- 939 negative probability, the nonexistence of an Object for a subject 940 name within a lexicographic range of subject names within a given 941 zone in a given context. They allow an efficiency-accuracy 942 tradeoff for negative proofs. P-Shards are described in detail in 943 Section 5.2.4 945 5.2.1. Singular Assertions 947 A Singular Assertion contains a set of Objects associated with a 948 single given subject name in a given zone in a given context. A 949 Singular Assertion with a valid signature can be used as a positive 950 answer to a query for a name. It is represented as a CBOR map. The 951 keys present in this map depend on whether the Singular Assertion is 952 contained in a Message, Shard or Zone. 954 Singular Assertions contained directly within a Message's content 955 value cannot inherit any values from their containers, and therefore 956 MUST contain the signatures (0), subject-name (3), subject-zone (4), 957 context (6), and objects (7) keys. 959 Singular Assertions within a Shard or Zone can inherit values from 960 their containers. A contained Singular Assertion MUST contain the 961 subject-name (3), and objects (7) keys. It MAY contain the 962 signatures (0) key. The subject-zone (4) and context (6) keys MUST 963 NOT be present. They are assumed to have the same value as the 964 corresponding values in the containing Shard or Zone for signature 965 generation and signature verification purposes; see Section 5.7. 967 The value of the signatures (0) key, if present, is an array of one 968 or more Signatures as defined in Section 5.7. Signatures on a 969 contained Assertion are generated as if the inherited subject-zone 970 and context values are present in the Assertion. The signatures on 971 the Assertion are to be verified against the appropriate key for the 972 Zone containing the Assertion in the given context. 974 The value of the subject-name (3) key is a UTF-8 encoded [RFC3629] 975 string containing the name of the subject of the assertion. The 976 subject name may cover multiple levels of hierarchy, separated by the 977 '.' character. The fully-qualified name of an Assertion is obtained 978 by joining the subject-name to the subject-zone with a '.' character. 979 The subject-name must be valid according to the nameset expression 980 for the zone, if any (see Section 5.3.6). 982 The value of the subject-zone (4) key, if present, is a UTF-8 encoded 983 string containing the name of the zone in which the assertion is made 984 and MUST end with '.' (the root zone). If not present, the zone of 985 the assertion is inherited from the containing Shard or Zone. 987 The value of the context (6) key, if present, is a UTF-8 encoded 988 string containing the name of the context in which the assertion is 989 valid. Both the authority-part and the context-part MUST end with a 990 '.'. If not present, the context of the assertion is inherited from 991 the containing Shard or Zone. See Section 5.2.7 for more. 993 The value of the objects (7) key is an array of objects, as defined 994 in Section 5.3. 996 5.2.2. Shards 998 A Shard contains Singular Assertions for every Object within a zone 999 in a given context whose subject name falls within a specified 1000 lexicographic range. A Shard with a valid signature, within which a 1001 subject name should fall (i.e. appearing within that Shard's range), 1002 but within which there is no Singular Assertion for the specified 1003 subject name and Object, can therefore be taken as a proof of 1004 nonexistence for that subject name and Object. Shards are used 1005 exclusively for negative proof; the individual signatures on their 1006 contained Singular Assertions are used for positive proof of the 1007 existence of an assertion. 1009 The content of a Shard (in terms of the number of Singular Assertions 1010 it covers) is chosen by the Authority of the zone for which the Shard 1011 is valid. There is an inherent tradeoff between the number of 1012 Singular Assertions within a Shard and the size of the Shard, and 1013 therefore the size of the Message that must be presented as negative 1014 proof. P-Shards ("Probabalistic Shards", see Section 5.2.4) allow a 1015 different tradeoff, gaining space efficiency and coverage for a 1016 fixed, predictable probability of a false positive (i.e., the 1017 possibility that the P-Shard cannot be used to prove the nonexistence 1018 of a subject which does not, in fact, exist). 1020 A Shard is represented as a CBOR map. Shards MUST contain the 1021 signatures (0), subject-zone (4), context (6), range (11), and 1022 assertions (20) keys. 1024 The value of the signatures (0) key is an array of one or more 1025 Signatures as defined in Section 5.7. Signatures on the Shard are to 1026 be verified against the appropriate key for the Shard in the given 1027 context. 1029 The value of the subject-zone (4) key is a UTF-8 encoded string 1030 containing the name of the zone in which the Singular Assertions 1031 within the Shard are made and MUST end with '.' (the root zone). 1033 The value of the context (6) key is a UTF-8 encoded string containing 1034 the name of the context in which the Singular Assertions within the 1035 Shard are valid. Both the authority-part and the context-part MUST 1036 end with a '.'. 1038 The value of the range (11) key is a two element array of strings or 1039 nulls (subject-name A, subject-name B). A MUST lexicographically 1040 sort before B. If A is null, the shard begins at the beginning of 1041 the zone. If B is null, the shard ends at the end of the zone. The 1042 shard MUST NOT contain any Singular Assertions whose subject names 1043 are equal to or sort before A, or are equal to or sort after B. 1045 The value of the assertions (20) key is a CBOR array of Singular 1046 Assertions as defined in Section 5.2.1. These Singular Assertions 1047 MUST be sorted (see Section 5.7.1); the set of allowable Singular 1048 Assertions is restricted by the range, as above. 1050 5.2.3. Zones 1052 A Zone contains Singular Assertions for every Object associated with 1053 every subject name within a given zone in a given context. A Zone 1054 with a valid signature can be used either as a positive answer for a 1055 query about a name (when its contained Singular Assertions are not 1056 signed), or as a negative answer to prove that a given Object does 1057 not exist for a given name. 1059 Organizing Singular Assertions into Zones allows operators of zones 1060 with few subject names (e.g., used only for simple web hosting, as is 1061 the case with many zones in the current Internet naming system) to 1062 minimize signing and zone management overhead. 1064 A Zone is represented as a CBOR map. Zones MUST contain the 1065 signatures (0), subject-zone (4), context (6), and assertions (20) 1066 keys. 1068 The value of the signatures (0) key is an array of one or more 1069 Signatures on the Zone as defined in Section 5.7. Signatures on the 1070 Zone are to be verified against the appropriate key for the Zone in 1071 the given context. 1073 The value of the subject-zone (4) key is a UTF-8 encoded string 1074 containing the name of the Zone which MUST end with '.' (the root 1075 zone). 1077 The value of the context (6) key is a UTF-8 encoded string containing 1078 the name of the context for which the Zone is valid. Both the 1079 authority-part and the context-part MUST end with a '.'. See 1080 Section 5.2.7 1082 The value of the assertions (20) key is a CBOR array of Singular 1083 Assertions as defined in Section 5.2.1. The CBOR array contains all 1084 Singular Assertions of this zone and context and they MUST be sorted 1085 (see Section 5.7.1). 1087 5.2.4. P-Shards 1089 Shards (Section 5.2.2) can be used as definitive proof of the 1090 nonexistence of a name within a zone. P-Shards serve the same 1091 purpose, but offer only a probabilistic guarantee of the nonexistence 1092 of a name. Specifically, as they are based on Bloom filters, a 1093 subject name which does not in fact exist may appear in the P-Shard; 1094 in return for this uncertainty, they offer a much more space- 1095 efficient way to demonstrate the nonexistence of an Object for a 1096 subject name within the zone and context than Shards do. There is a 1097 tradeoff between the size of the bit string storing the Bloom filter, 1098 the number of names covered by the P-Shard, and the false positive 1099 error rate. The zone Authority can determine how to weight them. 1101 A P-Shard is represented as a CBOR map. This map MUST contain the 1102 signatures (0), subject-zone (4), context (6), and content(23) keys. 1103 It MAY contain the range(11) key. 1105 The value of the signatures (0) key is an array of one or more 1106 Signatures as defined in Section 5.7. The signatures on the P-Shard 1107 are to be verified against the appropriate key for the Zone for which 1108 the P-Shard is valid in the given context. 1110 The value of the subject-zone (4) key is a UTF-8 encoded string 1111 containing the name of the zone within which the names represented in 1112 the P-Shard are contained, and MUST end with '.' (the root zone). 1114 The value of the context (6) key is a UTF-8 encoded string containing 1115 the name of the context for which the names represented in the 1116 P-Shard are valid. Both the authority-part and the context-part MUST 1117 end with a '.'. 1119 The value of the range (11) key, if present, is a two element array 1120 of strings or nulls (subject-name A, subject-name B). A MUST 1121 lexicographically sort before B. If A is null, the P-Shard begins at 1122 the beginning of the zone. If B is null, the P-Shard ends at the end 1123 of the zone. The P-Shard MUST NOT be used to check the existence of 1124 Assertions about subject names equal to or sort before A, or are 1125 equal to or sort after B. If the range (11) key is not present, the 1126 P-Shard covers then entire zone. 1128 The value of the content (23) key is a three-element array. The 1129 first element identifies the algorithm used for generating the 1130 bitstring. The second element identifies the hash function in use 1131 for generating the bitstring. The third element contains the 1132 bitstring itself, as an octet array. The size of the bitstring must 1133 be 0 mod 8. 1135 Table 3 enumerates supported generation algorithms; supported hash 1136 functions are given in Section 5.4. 1138 +------+-------------+--------------------------------------+ 1139 | Code | Name | Description | 1140 +------+-------------+--------------------------------------+ 1141 | 1 | bloom-km-12 | KM-optimized bloom filter with nh=12 | 1142 | | | | 1143 | 2 | bloom-km-16 | KM-optimized bloom filter with nh=16 | 1144 | | | | 1145 | 3 | bloom-km-20 | KM-optimized bloom filter with nh=20 | 1146 | | | | 1147 | 4 | bloom-km-24 | KM-optimized bloom filter with nh=24 | 1148 +------+-------------+--------------------------------------+ 1150 Table 3: P-shard generation algorithms 1152 These datastructures generate a bitstring using a Bloom filter and 1153 the Kirsch-Mitzenmacher optimization [BETTER-BLOOM-FILTER]. 1155 To add a subject-object mapping for a name to a bloom-km structure, 1156 the mapping is first encoded as a four-element CBOR array. The first 1157 element is the subject name. The second element is the subject zone. 1158 The third element is the subject context. The fourth element is the 1159 type code as in Table 4 in Section 5.3. This encoded object is then 1160 hashed according to the specified hash algorithm. The hash 1161 algorithm's output is then split into two parts of equal length x and 1162 y. To obtain the nh indexes into the bitstring, the following 1163 equation is used: 1165 o (x + i*y) mod bsl, where bsl is the bitstring length and i ∈ 1166 [1,nh] 1168 To add a subject-object mapping, all bits at the calculated indices 1169 are set to one. To check wether such a mapping exists, all bits at 1170 the calculated indices are checked, and the mapping is taken to be in 1171 the filter if all bits are one. 1173 5.2.5. Dynamic Assertion Validity 1175 For a given {subject, zone, context, type} tuple, multiple Singular 1176 Assertions can be valid at a given point in time; the union of the 1177 object values of all of these Singular Assertions is considered to be 1178 the set of valid values at that point in time. 1180 5.2.6. Semantic of nonexistence proofs 1182 Shards, P-Shards and Zones can all be used to prove nonexistence 1183 during their validity. However, real naming systems are dynamic: an 1184 Assertion might be created, altered, expired or revoked during the 1185 validity period of a Shard, P-Shard or Zone, leading to an 1186 inconsistency. Thus, a section proving nonexistence only captures 1187 the state at the point in time when it was signed. 1189 5.2.7. Context in Assertions 1191 Assertion contexts are used to provide explicit inconsistency, while 1192 allowing Assertions themselves to be globally valid regardless of the 1193 query to which they are given in reply. Explicit inconsistency is 1194 the simultaneous validity of multiple sets of Assertions for a single 1195 subject name at a given point in time. Explicit inconsistency is 1196 implemented by using the context to select an alternate chain of 1197 signatures to use to verify the validity of an Assertion, as follows: 1199 o The global context is identified by the special context name '.'. 1200 Assertions in the global context are signed by the Authority for 1201 the subject zone. For example, assertions about the name 1202 'ethz.ch.' in the global context are only valid if signed by the 1203 relevant Authority which is either 'ethz.ch.', 'ch.', or '.' 1204 depending on the value of the subject zone of the Assertion. 1206 o A local context is associated with a given Authority. The local 1207 context's name is divided into an authority-part and a context- 1208 part by a context marker ('cx-'). The authority-part directly 1209 identifies the Authority whose key was used to sign the Assertion; 1210 Assertions within a local context are only valid if signed by the 1211 identified Authority. Authorities have complete control over how 1212 the contexts under their namespaces are arranged, and over the 1213 names within those contexts. Both the authority-part and the 1214 context-part must end with a '.'. 1216 Some examples illustrate how context works: 1218 o For the common split-DNS case, an enterprise could place names for 1219 machines on its local networks within a separate context. E.g., a 1220 workstation could be named 'simplon.cab.inf.ethz.ch.' within the 1221 context 'staff-workstations.cx-inf.ethz.ch.' Assertions about 1222 this name would be signed by the Authority for 'inf.ethz.ch.'. 1223 Here, the context serves simply as a marker, without enabling an 1224 alternate signature chain: note that the name 1225 'simplon.cab.inf.ethz.ch' could at the same time be validly signed 1226 in the global context by the Authority over that name to allow 1227 external users access this workstation. The local context simply 1228 marks this Assertion as internal. This allows a client making 1229 requests of local names to know they are local, and for local 1230 resolvers to manage visibility of Assertions outside the 1231 enterprise: explicit context makes accidental leakage of both 1232 Queries and Assertions easier to detect and avoid. 1234 o Contexts make captive-portal interactions more explicit: a captive 1235 portal resolver could respond to a query for a common website 1236 (e.g. www.google.ch) with a signed response directed at the 1237 captive portal, but within a context identifying the location as 1238 well as the ISP (e.g. sihlquai.zurich.ch.cx- 1239 starbucks.access.some-isp.net.). This response will be signed by 1240 the Authority for 'starbucks.access.some-isp.net.'. This 1241 signature achieves two things: first, the client knows the result 1242 for www.google.ch is not globally valid; second, it can present 1243 the user with some indication as to the identity of the captive 1244 portal it is connected to. 1246 Further examples showing how context can be used in queries as well 1247 are given in Section 5.5.3 below. 1249 Developing conventions for assertion contexts for different 1250 situations will require implementation and deployment experience, and 1251 is a subject for future work. 1253 5.2.8. Zone-Reflexive Singular Assertions 1255 A zone may make a Singular Assertion about itself by using the string 1256 "@" as a subject name. This facility can be used for any object 1257 type, but is especially useful for self-signing root zones, and for a 1258 zone to make a subsequent key assertion about itself. If a Singular 1259 Assertion for an Object about a zone is available both in the zone 1260 itself and in the superordinate zone, the assertion in the 1261 superordinate zone will take precedence. 1263 5.3. Object Types and Encodings 1265 Each Object associated with a given subject name in a Singular 1266 Assertion (see Section 5.2.1) is represented as a CBOR array, where 1267 the first element is the type of the object, encoded as an integer in 1268 the following table: 1270 +------+--------------+------------------------------+--------------+ 1271 | Code | Name | Description | Reference | 1272 +------+--------------+------------------------------+--------------+ 1273 | 1 | name | name associated with subject | Section | 1274 | | | | 5.3.1 | 1275 | | | | | 1276 | 2 | ip6-addr | IPv6 address of subject | Section | 1277 | | | | 5.3.2 | 1278 | | | | | 1279 | 3 | ip4-addr | IPv4 address of subject | Section | 1280 | | | | 5.3.3 | 1281 | | | | | 1282 | 4 | redirection | name of zone authority | Section | 1283 | | | server | 5.3.4 | 1284 | | | | | 1285 | 5 | delegation | public key for zone | Section | 1286 | | | delgation | 5.3.5 | 1287 | | | | | 1288 | 6 | nameset | name set expression for zone | Section | 1289 | | | | 5.3.6 | 1290 | | | | | 1291 | 7 | cert-info | certificate information for | Section | 1292 | | | name | 5.3.7 | 1293 | | | | | 1294 | 8 | service-info | service information for | Section | 1295 | | | srvname | 5.3.8 | 1296 | | | | | 1297 | 9 | registrar | registrar information | Section | 1298 | | | | 5.3.9 | 1299 | | | | | 1300 | 10 | registrant | registrant information | Section | 1301 | | | | 5.3.10 | 1302 | | | | | 1303 | 11 | infrakey | public key for RAINS | Section | 1304 | | | infrastructure | 5.3.11 | 1305 | | | | | 1306 | 12 | extrakey | external public key for | Section | 1307 | | | subject | 5.3.12 | 1308 | | | | | 1309 | 13 | nextkey | next public key for subject | Section | 1310 | | | | 5.3.13 | 1311 +------+--------------+------------------------------+--------------+ 1313 Table 4: Object type codes 1315 Subsequent elements contain the object content, encoded as described 1316 in the respective subsection below. 1318 5.3.1. Name Alias 1320 A name (1) object contains a name associated with a name as an alias. 1321 It is represented as a three-element array. The second element is a 1322 fully-qualified name as a UTF-8 encoded string. The third type is an 1323 array of object type codes for which the alias is valid, with the 1324 same semantics as the query-types (9) key in queries (see 1325 Section 5.5). 1327 The name type is roughly equivalent to the DNS CNAME RRTYPE. 1329 5.3.2. IPv6 Address 1331 An ip6-addr (2) object contains an IPv6 address associated with a 1332 name. It is represented as a two element array. The second element 1333 is a byte array of length 16 containing an IPv6 address in network 1334 byte order. 1336 The ip6-addr type is roughly equivalent to the DNS AAAA RRTYPE. 1338 5.3.3. IPv4 Address 1340 An ip4-addr (3) object contains an IPv4 address associated with a 1341 name. It is represented as a two element array. The second element 1342 is a byte array of length 4 containing an IPv4 address in network 1343 byte order. 1345 The ip4-addr type is roughly equivalent to the DNS A RRTYPE. 1347 5.3.4. Redirection 1349 A redirection (4) object contains the fully-qualified name of a RAINS 1350 authority server for a named zone. It is represented as a two- 1351 element array. The second element is a fully-qualified name of an 1352 RAINS authority server as a UTF-8 encoded string. 1354 The redirection type is used to point to a "last-resort" server or 1355 server from which assertions about a zone can be retrieved; it 1356 therefore approximately replaces the DNS NS RRTYPE. 1358 5.3.5. Delegation 1360 A delegation (5) object contains a public key used to generate 1361 signatures on assertions in a named zone, and by which a delegation 1362 of a name within a zone to a subordinate zone may be verified. It is 1363 represented as an 4-element array. The second element is a signature 1364 algorithm identifier as in Section 5.7. The third element is a key 1365 phase as in Section 5.7. The fourth element is the public key, 1366 formatted as defined in Section 5.7 for the given algorithm 1367 identifier and RAINS delegation chain keyspace. 1369 Delegations approximately replace the DNS DNSKEY RRTYPE. 1371 5.3.6. Nameset 1373 A nameset (6) object contains an expression defining which names are 1374 allowed and which names are disallowed in a given zone. It is 1375 represented as a two- element array. The second element is a nameset 1376 expression to be applied to each name element within the zone without 1377 an intervening delegation. 1379 The nameset expression is represented as a UTF-8 string encoding a 1380 modified POSIX Extended Regular Expression format (see POSIX.2) to be 1381 applied to each element of a name within the zone. A name containing 1382 an element that does not match the valid nameset expression for a 1383 zone is not valid within the zone, and the nameset assertion can be 1384 used to prove nonexistence. 1386 The POSIX character classes :alnum:, :alpha:, :ascii:, :digit:, 1387 :lower:, and :upper: are available in these regular expressions, 1388 where: 1390 o :lower: matches all codepoints within the Unicode general category 1391 "Letter, lowercase" 1393 o :upper: matches all codepoints within the Unicode general category 1394 "Letter, uppercase" 1396 o :alpha: matches all codepoints within the Unicode general category 1397 "Letter". 1399 o :digit: matches all codepoints within the Unicode general category 1400 "Number, decimal digit" 1402 o :alnum: is the union of :alpha: and :digit: 1404 o :ascii: matches all codepoints in the range 0x20-0x7f 1406 In addition, each Unicode block is available as a character class, 1407 with the syntax :ublkXXXX: where XXXX is a 4 or 5 digit, zero- 1408 prefixed hex encoding of the first codepoint in the block. For 1409 example, the Cyrillic block is available as :ublk0400:. 1411 Unicode escapes are supported in these regular expressions; the 1412 sequence \uXXXX where XXXX is a 4 or 5 digit, possibly zero-prefixed 1413 hex encoding of the codepoint, is substituted with that codepoint. 1415 Set operations (intersection and subtraction) are available on 1416 character classes. Two character class or range expressions in a 1417 bracket expression joined by the sequence && are equivalent to the 1418 intersection of the two character classes or ranges. Two character 1419 class or range expressions in a bracket expression joined by the 1420 sequence - are equivalent to the subtraction of the second character 1421 class or range from the first. 1423 For example, the nameset expression: 1425 [[:ublk0400:]&&[:lower:][:digit:]]+ 1427 matches any name made up of one or more lowercase Cyrillic letters 1428 and digits. The same expression can be implemented with a range 1429 instead of a character class: 1431 [\u0400-\u04ff&&[:lower:][:digit:]]+ 1433 Nameset expression support is experimental and subject to (radical) 1434 change in future revisions of this specification. 1436 5.3.7. Certificate Information 1438 A cert-info (7) object contains an expression binding a certificate 1439 or certificate authority to a name, such that connections to the name 1440 must either use the bound certificate or a certificate signed by a 1441 bound authority. It is represented as an five-element array. 1443 The second element is the protocol family specifier, describing the 1444 cryptographic protocol used to connect, as defined in Table 5. The 1445 protocol family defines the format of certificate data to be hashed. 1446 The third element is the certificate usage specifier as in Table 6, 1447 describing the constraint imposed by the assertion. These are 1448 defined to be compatible with Certificate Usages in the TLSA RRTYPE 1449 for DANE [RFC6698]. The fourth element is the hash algorithm 1450 identifier, defining the hash algorithm used to generate the 1451 certificate data, as in Table 7. The fifth item is the data itself, 1452 whose format is defined by the protocol family and hash algorithm. 1454 +------+--------+---------------------------------+-----------------+ 1455 | Code | Name | Protocol family | Certificate | 1456 | | | | format | 1457 +------+--------+---------------------------------+-----------------+ 1458 | 0 | unspec | Unspecified | Unspecified | 1459 | | | | | 1460 | 1 | tls | Transport Layer Security (TLS) | [RFC5280] | 1461 | | | [RFC8446] | | 1462 +------+--------+---------------------------------+-----------------+ 1464 Table 5: Certificate information protocol families 1466 Protocol family 0 leaves the protocol family unspecified; client 1467 validation and usage of cert-info assertions, and the protocol used 1468 to connect, are up to the client, and no information is stored in 1469 RAINS. Protocol family 1 specifies Transport Layer Security version 1470 1.3 [RFC8446] or a subsequent version, secured with PKIX [RFC5280] 1471 certificates. 1473 +------+------+--------------------------+ 1474 | Code | Name | Certificate usage | 1475 +------+------+--------------------------+ 1476 | 2 | ta | Trust Anchor Certificate | 1477 | | | | 1478 | 3 | ee | End-Entity Certificate | 1479 +------+------+--------------------------+ 1481 Table 6: Certificate information usage values 1483 A trust anchor certificate constraint specifies a certificate that 1484 MUST appear as the trust anchor for the certificate presented by the 1485 subject of the Assertion on a connection attempt. An end-entity 1486 certificate constraint specifies a certificate that MUST be presented 1487 by the subject on a connection attempt. 1489 Certificate information is hashed using an appropriate hash function 1490 described in Section 5.4; hash functions are identified by a code as 1491 in Table 7. Code 0 is used to store full certificates in RAINS 1492 assertions, while other codes are used to store hashes for 1493 verification. 1495 For example, in a cert-info object with values [ 7, 1, 3, 3, (data) 1496 ], the data would be a 48 SHA-384 hash of the ASN.1 DER-encoded 1497 X.509v3 certificate (see Section 4.1 of [RFC5280]) to be presented by 1498 the endpoint on a connection attempt with TLS version 1.2 or later. 1500 The cert-info type replaces the TLSA DNS RRTYPE. 1502 5.3.8. Service Information 1504 A service-info (8) object gives information about a named service. 1505 Services are named as in [RFC2782]. It is represented as a four- 1506 element array. The second element is a fully-qualified name of a 1507 host providing the named service as a UTF-8 string. The third 1508 element is a transport port number as a positive integer in the range 1509 0-65535. The fourth element is a priority as a positive integer, 1510 with lower numbers having higher priority. 1512 The service-info type replaces the DNS SRV RRTYPE. 1514 5.3.9. Registrar Information 1516 A registrar (9) object gives the name and other identifying 1517 information of the registrar (the organization which caused the name 1518 to be added to the namespace) for organization-level names. It is 1519 represented as a two element array. The second element is a UTF-8 1520 string of maximum length 256 bytes containing identifying information 1521 chosen by the registrar according to the registry's policy. 1523 5.3.10. Registrant Information 1525 A registrant (10) object gives information about the registrant of an 1526 organization-level name. It is represented as a two element array. 1527 The second element is a UTF-8 string with a maximum length of 4096 1528 bytes containing this information, with a format chosen by the 1529 registrant according to the registry's policy. 1531 5.3.11. Infrastructure Key 1533 An infrakey (11) object contains a public key used to generate 1534 signatures on messages by a named RAINS server, by which a RAINS 1535 message signature may be verified by a receiver. It is identical in 1536 structure to a delegation object, as defined in Section 5.3.5. 1537 Infrakey signatures are especially useful for clients which delegate 1538 verification to their query servers to authenticate the messages sent 1539 by the query server. 1541 5.3.12. External Key 1543 An extrakey (12) object contains a public key used to generate 1544 signatures on assertions in a named zone outside of the normal 1545 delegation chain. It is represented as an 4-element array, where the 1546 second element is a signature algorithm identifier, and the third 1547 element is keyspace identifier, as in Section 5.7. The fourth 1548 element is the public key, as defined in Section 5.7 for the given 1549 algorithm identifier. An extrakey may be matched with a public key 1550 obtained through other means for additional authentication of an 1551 assertion. 1553 5.3.13. Next Delegation Public Key 1555 A nextkey (13) object contains the a public key that a zone owner 1556 would like its superordinate to delegate to in the future. It is 1557 represented as an 6-element array. The second element is a signature 1558 algorithm identifier as in Section 5.7. The third element is a key 1559 phase as in Section 5.7. The fourth element is the public key, as 1560 defined in Section 5.7 for the given algorithm identifier. The fifth 1561 element is the requested-valid-since time, and the sixth element is 1562 the requested-valid-until time, formatted as for signatures as in 1563 Section 5.7. See Section 7.6 for more. 1565 5.4. Hash Functions 1567 Hash algorithms are used in several places in the RAINS data model: 1569 o hashing certificate data in cert-info objects (see Section 5.3.7) 1571 o hashing assertions into Bloom filters and checking if a subject- 1572 object mapping within a zone for the given context and type is 1573 present in a Bloom filter (see Section 5.2.4) 1575 o hashing Assertion and Message data as part of generating a MAC 1576 (see Section 5.7) 1578 Hash functions are identified by a code given in Table 7. The 1579 Applicability column determines where in the RAINS Protocol a 1580 specific hash function might be used. Applicability "C" means the 1581 hash is valid for use in a certificate info object, "P" that it can 1582 be used for hashing assertions for P-shards, "S" that it can be used 1583 for hashing Assertions and Messages for signatures. 1585 +------+----------+-------------------+--------+---------------+ 1586 | Code | Name | Reference | Length | Applicability | 1587 +------+----------+-------------------+--------+---------------+ 1588 | 0 | nohash | (data not hashed) | var. | C | 1589 | | | | | | 1590 | 1 | sha-256 | [RFC6234] | 32 | CPS | 1591 | | | | | | 1592 | 2 | sha-512 | [RFC6234] | 64 | CS | 1593 | | | | | | 1594 | 3 | sha-384 | [RFC6234] | 48 | CS | 1595 | | | | | | 1596 | 4 | shake256 | [RFC8419] | 32 | PS | 1597 | | | | | | 1598 | 5 | fnv-64 | [FNV] | 8 | P | 1599 | | | | | | 1600 | 6 | fnv-128 | [FNV] | 16 | P | 1601 +------+----------+-------------------+--------+---------------+ 1603 Table 7: Hash algorithms 1605 5.5. Queries 1607 Information about requests for information about names is carried in 1608 Queries. A Query specifies the name and object types about which 1609 information is requested, information about how long the querier is 1610 willing to wait for an answer, and additional options indicating the 1611 querier's preferences about how the query should be handled. 1613 In contrast to Singular Assertions, the subject in a Query is given 1614 as a fully-qualified name - the subject name concatenated to the zone 1615 name with a '.', since a querier may not know the zone name 1616 associated with a fully-qualified name. 1618 There are two kinds of queries supported by the RAINS data model: 1620 o Query (or Normal Query): a request for information about one or 1621 several types of a given subject, about which the querier 1622 expresses no prior information. 1624 o Confirmation Query: a request for information about one or several 1625 types of a given subject, for which the querier already has a 1626 valid cached Assertion, but for which the querier would like a new 1627 Assertion if available. Confirmation queries are covered in 1628 Section 5.5.2. 1630 Both queries are carried in a Query message section. Each Query 1631 contained in a Message represents a separate Query. 1633 A Query body is represented as a CBOR map. Queries MUST contain the 1634 query-name (8), context (6), query-types (10), and query-expires (12) 1635 keys. Queries MAY contain the query-opts (13), query-keyphases (17) 1636 keys, and/or current-time (14) keys. 1638 The value of the query-name (8) key is a UTF-8 encoded string 1639 containing the name for which the query is issued and MUST end with a 1640 '.' (the root zone). 1642 The value of the context (6) key is a UTF-8 encoded string containing 1643 the name of the context to which a query pertains. A zero-length 1644 string indicates that assertions will be accepted in any context. 1646 The value of the query-types (10) key is an array of integers 1647 encoding the type(s) of Objects (as in Section 5.3) acceptable in 1648 answers to the query. All values in the query-type array are treated 1649 at equal priority: for example, [2,3] means the querier is equally 1650 interested in both IPv4 and IPv6 addresses for the query-name. An 1651 empty query-types array indicates that objects of any type are 1652 acceptable in answers to the query. 1654 The value of the query-expires (12) key is a CBOR integer epoch 1655 timestamp identified with tag value 1 and encoded as in section 2.4.1 1656 of [RFC7049]. After the query-expires time, the query will have been 1657 considered not answered by the original issuer and can be ignored. 1659 The value of the query-keyphases (17) key, if present, is an array of 1660 integers representing all key phases (see Section 5.7) desired in 1661 delegation and nextkey answers to queries (see Section 5.3.5 and 1662 Section 5.3.13). The value of the query-keyphases key is ignored for 1663 all Queries where query-types does not include delegation or nextkey. 1664 A query for a delegation or nextkey object that does not contain a 1665 query-keyphases key SHOULD return information for all available 1666 keyphases. 1668 The value of the query-opts (13) key, if present, is an array of 1669 integers in priority order of the querier's preferences in tradeoffs 1670 in answering the query. See Section 5.5.1. 1672 The value of the current-time (14) key, if present, is the timestamp 1673 of the latest information available at the querier for the queried 1674 subject and object types. See Section 5.5.2 for details of how 1675 confirmation queries work. 1677 5.5.1. Query Options 1679 RAINS supports a set of query options to allow a querier to express 1680 preferences. Query options are advisory. 1682 +------+------------------------------------------------------------+ 1683 | Code | Description | 1684 +------+------------------------------------------------------------+ 1685 | 1 | Minimize end-to-end latency | 1686 | | | 1687 | 2 | Minimize last-hop answer size (bandwidth) | 1688 | | | 1689 | 3 | Minimize information leakage beyond first hop | 1690 | | | 1691 | 4 | No information leakage beyond first hop: cached answers | 1692 | | only | 1693 | | | 1694 | 5 | Expired assertions are acceptable | 1695 | | | 1696 | 6 | Enable query token tracing | 1697 | | | 1698 | 7 | Disable verification delegation (client protocol only) | 1699 | | | 1700 | 8 | Suppress proactive caching of future assertions | 1701 | | | 1702 | 9 | Maximize freshness of result | 1703 +------+------------------------------------------------------------+ 1705 Table 8: Query Option Codes 1707 Options 1-5 and 9 specify performance/privacy tradeoffs. Each server 1708 is free to determine how to minimize each performance metric 1709 requested; however, servers MUST NOT generate queries to other 1710 servers if "no information leakage" is specified, and servers MUST 1711 NOT return expired Assertions unless "expired assertions acceptable" 1712 is specified. 1714 Option 6 specifies that the token on the message containing the query 1715 (see Section 5.8) should be used on all queries resulting from a 1716 given query, allowing traceability through an entire RAINS 1717 infrastructure. The resulting queries SHOULD also carry Option 6. 1718 When Option 6 is not present, queries sent by a server in response to 1719 an incoming query must use different tokens. 1721 By default, a client service will perform verification on a negative 1722 query response and return a 404 No Assertion Exists Notification for 1723 queries with a valid and verified proof of nonexistence, within a 1724 Message signed by the query service's infrakey. Option 7 disables 1725 this behavior, and causes the query service to return the Shard, 1726 P-Shard or Zone for verification by the client. It is intended to be 1727 used with untrusted query services. 1729 Option 8 specifies that a querier's interest in a query is strictly 1730 ephemeral, and that future assertions related to this query SHOULD 1731 NOT be proactively pushed to the querier. 1733 Option 9 specifies that the querier would prefer a fresh result to 1734 one from the server's cache. If the server is not running an 1735 authority service for the queried subject, it can honor this request 1736 by issuing a query toward the authority. As this could be used for 1737 denial-of-service-attacks, a server honoring Option 9 SHOULD limit 1738 the rate of "freshness" queries it issues. 1740 5.5.2. Confirmation Queries 1742 A Query containing a current-time key is a Confirmation Query, used 1743 by a server to refresh a cached query result. The querier passes the 1744 timestamp of the most recent result it has cached, taken from the 1745 most recent start time of the validity of the signature(s) on the 1746 Assertion(s) that may answer it. If the answer to a Confirmation 1747 Query is not newer than the given timestamp, the server SHOULD answer 1748 with a Notification of type 304 (see Section 5.6). Otherwise, the 1749 most recent Assertion answering the query is returned. 1751 The value of the current-time key is represented as a CBOR integer 1752 epoch timestamp identified with tag value 1 and encoded as in section 1753 2.4.1 of [RFC7049]. 1755 5.5.3. Context in Queries 1757 Context is used in Queries as it is in Assertions (see 1758 Section 5.2.7). The Context section of a query contains the context 1759 of desired Assertions; a special "any" context (represented by the 1760 empty string) indicates that Assertions in any context will be 1761 accepted. Assertion contexts in an answer to a Query that is not 1762 about the "any" context MUST match the context in the Query. 1764 Query contexts can also be used to provide additional information to 1765 RAINS servers about the query. For example, context can provide a 1766 method for explicit selection of a CDN server not based on either the 1767 client's or the resolver's address (see [RFC7871]). Here, the CDN 1768 creates a context for each of its content zones, and an external 1769 service selects appropriate contexts for the client based not just on 1770 client source address but passive and active measurement of 1771 performance. Queries for names at which content resides can then be 1772 made within these contexts, with the priority order of the contexts 1773 reflecting the goodness of the zone for the client. Here, a context 1774 might be 'zrh.cx-cdn-zones.some-cdn.com.' for names of servers 1775 hosting content in a CDN's Zurich data center. A client could 1776 represent its desire to find content nearby by making queries in the 1777 zrh.cx-, fra.cx- (Frankfurt), and ams.cx- (Amsterdam) contexts of the 1778 'cdn-zones.some-cdn.com.' Authority. In all cases, the Assertions 1779 themselves will be signed by the Authority for 'cdn-zones.some- 1780 cdn.com.', accurately representing that it is the CDN, not the owner 1781 of the related name in the global context, that is making the 1782 Assertion. 1784 As with assertion contexts, developing conventions for query contexts 1785 for different situations will require implementation and deployment 1786 experience, and is a subject for future work. 1788 5.6. Notifications 1790 Notifications contain information about the operation of the RAINS 1791 protocol itself. A Notification body is represented as a CBOR map, 1792 which MUST contain the token (2) and note-type (21) keys, and MAY 1793 contain the note-data (22) key. 1795 The value of the token (2) key is a 16-byte array, which MUST contain 1796 the token of the Message to which the Notification is a response. 1797 See Section 5.8. 1799 The value of the note-type key is encoded as an integer as in the 1800 Table 9. 1802 +------+-----------------------------------+------------------------+ 1803 | Code | Description | See Also | 1804 +------+-----------------------------------+------------------------+ 1805 | 100 | Connection heartbeat | Section 6.1.2 | 1806 | | | | 1807 | 304 | Confirmation query has latest | Section 5.5.2 | 1808 | | answer | | 1809 | | | | 1810 | 399 | Send full capabilities | Section 5.9 | 1811 | | | | 1812 | 400 | Bad message received | | 1813 | | | | 1814 | 403 | Inconsistent message received | Section 6.5 | 1815 | | | | 1816 | 404 | No assertion exists | Section 6.3 | 1817 | | | | 1818 | 406 | Message not acceptable for | Section 6.3 Section | 1819 | | service | 6.4 | 1820 | | | | 1821 | 413 | Message too large | Section 6.1.1 | 1822 | | | | 1823 | 500 | Unspecified server error | | 1824 | | | | 1825 | 504 | No assertion available | Section 6.3 | 1826 +------+-----------------------------------+------------------------+ 1828 Table 9: Notification Type Codes 1830 Note that the status codes are chosen to be mnemonically similar to 1831 status codes for HTTP [RFC7231]. 1833 The value of the note-data (22) key, if present, is a UTF-8 encoded 1834 string with additional information about the notification, intended 1835 to be displayed to an administrator to help debug the issue 1836 identified by the Notification. 1838 Notification codes 400 and 500 signal error conditions. 400 is a 1839 general message noting that a client or server could not parse a 1840 message, and 500 notes that the server failed to process a message 1841 due to some internal error. Sending these notifications is optional, 1842 according to server policy and configuration. 1844 5.7. Signatures 1846 RAINS supports multiple signature algorithms and hash functions for 1847 signing Assertions for cryptographic algorithm agility [RFC7696]. A 1848 RAINS signature algorithm identifier specifies the signature 1849 algorithm; a hash function for generating the HMAC and the format of 1850 the encodings of the signature values in Assertions and Messages, as 1851 well as of public key values in delegation objects. 1853 RAINS signatures have five common elements: the algorithm identifier, 1854 a keyspace identifier, a key phase, a valid-since timestamp, and a 1855 valid-until timestamp. Signatures are represented as an array of 1856 these five values followed by additional elements containing the 1857 signature data itself, according to the algorithm identifier. 1859 The following algorithms are supported: 1861 +--------+------------+-----------+-------------------+ 1862 | Alg ID | Signatures | Hash/HMAC | Format | 1863 +--------+------------+-----------+-------------------+ 1864 | 1 | ed25519 | sha-512 | See Section 5.7.2 | 1865 | | | | | 1866 | 2 | ed448 | shake256 | See Section 5.7.2 | 1867 +--------+------------+-----------+-------------------+ 1869 Table 10: Defined signature algorithms 1871 As noted in Section 5.7.2, support for Algorithm 1, ed25519, is 1872 REQUIRED; other algorithms are OPTIONAL. 1874 The keyspace identifier associates the signature with a method for 1875 verifying signatures. This facility is used to support signatures on 1876 assertions from external sources (the extrakey object type). At 1877 present, one keyspace identifier is defined, and support for it is 1878 REQUIRED. 1880 +-------------+-------+-----------------------------------------+ 1881 | Keyspace ID | Name | Signature Verification Algorithm | 1882 +-------------+-------+-----------------------------------------+ 1883 | 0 | rains | RAINS delegation chain; see Section 5.7 | 1884 +-------------+-------+-----------------------------------------+ 1886 Within the RAINS delegation chain keyspace, the key phase is an 1887 unbounded, unsigned integer matching a signature's key phase to the 1888 delegation key phase. Multiple keys may be valid for a delegation at 1889 a given point in time, in order to support seamless rollover of keys, 1890 but only one per key phase and algorithm may be valid at once. The 1891 third element of delegation objects and signatures is the key phase. 1893 Valid-since and valid-until timestamps are represented as CBOR 1894 integers counting seconds since the UNIX epoch UTC, identified with 1895 tag value 1 and encoded as in section 2.4.1 of [RFC7049]. 1897 A signature in RAINS is generated over a byte stream representing the 1898 data element to be signed. The signing process is defined as 1899 follows: 1901 o Render the element to be signed into a canonical byte stream as 1902 specified in Section 5.7.1. 1904 o Generate a signature on the resulting byte stream according to the 1905 algorithm selected. 1907 o Add the full signature to the signatures array at the appropriate 1908 point in the element. 1910 To verify a signature, generate the byte stream as for signing, then 1911 verify the signature according to the algorithm selected. 1913 5.7.1. Canonicalization 1915 The byte stream representing a data element over which signatures are 1916 generated and verified is a canonicalized CBOR object representing 1917 the data element. 1919 Signatures may be attached to any form of Assertion, as well as to 1920 Messages as a whole. 1922 First, to canonicalize signature metadata to allow it to be protected 1923 by the signature, regardless of the type of data element: 1925 o recursively strip all signatures from the content of the data 1926 element. 1928 o add a single-element signatures array at the level in the data 1929 structure where the generated signature will be attached, 1930 containing the information common to all signatures: the algorithm 1931 identifier, a keyspace identifier, a key phase, a valid-since 1932 timestamp, and a valid-until timestamp, but omitting any signature 1933 content. 1935 Then follow the canonicalization steps below appropriate for the type 1936 of data element to be signed: 1938 To generate a canonicalized Singular Assertion: 1940 o sort the objects array by ascending order of object type 1941 (Table 4), then by ascending numeric or lexicographic order of 1942 each subsequent array element in the object(s)' representation. 1944 o sort the CBOR map by ascending order of its keys (Table 1). 1946 To generate a canonicalized Shard: 1948 o sort the objects array in each Singular Assertion contained in the 1949 assertions array as, above. 1951 o sort the assertions array by lexicographic order of the serialized 1952 canonicalized byte string representing the assertion. Note that 1953 this will cause the assertions array to be sorted in lexicographic 1954 order of subject name, as well. 1956 o sort the CBOR map by ascending order of its keys (Table 1). 1958 To generate a canonicalized Zone: 1960 o sort the objects array in each Singular Assertion contained in the 1961 assertions array as, above. 1963 o sort the assertions array by lexicographic order of the serialized 1964 canonicalized byte string representing the assertion. Note that 1965 this will cause the assertions array to be sorted in lexicographic 1966 order of subject name, as well. 1968 o sort the CBOR map by ascending order of its keys (Table 1). 1970 To generate a canonicalized P-Shard: 1972 o sort the CBOR map by ascending order of its keys (Table 1). 1974 To generate a canonicalized Message: 1976 o preserve the order of the Message Sections within the Message. 1978 o canonicalize each Section as appropriate by following the 1979 canonicalization steps for the appropriate Section type, above. 1981 It is RECOMMENDED that RAINS implementations generate and send only 1982 Messages whose contents are sorted according to the canonicalization 1983 rules in this section, since the sorting operation is in any case 1984 necessary to generate and verify signatures. However, an 1985 implementation MUST NOT assume that a Message it receives is sorted 1986 according to these rules. 1988 5.7.2. EdDSA signature and public key format 1990 EdDSA public keys consist of a single value, a 32-byte bit string 1991 generated as in Section 5.1.5 of [RFC8032] for Ed25519, and a 57-byte 1992 bit string generated as in Section 5.2.5 of [RFC8032] for Ed448. The 1993 fourth element in a RAINS delegation object is this bit string 1994 encoded as a CBOR byte array. RAINS delegation objects for Ed25519 1995 keys with value k are therefore represented by the array [5, 1, 1996 phase, k]; and for Ed448 keys as [5, 2, phase, k]. 1998 Ed25519 and Ed448 signatures are are a combination of two non- 1999 negative integers, called "R" and "S" in sections 5.1.6 and 5.2.6, 2000 respectively, of [RFC8032]. An Ed25519 signature is represented as a 2001 64-byte array containing the concatenation of R and S, and an Ed448 2002 signature is represented as a 114-byte array containing the 2003 concatenation of R and S. RAINS signatures using Ed25519 are 2004 therefore the array [1, 0, phase, valid-since, valid-until, R|S]; 2005 using Ed448 the array [2, 0, phase, valid-since, valid-until, R|S]. 2007 Ed25519 keys are generated as in Section 5.1.5 of [RFC8032], and 2008 Ed448 keys as in Section 5.2.5 of [RFC8032]. Ed25519 signatures are 2009 generated from a normalized serialized CBOR object as in 2010 Section 5.1.6 of [RFC8032], and Ed448 signatures as in section 5.2.6 2011 of [RFC8032]. 2013 RAINS Server and Client implementations MUST support Ed25519 2014 signatures for delegation. 2016 5.8. Tokens 2018 Messages and Notifications contain an opaque token (2) key, whose 2019 content is a 16-byte array, and is used to link Messages to the 2020 Queries they respond to, and Notifications to the Messages they 2021 respond to. Tokens MUST be treated as opaque values by RAINS 2022 servers. 2024 A Message sent in response to a Query (normal and update) MUST 2025 contain the token of the Message containing the Query. Otherwise, 2026 the Message MUST contain a token selected by the server originating 2027 it, so that future Notifications can be linked to the Message causing 2028 it. Likewise, a Notification sent in response to a Message MUST 2029 contain the token from the Message causing it (where the new Message 2030 contains a fresh token selected by the server). This allows sending 2031 multiple Notifications within one Message and the receiving server to 2032 respond to a Message containing Notifications (e.g. when it is 2033 malformed). 2035 Since tokens are used to link Queries to replies, and to link 2036 Notifications to Messages, regardless of the sender or recipient of a 2037 Message, they MUST be chosen by servers to be hard to guess; e.g. 2038 generated by a cryptographic random number generator. 2040 When a server creates a new Query to forward to another server in 2041 response to a Query it received, it MUST NOT use the same token on 2042 the delegated query as on the received query, unless option 6 Enable 2043 Tracing is present in the received query, in which case it MUST use 2044 the same token. 2046 5.9. Capabilities 2048 The capabilities (1) key in a RAINS message allows the sender of that 2049 message to communicate its capabilities to its peer. Capabilities 2050 MUST be sent on the first message sent from one peer to another. 2052 A peer's capabilities can be represented in one of two ways: 2054 o an array of uniform resource names specifying capabilities 2055 supported by the sending server, taken from the table below, with 2056 each name encoded as a UTF-8 string. 2058 o a SHA-256 hash of the CBOR byte stream derived from normalizing 2059 such an array by sorting it in lexicographically increasing order, 2060 then serializing it. 2062 If a peer receives a message from a counterpart for which it does not 2063 have the hash of the capabilities, it can ask for the next message to 2064 contain a list of these capabilities by sending a message containing 2065 notification 399. 2067 This mechanism is inspired by [XEP0115], and is intended to be used 2068 to reduce the overhead in exposing common sets of capabilities. Each 2069 RAINS server can cache a set of recently-seen or common hashes, 2071 The following URNs are presently defined; other URNs will specify 2072 future optional features, support for alternate transport protocols 2073 and new signature algorithms, and so on. 2075 +--------------------+----------------------------------------------+ 2076 | URN | Meaning | 2077 +--------------------+----------------------------------------------+ 2078 | urn:x-rains:tlssrv | Listens for TLS/TCP connections (see Section | 2079 | | 6.1.1 | 2080 +--------------------+----------------------------------------------+ 2082 A RAINS server MUST NOT assume that a peer server supports a given 2083 capability unless it has received a message containing that 2084 capability from that server. An exception are the capabilities 2085 indicating that a server listens for connections using a given 2086 transport protocol; servers and clients can also learn this 2087 information from RAINS itself (given redirection and service-info 2088 Assertions for a named zone) or from external configurations. 2090 6. RAINS Protocol 2092 RAINS is a message-exchange protocol based around a CBOR data model. 2093 Since CBOR is self-framing - a CBOR parser can determine when a CBOR 2094 object is complete at the point at which it has read its final byte - 2095 RAINS messages requires no external framing, and can be carried on a 2096 variety of transport protocols. 2098 These transport bindings serve to transfer Messages containing 2099 Queries toward servers that can answer them, and to transfer 2100 Assertions toward clients that have indicated an interest in them. 2101 The interpretation and action implied by the arrival of a RAINS 2102 Message at a peer is not affected by the transport used to send it. 2104 6.1. Transport Bindings 2106 This document defines one transport binding for RAINS: TLS-over-TCP 2107 in Section 6.1.1. Each transport binding offers a different set of 2108 tradeoffs. Carrying RAINS Messages over persistent TLS 1.3 (or 2109 later) connections [RFC8446] over TCP [RFC0793] protects query 2110 confidentiality and integrity while supporting implementation over a 2111 ubiquitously-available and well-understood security and transport 2112 layer. 2114 6.1.1. TLS over TCP 2116 RAINS servers listen on port 55553 by default. Note that no effort 2117 has yet been made to assign this port at IANA; should RAINS be 2118 standardized, another port may be chosen. Servers may listen on 2119 other TCP ports subject to local configuration. Methods for 2120 discovering servers and configuring clients MUST allow for the 2121 specification of an alternate port. Servers providing authority 2122 service should use service information records (Section 5.3.8) to 2123 specify a port on a service name specified by redirection object(s) 2124 for the zone; see Section 7.2. 2126 RAINS servers should strive to keep connections open to peer servers, 2127 unless it is clear that no future messages will be exchanged with 2128 those peers, or in the face of resource limitations at either peer. 2129 If a RAINS server needs to send a message to another RAINS server to 2130 which it does not have an open connection, it attempts to open a 2131 connection with that server. 2133 A RAINS client configured to use one or more servers for query 2134 service should strive to keep connections open to those servers. 2136 RAINS servers MUST accept Messages over TCP up to 65536 bytes in 2137 length, but MAY accept messages of greater length, subject to 2138 resource limitations of the server. A server with resource 2139 limitations MUST respond to a message rejected due to length 2140 restrictions with a notification of type 413 (Message Too Large). A 2141 server that receives a type 413 notification must note that the peer 2142 sending the message only accepts messages smaller than the largest 2143 message it's successfully sent that peer, or cap messages to that 2144 peer to 65536 bytes in length. 2146 Since a singular assertion with a single Ed25519 signature requires 2147 on the order of 180 bytes, it is clear that many full zones won't fit 2148 into a single minimum maximum-size message. Authorities are 2149 therefore encouraged to publish zones grouped into shards that will 2150 fit into 65536-byte messages, to allow servers to reply using these 2151 shards when full-zone transfers are not possible due to message size 2152 limitations. 2154 6.1.2. Heartbeat Messages 2156 TCP connections between RAINS clients and servers may be associated 2157 with in-network state (such as firewall pinholes and/or network 2158 address translation cache entries) with relatively short idle 2159 timeouts. RAINS provides a simple heartbeat mechanism to refresh 2160 this state for long-running connections. 2162 A RAINS peer may send its peer a 100 Connection Heartbeat 2163 notification at any time. This message is ignored by the receiving 2164 peer. 2166 6.2. Protocol Dynamics 2168 This section illustrates how the RAINS protocol works with one 2169 possible set of rules for handling incoming messages and sending 2170 outgoing messages as a RAINS server; however, the actions here and 2171 the sequence in which they are applied are meant only as one 2172 possibility for implementors, and are not normative. 2174 6.2.1. Message Processing 2176 Once a transport connection is established, any server may validly 2177 send a message with any content to any other server. A client may 2178 send messages containing queries to servers, and a server may sent 2179 messages containing anything other than queries to clients. 2181 Upon receipt of a message, a server or client attempts to parse it. 2182 If the server or client cannot parse the message at all, it returns a 2183 400 Bad Message notification to the peer. This notification may have 2184 a null token if the token cannot be retrieved from the message. 2186 If the server or client can parse the message, it: 2188 o notes the token on the message to send on any message generated in 2189 reply to the message. 2191 o processes any capabilities present, replacing the set of 2192 capabilities known for the peer with the set present in the 2193 message. If the present capabilities are represented by a hash 2194 that the server does not have in its cache, it prepares a 2195 notification of type 399 ("Capability hash not understood") to 2196 send to its peer. 2198 o splits the contents into its constituent message sections, and 2199 verifies that each is acceptable. Specifically, queries are not 2200 accepted by clients (see Section 6.3), and 404 No Assertion Exists 2201 notifications are not accepted by servers. If a message contains 2202 an unacceptable section, the server or client returns a 406 2203 Message Not Acceptable for Service notification to its peer, and 2204 ceases processing of the message. 2206 It then processes each sections acoording to the rules below. 2208 On receipt of an Assertion (Singular Assertion, Shard, P-Shard, or 2209 Zone) section, a server: 2211 o verifies its consistency (see Section 6.5). If the section is not 2212 consistent, it prepares to send a notification of type 403 2213 Inconsistent Message to the peer, and discards the section. 2214 Otherwise, it: 2216 o determines whether it answers an outstanding query; if so, it 2217 prepares to forward the section to the server that issued the 2218 query. 2220 o determines whether it is likely to answer a future query, 2221 according to its configuration, policy, and query history; if so, 2222 it caches the section. 2224 On receipt of an Assertion (Singular Assertion, Shard, P-Shard, or 2225 Zone) section, a client: 2227 o determines whether it answers an outstanding query; if so, it 2228 considers the query answered. It then: 2230 o determines whether it is likely to answer a future query, 2231 according to its configuration, policy, and query history; if so, 2232 it caches the section. 2234 On receipt of a query, a server: 2236 1. determines whether it has expired by checking the query-expires 2237 value. If so, it drops the query silently. If not, it 2239 2. determines whether it has at least one stored assertion 2240 containing a positive answer to the query. If so, it checks to 2241 see if the assertion is newer than the current-time value in the 2242 query, if present. If the assertion is not newer, it prepares to 2243 send a notification of type 304 ("Querier Has Latest Answer") to 2244 the peer. Otherwise, it prepares a message containing the stored 2245 assertion(s) positively answering the query. If no positive 2246 assertion is available, it 2248 3. checks to see whether it has at least one stored proof of 2249 nonexistence (shard or p-shard) for the query. If so, it 2250 prepares a message containing the negative proof to the peer. It 2251 prefers P-Shards to Shards for reasons of efficiency, but must 2252 verify that any P-shard does indeed function as a negative proof 2253 before sending it. 2255 4. determines whether it has other non-authoritative servers it can 2256 forward the query to, according to its configuration and policy, 2257 and in compliance with any query options (see Section 5.5.1). If 2258 so, it prepares to forward the query to those servers, noting the 2259 reply for the received query depends on the replies for the 2260 forwarded query. If not, it: 2262 5. determines the responsible authority servers for the zone 2263 containing the query name in the query for the context requested, 2264 and forwards the query to those authority servers, noting the 2265 reply for the received query depends on the reply for the 2266 forwarded query. 2268 Query options (see Section 5.5.1) change this handling. If query 2269 option 4 ("cached answers only") is set, steps 4 and 5 above are 2270 skipped, and the server returns a 504 ("No Assertion Available") 2271 notification instead. If query option 9 ("Maximize Freshness") is 2272 set, the server might forward a query even if it has a cached answer. 2274 If query delegation fails to return an answer within the maximum of 2275 the valid-until time in the received query and a configured maximum 2276 timeout for a delegated query, the server prepares to send a 504 No 2277 assertion available response to the peer from which it received the 2278 query. 2280 When a server creates a new query to forward to another server in 2281 response to a query it received, it does not use the same token on 2282 the delegated query as on the received query, unless option 6 2283 ("Enable Tracing") is present in the received query, in which case it 2284 does use the same token. The Enable Tracing option is designed to 2285 allow debugging of query processing across multiple servers. 2287 When a server creates a new query to forward to another server in 2288 response to a query it received, and the received query contains a 2289 query-expires time, the delegated query MUST NOT have a query-expires 2290 time after that in the received query. If the received query 2291 contains no query-expires time, the delegated query MAY contain a 2292 query- expires time of the server's choosing, according to its 2293 configuration. 2295 On receipt of a notification, a server's behavior depends on the 2296 notification type: 2298 o For type 100 "Connection Heartbeat", the server does nothing: 2299 these null messages are used to keep long-lived connections open 2300 in the presence of network behaviors that may drop state for idle 2301 connections. 2303 o For type 399 "Capability hash not understood", the server prepares 2304 to send a full capabilities list on the next message it sends to 2305 the peer. 2307 o For type 504 "No assertion available", the server checks the token 2308 on the message, and prepares to forward the assertion to the 2309 associated query. 2311 o For type 413 "Message too large" the server notes that large 2312 messages may not be sent to a peer and tries again, or logs the 2313 error along with the note-data content. 2315 o For type 400 "Bad message", type 403 "Inconsistent message", type 2316 406 "not supported for service", or type 500 "Server error", the 2317 server logs the error along with the note-data content, as these 2318 notifications generally represent implementation or configuration 2319 error conditions which will require human intervention to 2320 mitigate. 2322 On receipt of a notification, a client's behavior depends on the 2323 notification type: 2325 o For type 100 "Connection Heartbeat", the client does nothing, as 2326 above. 2328 o For type 304 "Querier has newest assertion", the client notes that 2329 its cache is up-to-date for the given query. 2331 o For type 399 "Capability hash not understood", the client prepares 2332 to send a full capabilities list on the next message it sends to 2333 the peer. 2335 o For type 404 "No assertion exists", the client takes the query to 2336 be unanswerable. It may reissue the query with query option 7 to 2337 do the verification of nonexistence again, if the server from 2338 which it received the notification is untrusted. 2340 o For type 413 "Message too large" the client notes that large 2341 messages may not be sent to a peer and tries again, or logs the 2342 error along with the note-data content. 2344 o For type 400 "Bad message", type 403 "Inconsistent message", type 2345 406 "not acceptable for service", of type 500 "Server error", the 2346 client logs the error along with the note-data content, as these 2347 notifications generally represent implementation or configuration 2348 error conditions which will require human intervention to 2349 mitigate. 2351 The first message a server or client sends to a peer after a new 2352 connection is established SHOULD contain a capabilities section, if 2353 the server or client supports any optional capabilities. See 2354 Section 5.9. 2356 If the server is configured to keep long-running connections open, 2357 due to the presence of network behaviors that may drop state for idle 2358 connections, it sends a message containing a type 100 Connection 2359 Heartbeat notification after a configured idle time without any 2360 messages containing other content being sent. 2362 6.2.2. Message Transmission 2364 As noted in Section 6.2.1 many messages are sent in reply to messages 2365 received from peers. Servers may also originate messages on their 2366 own, based on their configuration and policy: 2368 o Proactive queries to retrieve assertions, shards, and zones for 2369 which all signatures have expired or will soon expire, for cache 2370 management purposes. 2372 o Proactive push of assertions, shards, and zones to other servers, 2373 based on query history or other information indicating those 2374 servers may query for the assertions they contain. 2376 6.3. Client Protocol 2378 The protocol used by clients to issue queries to and receive 2379 responses from a query service is a subset of the full RAINS 2380 protocol, with the following differences: 2382 o Clients only process assertion, shard, zone, and notification 2383 sections; sending a query to a client results in a 406 2384 Unacceptable notification. 2386 o Clients never listen for connections via TCP; a client must 2387 initiate and maintain a transport session to the query server(s) 2388 it uses for name resolution. 2390 o Servers only process query and notification sections when 2391 connected to clients; a client sending assertions to a server 2392 results in a 406 Unacceptable notification. 2394 Since signature verification is resource-intensive, clients delegate 2395 signature verification to query servers by default. The query server 2396 signs the message containing results for a query using its own key 2397 (published as an infrakey object associated with the query server's 2398 name), and a validity time corresponding to the signature it verified 2399 with the longest lifetime, stripping other signatures from the reply. 2400 This behavior can be disabled by a client by specifying query option 2401 7, allowing the client to do its own verification. 2403 6.4. Publication Protocol 2405 The protocol used by authorities to publish assertions to an 2406 authority service is a subset of the full RAINS protocol, with the 2407 following differences: 2409 o Servers only process assertion, shard, zone, and notification 2410 sections when connected to publishers; sending a query to a server 2411 via the publication procotol results in a 406 Unacceptable 2412 notification. Servers only process notifications for capability 2413 negotiation purposes (see Section 5.9). 2415 o Publishers only process notification sections; sending a query or 2416 assertion to a publisher results in a 406 Unacceptable 2417 notification. 2419 6.5. Enforcing Assertion Consistency 2421 The data model used by the RAINS protocol allows inconsistent 2422 information to be asserted, all resulting from misconfigured or 2423 misbehaving authority servers. The following types of inconsistency 2424 are possible: 2426 o A Zone omits an Assertion which has the same validity start time 2427 as said Assertion. 2429 o A Shard omits an Assertion within its range which has the same 2430 validity start time as said Assertion. 2432 o A P-Shard with a given validity start time proves nonexistence of 2433 an Assertion with the same validity start time. 2435 o An Assertion prohibited by its Aone's nameset has the same 2436 validity start time as the prohibiting nameset Assertion. 2438 o A zone contains a valid reflexive assertion of a given object type 2439 with the same validity start time as a valid assertion of the same 2440 type for the same name within a supordinate zone, but with a 2441 different object value. 2443 o Delegations to more than one key are simultaneously valid for a 2444 given context, zone, signature algorithm, and key phase. 2446 RAINS relies on runtime consistency checking to mitigate 2447 inconsistency: each server receiving an assertion, shard, or zone 2448 SHOULD, subject to resource constraints, ensure that it is consistent 2449 with other information it has, and if not, discard all inconsistent 2450 assertions, shards, and zones in its cache, log the error, and send a 2451 403 Inconsistent Message to the source of the message. 2453 For RAINS to work in a highly dynamic environment, some time-bounded 2454 inconsistencies are allowed to occur. On the one hand, the authority 2455 wants to prove nonexistence of a name for a duration of time to make 2456 caching possible to reduce query latency and reduce load on its 2457 naming servers. On the other hand, the authority would like the 2458 flexibility to issue new assertions about previously nonexistent 2459 names without waiting for a previous negative proof to expire. 2460 Therefore, the defintions of inconsistency above are strictly limited 2461 to identical (and therefore non-orderable) validity start times. 2463 7. Operational Considerations 2465 The following subsections discuss issues that must be considered in 2466 any deployment of RAINS at scale. 2468 7.1. Discovering RAINS servers 2470 A client that will not do its own verification must be able to 2471 discover the query server(s) it should trust for resolution. There 2472 are three broad approaches to this discovery process: (1) static 2473 client configuration; (2) server configuration as part of dynamic 2474 host interface configuration, such as DHCP or provisioning domains; 2475 (3) discovery of a RAINS server as an optional service, for example 2476 using mDNS. Integration with any of these approaches is 2478 In any case, clients MUST provide a configuration interface to allow 2479 a user to specify (by address or name) and/or constrain (by 2480 certificate property) a preferred/trusted query server. This would 2481 allow client on an untrusted network to use an untrusted locally- 2482 available query server to discover a preferred query server (doing 2483 key verification on its own for bootstrapping), before connecting to 2484 that query server for normal name resolution. 2486 Servers providing query and intermediate service also discover other 2487 intermediate servers through static configuration, or through an 2488 external, unspecified discovery protocol. 2490 Servers providing query and intermediate service discover servers 2491 providing authority service as in Section 7.2, below. 2493 7.2. Bootstrapping RAINS Services 2495 At startup, a server performing recursive lookup MUST have access to 2496 at least one of each of these three assertion types: a self-signed 2497 delegation assertion of the root zone, a redirection assertion 2498 containing the name of an authoritative root name server, and an ip4 2499 or ip6 assertion of the root name server mentioned in the redirection 2500 assertion. These assertions must be obtained through a secure out of 2501 band mechanism. For a caching server, it is sufficient to have a 2502 connection to a recursive resolver which does the lookup on its 2503 behalf. 2505 When a zone authority delegates a part of its namespace to a 2506 subordinate, it MUST sign and serve the assertions of the three above 2507 mentioned types. This information is necessary for a recursive 2508 resolver to determine in a recursive lookup where to ask for a more 2509 specific answer and to validate the response. 2511 7.3. Cooperative Delegation Distribution 2513 Regardless of any other configuration directive, a RAINS server MUST 2514 be prepared to provide a full chain of delegation assertions from the 2515 appropriate delegation root to the signature on any assertion it 2516 gives to a peer or a client, whether as additional assertions on a 2517 message answering a query, or in reply to a subsequent query. This 2518 property allows RAINS servers to maintain a full delegation tree. 2520 7.4. Assertion Lifetime Management 2522 An assertion can contain multiple signatures, each with a different 2523 lifetime. Signature lifetimes are equivalent to a time to live in 2524 the present DNS: authorities should compute a new signature for each 2525 validity period, and make these new signatures available when old 2526 ones are expiring. 2528 Since assertion lifetime management is based on a real-time clock 2529 expressed in UTC, RAINS servers MUST use a clock synchronization 2530 protocol such as NTP [RFC5905]. 2532 RAINS servers MAY coalesce assertion lifetimes, e.g. using only the 2533 most recent valid-until time in their cache management. This implies 2534 that an assertion with valid signatures in time intervals (T1, T2) 2535 and (T3, T4) such that T3 > T2 may be cached during the interval (T2, 2536 T3) as well. Authorites MUST NOT rely on non-caching or non- 2537 availability of assertions during such intervals. 2539 7.5. Secret Key Management 2541 The secret keys associated with public keys for each RAINS server 2542 (via infrakey objects) must be available on that server, whether 2543 through a hardware or software security device, so they can sign 2544 messages on demand; this is particularly important for query servers. 2545 In addition, the secret keys associated with TLS certificates for 2546 each server (published via certinfo objects) must be available as 2547 well in order to establish TLS sessions. 2549 However, storing zone secret keys (associated via delegation objects) 2550 on RAINS servers would represent a more serious operational risk. To 2551 keep this from being necessary, authority servers have an additional 2552 signer interface, from which they will accept and cache any 2553 assertion, shard, or zone for which they are authority servers until 2554 at least the end of validity of the last signature, provided the 2555 signature is verifiable. 2557 7.6. Public Key Management 2559 As signature lifetime is used to manage assertion lifetime, and key 2560 rotation strategies may be used both for revocation as well as 2561 operational flexibility purposes, RAINS presents a much more dynamic 2562 key management environment than that presented by DNSSEC. 2564 7.6.1. Key Phase and Key Rotation 2566 Each signature and public key in a RAINS message is associated with a 2567 key phase, allowing multiple keys to be valid for a given authority 2568 at any given time. For example, given two key phases and a key 2569 validity interval of one day, a phase 0 key would be valid from 00:00 2570 on day 0 to 00:00 on day 1, and a phase 1 key valid from 12:00 on day 2571 0 to 12:00 on day 1. When the phase 0 key expires, it would be 2572 replaced by a new phase 0 valid from 00:00 on day 1 to 00:00 on day 2573 2, and so on. 2575 Since the end time of the validity of a signature on an assertion is 2576 the maximum of the validity of the signatures on each of the 2577 delegations in the delegation chain from the root, key rotation 2578 avoids mass expiration of assertions, at the cost of requiring one 2579 valid signatures per key phase on at least all delegation assertions. 2580 Key rotation schedules are a matter of authority operational policy, 2581 but key validity intervals should be longer the closer in the 2582 delegation chain an assertion is to the root. 2584 7.6.2. Next Key Assertions 2586 Another problem this dyanmic envrionment raises is how a zone 2587 authority communicates to its superordinate that it would like to 2588 begin using a new public key to sign its assertions. 2590 This can be done out of band, using private APIs provided by the 2591 superordinate authority. Through the nextkey object type, RAINS 2592 provides a way for a future public key to be shared with the 2593 superordinate authority (and all other queriers) in-band. An 2594 authority that wishes to use a new key publishes a reflexive nextkey 2595 assertion (i.e., in its own zone, with subject @) with the new public 2596 key and a requested valid-since and valid-until time range. The 2597 superordinate issues periodic queries for nextkey assertions from its 2598 subordinate zone, or the subordinate pushes these assertions to an 2599 intermediate service designated to receive them. When the 2600 superordinate receives a nextkey, and it decides it wants to delegate 2601 to the new key, it creates and signs a delegation assertion. 2603 This process is not mandatory: the superordinate is free to ignore 2604 the request, or to use a different time range, depending on its 2605 policy and/or the status of its business relationship with the 2606 subordinate. The subordinate can discover this, in turn, using its 2607 own RAINS queries, or through the delegation assertions being 2608 similarly pushed to a designated intermediate service. 2610 8. Experimental Design and Evaluation 2612 The protocol described in this document is intended primarily as a 2613 prototype for discussion, though the goal of the document is to 2614 specify RAINS completely enough to allow independent, interoperable 2615 implementation of clients an servers. The massive inertia behind the 2616 deployment of the present domain name system makes full deployment as 2617 a replacement for DNS unlikely. Despite this, there are some 2618 criteria by which the success of the RAINS experiment may be judged: 2620 First, deployment in simulated or closed networks, or in alternate 2621 Internet architectures such as SCION, allows implementation 2622 experience with the features of RAINS which DNS lacks (signatures as 2623 a first-order delegation primitive, support for explicit contexts, 2624 explicit tradeoffs in queries, runtime availability of registrar/ 2625 registrant data, and nameset support), which in turn may inform the 2626 specification and deployment of these features on the present DNS. 2628 Second, deployment of RAINS "islands" in the present Internet 2629 alongside DNS on a per-domain basis would allow for comparison 2630 between operational and implementation complexity and efficiency and 2631 benefits derived from RAINS' features, as information for future 2632 development of the DNS protocol. 2634 9. Security Considerations 2636 This document specifies a new, experimental protocol for Internet 2637 name resolution, with mandatory integrity protection for assertions 2638 about names built into the information model, and confidentiality for 2639 query information protected on a hop-by-hop basis. 2641 9.1. Integrity and Confidentiality Protection 2643 Assertions are not valid unless they contain at least one signature 2644 that can be verified from the chain of authorities specified by the 2645 name and context on the assertion; integrity protection is built into 2646 the information model. The infrastructure key object type allows 2647 keys to be associated with RAINS servers in addition to zone 2648 authorities, which allows a client to delegate integrity verification 2649 of assertions to a trusted query service (see Section 6.3). 2651 Since the job of an Internet naming service is to provide publicly- 2652 available information mapping names to information needed to connect 2653 to the services they name, confidentiality protection for assertions 2654 is not a goal of the system. Specifically, the information model and 2655 the mechanism for proving nonexistence of an assertion is not 2656 designed to provide resistance against zone enumeration. 2658 On the other hand, confidentiality protection of query information is 2659 crucial. Linking naming queries to a specific user can be nearly as 2660 useful to build a profile of that user for surveillance purposes as 2661 full access to the clear text of that client's communications 2662 [RFC7624]. In this revision, RAINS uses TLS to protect 2663 communications between servers and between servers and clients, with 2664 certificate information for RAINS infrastructure stored in RAINS 2665 itself. Together with hop-by-hop confidentiality protection, query 2666 options, proactive caching, default use of non-persistent tokens, and 2667 redirection among servers can be used to mix queries and reduce the 2668 linkability of query information to specific clients. 2670 10. IANA Considerations 2672 The present revision of this document has no actions for IANA. 2674 The authors have registered the CBOR tag 15309736 to identify RAINS 2675 messages in the CBOR tag registry at 2676 https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml. 2678 RAINS servers currently listen for connections from other servers by 2679 default on TCP port 7753. This port has not been registered with 2680 IANA, and is intended only for experimentation with RAINS on closed, 2681 non-Internet-connected networks. Future revisions of this document 2682 may specify a different port, registered with IANA via Expert Review 2683 [RFC5226]. 2685 The urn:x-rains namespace used by the RAINS capability mechanism in 2686 Section 5.9 may be a candidate for replacement with an IANA- 2687 registered namespace in a future revision of this document. 2689 11. Acknowledgments 2691 Thanks to Daniele Asoni, Laurent Chuat, Markus Deshon, Ted Hardie, 2692 Joe Hildebrand, Tobias Klausmann, Steve Matsumoto, Adrian Perrig, 2693 Raphael Reischuk, Wendy Seltzer, Andrew Sullivan, and Suzanne Woolf 2694 for the discussions leading to the design of this protocol, and the 2695 definition of an ideal naming service on which it is based. Thanks 2696 especially to Stephen Shirley for detailed feedback. 2698 12. References 2700 12.1. Normative References 2702 [FIPS-186-3] 2703 NIST, ., "Digital Signature Standard FIPS 186-3", June 2704 2009. 2706 [FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen, 2707 "The FNV Non-Cryptographic Hash Algorithm", draft- 2708 eastlake-fnv-16 (work in progress), December 2018. 2710 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2711 RFC 793, DOI 10.17487/RFC0793, September 1981, 2712 . 2714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2715 Requirement Levels", BCP 14, RFC 2119, 2716 DOI 10.17487/RFC2119, March 1997, 2717 . 2719 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2720 specifying the location of services (DNS SRV)", RFC 2782, 2721 DOI 10.17487/RFC2782, February 2000, 2722 . 2724 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2725 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2726 2003, . 2728 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2729 Housley, R., and W. Polk, "Internet X.509 Public Key 2730 Infrastructure Certificate and Certificate Revocation List 2731 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2732 . 2734 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2735 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2736 DOI 10.17487/RFC6234, May 2011, 2737 . 2739 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2740 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2741 October 2013, . 2743 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2744 Signature Algorithm (EdDSA)", RFC 8032, 2745 DOI 10.17487/RFC8032, January 2017, 2746 . 2748 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 2749 Algorithm (EdDSA) Signatures in the Cryptographic Message 2750 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 2751 2018, . 2753 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2754 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2755 . 2757 12.2. Informative References 2759 [BETTER-BLOOM-FILTER] 2760 Adam Kirsch, . and . Michael Mitzenmacher, "Building a 2761 Better Bloom Filter", May 2008. 2763 [I-D.ietf-dprive-dns-over-tls] 2764 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2765 and P. Hoffman, "Specification for DNS over TLS", draft- 2766 ietf-dprive-dns-over-tls-09 (work in progress), March 2767 2016. 2769 [I-D.ietf-dprive-dnsodtls] 2770 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 2771 over Datagram Transport Layer Security (DTLS)", draft- 2772 ietf-dprive-dnsodtls-15 (work in progress), December 2016. 2774 [I-D.trammell-optional-security-not] 2775 Trammell, B., "Optional Security Is Not An Option", draft- 2776 trammell-optional-security-not-00 (work in progress), 2777 March 2018. 2779 [IAB-UNICODE7] 2780 IAB, ., "IAB Statement on Identifiers and Unicode 7.0.0", 2781 n.d., . 2785 [LUCID] Freytag, A. and A. Sullivan, "LUCID problem (slides, IETF 2786 92 LUCID BoF)", n.d., 2787 . 2790 [PARSER-BUGS] 2791 Bratus, S., Patterson, M., and A. Shubina, "The Bugs We 2792 Have To Kill (USENIX login)", August 2015. 2794 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 2795 and Secure Transport", draft-ietf-quic-transport-17 (work 2796 in progress), December 2018. 2798 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2799 Rose, "DNS Security Introduction and Requirements", 2800 RFC 4033, DOI 10.17487/RFC4033, March 2005, 2801 . 2803 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2804 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2805 2006, . 2807 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2808 (CIDR): The Internet Address Assignment and Aggregation 2809 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2810 2006, . 2812 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2813 IANA Considerations Section in RFCs", RFC 5226, 2814 DOI 10.17487/RFC5226, May 2008, 2815 . 2817 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2818 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 2819 . 2821 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2822 "Network Time Protocol Version 4: Protocol and Algorithms 2823 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2824 . 2826 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 2827 of Named Entities (DANE) Transport Layer Security (TLS) 2828 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2829 2012, . 2831 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2832 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2833 DOI 10.17487/RFC7231, June 2014, 2834 . 2836 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2837 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2838 DOI 10.17487/RFC7540, May 2015, 2839 . 2841 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 2842 Trammell, B., Huitema, C., and D. Borkmann, 2843 "Confidentiality in the Face of Pervasive Surveillance: A 2844 Threat Model and Problem Statement", RFC 7624, 2845 DOI 10.17487/RFC7624, August 2015, 2846 . 2848 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 2849 Agility and Selecting Mandatory-to-Implement Algorithms", 2850 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 2851 . 2853 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2854 and P. Hoffman, "Specification for DNS over Transport 2855 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2856 2016, . 2858 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 2859 Kumari, "Client Subnet in DNS Queries", RFC 7871, 2860 DOI 10.17487/RFC7871, May 2016, 2861 . 2863 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 2864 Transport Layer Security (DTLS)", RFC 8094, 2865 DOI 10.17487/RFC8094, February 2017, 2866 . 2868 [SCION] Barrera, D., Reischuk, R., Szalachowski, P., and A. 2869 Perrig, "SCION Five Years Later - Revisiting Scalability, 2870 Control, and Isolation Next-Generation Networks 2871 (arXiv:1508.01651v1)", August 2015. 2873 [XEP0115] Hildebrand, J., Saint-Andre, P., Troncon, R., and J. 2874 Konieczny, "XEP-0115 Entity Capabilities", February 2008. 2876 Authors' Addresses 2878 Brian Trammell 2879 ETH Zurich 2880 Universitaetstrasse 6 2881 Zurich 8092 2882 Switzerland 2884 Email: ietf@trammell.ch 2885 Christian Fehlmann 2886 ETH Zurich 2888 Email: fehlmannch@gmail.com