Skip to content

Latest commit

 

History

History
213 lines (166 loc) · 8.87 KB

HIP-0007.md

File metadata and controls

213 lines (166 loc) · 8.87 KB
Raw

HIP-0007 : DANE for Decentralized Naming Systems (dDANE)

Number:  HIP-0007
Title:   DANE for Decentralized Naming Systems (dDANE)
Type:    Informational
Status:  Draft
Authors: Matthew Zipkin (@pinheadmz)
         Hasan Adams (@buffrr)
Created: 2021-06-17

Abstract

ICANN-rooted DNS is not the only internet naming system available to users, but it is the only naming system in which certificate authorities issue SSL certificates. Since SSL certificates are the mechanism behind HTTPS, browsing securely to websites outside the ICANN-rooted DNS is difficult and out of scope for the majority of users.

DANE is a protocol that uses DNSSEC to authenticate SSL certificates as presented by a web server and could be used to bypass certificate authorities, assuming the naming system is trusted or cryptographically secure.

DANE is an old innovation, initially proposed in 2012 in RFC6698 and updated in 2015 in RFC7671. It has been met with consistent rejection, particularly from web browsers: 1 2 3 4 The arguments against DANE/DNSSEC adoption by web browsers can be summarized as follows:

  1. DNSSEC is unnecessary
  2. DNSSEC is a government-controlled PKI
  3. DNSSEC is cryptographically weak
  4. DANE is slow

Note that these widely-shared critiques are themselves over six years old, and there is a new exciting technology that can breathe new life into the DANE use-case: BLOCKCHAIN. In particular, there are many blockchain-based domain naming systems in production today, including Handshake, Namecoin, Ethereum Name Service, Unstoppable Domains, yat, and Butterfly Protocol. Every single one of these domain name systems needs DANE support in web browsers or their users will have no security. Without convenient and secure web browsing accessible to the average user, none of these systems will ever gain wide adoption.

Decentralized, blockchain-based naming systems offer a brand new security model and a brand new class of users and services, meaning that there is no "legacy" infrastructure to update. If we establish a high-quality standard right now, there will be no resistance from old systems that can refuse to upgrade, simply because there are no old systems yet. Therefore:

  1. DNSSEC is necessary for DANE, which means secure browsing to websites hosted on decentralized naming systems.
  2. DNSSEC is not government-controlled if the domain name root zone is secured by a decentralized consensus mechanism like proof-of-work.
  3. DNSSEC can be strong if all participants agree to require high-quality cryptosystems.
  4. DANE is slow: decentralized systems are never convenient and there are difficult trade-offs for adoption. Simple technology like caching can help improve this lag.

Motivation

We propose a secure, simplified subset of the DANE protocol that can secure the entire blockchain-naming ecosystem. Its properties are chosen to provide state-of-the-art cryptographic security and limited flexibility to reduce the technical effort required by web browsers to implement it.

Goals

  1. Do not alter or affect in any way the resolution, authentication, or fetching of ICANN-rooted domain names.

  2. When browsing to a decentralized domain name, indicate to the user whether or not the connection is secure (just like for legacy domains). A connection MUST be indicated as secure ONLY if ALL requirements of the specification are satisfied.

  3. Reduce the complexity (and increase the cryptographic security) of implementing DANE in browsers by limiting available options.

Specification

DNS Resolution

This protocol does not require that browsers resolve domain names internally, although some networks like Handshake and Namecoin have embedable light clients: hnsd ncds. It is expected that users will already have their system configured to resolve names by a trusted resolver (e.g. validating proof-of-work) that is either maintained by themselves or optionally, by a browser vendor for public use. Such a resolver MUST verify DNSSEC and ONLY set the DNS ad bit when DNSSEC is validated according to this specification. If the ad bit is not set, the protocol has failed and the user should be alerted that the connection is insecure. DNSSEC validity MUST be checked by the browser for the certificate matching record (TLSA). No other DNS records need to be examined by the browser internally.

We do not require the browser itself to resolve domain names or verify DNSSEC, we only require it to check that an ad bit has been set on two queries (location and certificate match).

Root KSK

The security of "legacy" DNS, DNSSEC and DANE comes down to single key: ICANN's KSK2017. Since all decentralized naming systems replace this security model with their own protocol, this key is not part of our system. However since we want to approach DANE with as much legacy compatibility as possible, some kind of root KSK must be trusted by the resolver that verifies DNSSEC.

For example, the Handshake full node reference implementation hsd has a built-in root authoritative name server which signs all requests with a "public private key" (after verifying proof-of-work). This private key is hard-coded into the software and because it is public, the user must have a secure connection with a trusted HNS resolver.

That connection can be secured with:

  • DNS-over-HTTPS: In this context, "HTTPS" relies entirely on legacy DNS and certificate authority infrastructure and is therefore not recommended for decentralized naming systems, despite the fact that it may be the most convenient method accessible to less advanced users.

  • SIG0: To authenticate responses from a trusted resolver, the browser MUST allow users to enter their resolver's public key. All Handshake full nodes generate a public key for this function and that key can be fetched by the full node operator. This is an example of an hsd node's URI containing it's SIG0 public key and IP address:

    aonetsezqp4m52w4jpfq2gv3dggy2wqfwqtkfjyttgdidbvhgp5as@165.22.151.242

  • Network firewall: if the browser is running on the same machine or local network as the decentralized name resolver, an advanced user may choose to ignore SIG0 verification, although this is not recommended.

Protocol

  1. When a user enters a URL into the browser, the software SHOULD first test the top-level domain for inclusion in the current ICANN root zone. This is a very fast test, and can be executed with a regex that the browser will only need to update a few times per year. If the TLD is found in the current ICANN root zone, this protocol is aborted and the browser should continue resolution and processing according to its "legacy" protocol.

  2. For all other top-level-domains including names in the Handshake root zone, .bit (Namecoin) or .eth (Ethereum Name Service), this protocol SHALL be applied and the user should be alerted whether or not a connection is considered secure by these definitions.

DNS Records

DANE is defined by a series of DNS record types. We specify a limited set of options for each record type to accomplish our goals. In particular, we limit algorithms and hash functions:

ALGO: Allowed signing algorithms

Value Name
8 RSASHA256
10 RSASHA512
13 ECDSAP256SHA256
15 ED25519

HASH: Allowed hash algorithms

Value Name
2 SHA256
5 SHA512

MATCH: Allowed matching algorithms

Value Name
1 SHA256
2 SHA512

DS Records:

Field Size Allowed Values
Key Tag 2 bytes
Algorithm 1 byte ALGO
Digest Type 1 byte HASH
Digest var

DNSKEY Records:

Field Size Allowed Values
Flags 2 byte
Protocol 1 byte 3
Algorithm 1 byte ALGO
Public Key var

TLSA Records:

Field Size Allowed Values
Usage 1 byte 3 (DANE-EE)
Selector 1 byte 1 (SubjectPublicKeyInfo)
Matching Type 1 byte MATCH
Certificate var