Wide Area Reachability Protocol

Introduction

The Wide-Area Reachability Protocol (WARP) is a mechanism for hosts to reliably locate one another using cryptographic identities (verifiable public keys) and the Domain Name System (DNS), particularly suited to "machine-to-machine" (M2M) applications, and others where human-readability of DNS labels is not a usability consideration. Using keys in place of other kinds of identifier enables a strong, verifiable, binding between the host providing services (the holder of the private key) and the DNS records describing how to access those services, without the added complexity of an intermediate label whose purpose is to make life slightly easier for humans in some circumstances. By swapping names for keys, using WARP makes it easier to build networked applications which are secure by default.

WARP is vendor- and service provider-agnostic, and is suitable for use in both consumer and enterprise devices. It includes vendor extension points for those applications which require them, and can be tailored for enterprise and cloud hosting environments. As with DNS itself, WARP is most useful when anybody can advertise services and anybody can locate them, but also like DNS itself, there are a range of alternative deployment strategies available which can be used where needed.

Technologies

Transport Layer Security (TLS), X.509 certificates, HTTP, ACME, DNS, DNSSEC, asymmetric cryptography, elliptic curve cryptography, TLS Trust Anchors (TLSA)

Rationale

As both user interfaces and search engine technologies have evolved, the need for users to deal with domain names directly has diminished over time. Nevertheless, the role of the Domain Name System (DNS) in providing a public, persistent, distributed database of hosts and services and related information is just as important as ever.

Whilst the original purpose of DNS was, in effect, to make the lives of human end-users easier, the use of DNS in many applications today is (often for very good usability reasons) an implementation detail, typically with minimal, if any, visibility, let alone control. In these applications, the role of DNS is not to provide a memorable or friendly name to a host, it's simply to provide a consistent—and ideally verifiably secure—means of obtaining the information needed to connect to a pre-defined "known" host, whose name may or may not be at all memorable.

In many applications, in line with good practice, once a connection to a host is established, its identity is cryptographically verified before any information is exchanged (indeed, both hosts’ identities may be to one another)—that is, proving that it is in possession of private key where the other host holds the corresponding public key, or one which has a chain of trust leading to an known trust anchor.

In practice, each domain name and sometimes even each DNS entry carries administrative overheads. Often lightweight, but nonetheless introducing a small added risk of human error and vulnerability to attack. In many applications, where the human-friendliness of the name is not a concern, this seems like a poor trade-off, particularly when security is only as good as the weakest link in the chain.

WARP retains the use of DNS to map an identifier to service information, but changes the nature of that identifier from being a name for humans, to simply the public key itself—effectively skipping the inconvenient middle step. This is not a novel approach, and has been implemented in a number of different systems, including most famously, The Onion Router (Tor). In order to do this, WARP leverages ACME, the automated X.509 certificate provisioning protocol which is seeing widespread adoption, along with an additional HTTP-based API, described in this document, for the holder of the ACME-provisioned certificate to register specific kinds of DNS entry.

Terminology

To avoid confusion with individual protocols, the words "client" and "server" are used only in that context. A WARP host that wishes to advertise information about itself (i.e., a key it holds) is termed an "advertiser", and a WARP host that wishes to discover information that has been advertised is called a "consumer".

Use cases

Home automation

Hub or set-top box: WARP advertiser

Phone or tablet: WARP consumer

Remote telemetry

Autonomous coordination

Remote pair programming

Media transport terminal

Multi-platform instant messenger

Description

The typical arrangement is shown in the below illustration:

 +------------+     +--------------+     +----------+     +-----------+     +----------+
 | Advertiser |---->| Provisioning |---->|   DNS    |<----| Recursive |<----| Consumer |
 |            |     |    Server    |     | Provider |     | Resolver  |     |          |
 +------------+     +--------------+     +----------+     +-----------+     +----------+

In the above diagram, "Host A" is the host advertising services, whilst "Host B" is the host wishing to contact Host A.

Host A contacts the provisioning server using the ACME Protocol, requesting a certificate for itself. In order to request a certificate, it must generate an asymmetric key-pair; the certificate request sent to the provision server contains the public key, and is signed by the private key (proving possession of both public and private keys).

The provisioning server generates a fully-qualified DNS name from the public key using a predictable algorithm (see below), and updates the database to create the initial DNS records, which must include a TXT record containing the base64-encoded public key. A certificate is then issued for that name, signed by the provisioning server's CA key, and returned to host A.

Host A makes a further request to the provisioning protocol, using HTTPS but not an ACME request. This request uses the certificate issued by the provisioning server for client authentication, and submits a JSON payload containing information about services to advertise. The provisioning server processes the JSON and updates the database with SRV, A, AAAA, TXT, and other records records within the domain the certificate was issued for. DNS records can only be updated by the holder of the private key, and only for the domain matching that key (and as a consequence, the certificate).

Subsequently, host B obtains the public key for host A. This could be from an e-mail, a web page, a QR code, embedded in a URL, or even typed out from paper. Host B constructs a fully-qualified DNS name from the public key using the method described below, and, once confirming the public key matches that published in DNS, can then can perform a standard (DNSSEC-validating) requests for records within that domain to locate specific services.

Implementing WARP advertisers

Implementing WARP consumers

Resolution order

Implementing WARP provisioning services

Certificate provisioning

The ACME endpoint will be available at /warp/acme-v01 ...

Differences from a typical certificate authority

• The CA is only trusted by the WARP provisioning service itself, it's not useful for anybody else to use it as a trust anchor
• The issued certificate will contain a subjectAltName of type DNS containing the fully-qualified domain name that has been registered for the host
• The zoneSigningKey extension contains the generated DNSSEC ZSK; this must be signed using the subject's key (which is used as the DNSSEC KSK)
• Only the issuing CA and the subject's public key are relevant to the WARP provisioning service
• DNS entries are expected to remain published until the validUntil timestamp; renewing the certificate before that time will extend their lifespan
• All other parts of the certificate are implementation-defined; applications should avoid making any assumptions about their contents

Service registration payload format

A single service can be registered alone:

{
  "name": "https",
  "proto": "tcp",
  "port": 9033
}

The provisioning server will generate an A or AAAA record automatically (depending upon whether the request was received via IPv4 or IPv6).

Alternatively, a set of services can be registered together:

[
  {
    "name": "https",
    "proto": "tcp",
    "port": 9033
  },
  {
    "name": "kdc",
    "proto": "tcp",
    "port": 88
  },
  {
    "name": "kdc",
    "proto": "udp",
    "port": 88
  }
]

Under normal circumstances, all requests to the registration endpoint will result in a JSON response. If the request could be processed (even if not all of the records could be created), the server returns an array of response objects, matching submission order. If the request could not be processed, for example due to a parse error, an internal error, a network failure, or other critical error condition, the response will be an error condition object. In extreme circumstances, the server may return a non-JSON response, which should always considered an error.

[
  {
    "name": "https",
    "proto": "tcp",
    "port": 9033,
    "status": "created",
    "fqdn": "_https._tcp.xzzbvutoahhfo7gxi52ignamxcuy5agh7xshkgtgzcswmwk4y6l7cgyd.x25519.SERVICES.ARPA."
  },
  {
    "name": "kdc",
    "proto": "tcp",
    "port": 88,
    "status": "created",
    "fqdn": "_kdc._tcp.xzzbvutoahhfo7gxi52ignamxcuy5agh7xshkgtgzcswmwk4y6l7cgyd.x25519.SERVICES.ARPA."
  },
  {
    "name": "kdc",
    "proto": "tcp",
    "port": 88,
    "status": "created",
    "fqdn": "_kdc._udp.xzzbvutoahhfo7gxi52ignamxcuy5agh7xshkgtgzcswmwk4y6l7cgyd.x25519.SERVICES.ARPA."
  }
]

Considerations for operating a public provisioning service

Fully-qualified DNS name generation algorithm

The details of the approach used to generate a DNS name from a key depends upon the type of key. In each case, the result is one or more dot-separated DNS labels, to which a fixed, well-known, domain name (e.g., SERVICES.ARPA), ideally supported by a well-maintained selection of anycast nodes, is appended.

For elliptic curve keys, strongly preferred the public key is short enough to fit entirely into a DNS label when appropriately-encoded, and this is identical to approach used in Tor v3 addresses. This means that the TXT record published by the provisioning server is superfluous (because there is nothing in the record not already within the DNS label) but this is of little consequence.

Enterprise, cloud, ISP/telco, and vendor considerations

Relationship with other technologies

DANE

Tor and peer-to-peer (P2P) networks

Security & privacy considerations

• Certificate lifetime
• DNS RR lifetime
• DNSSEC validation is mandatory (but if the KSK matches the advertiser's key, does it matter about the rest of the chain?)
• Always check the TXT record to resist clashes