DNS-over-TLS for insecure delegations
draft-bretelle-dprive-dot-for-insecure-delegations-00

Abstract

This document describes an alternate mechanism to DANE ([RFC6698]) in order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative server by not making DNSSEC a hard requirement, making DoT server authentication available for insecure delegations.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 31, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Authenticating an insecure delegation
• 3.1. Public Key Infranstructure (PKIX)
• 3.2. Simple Public-Key Infrastructure (SPKI)
• 3.3. Authenticating from the parent
• 3.3.1. Example
• 4. DSPKI Resource Record
• 4.1. DSPKI RDATA Format
• 5. Security Considerations
• 6. IANA Considerations
• 7. Normative References
• Acknowledgments
• Author's Address

1. Introduction

This document describes an alternate mechanism to [RFC6698] as described in [I-D.bortzmeyer-dprive-resolver-to-auth] Section 2 extending the authentication of DoT [RFC7858] to insecure delegations and therefore enabling the onboarding of DoT authoritative servers without the requirement for the authorities to support DNSSEC ([RFC4033], [RFC4034], and [RFC4035]). To do so, this document introduce the Delegation SPKI (DSPKI) resource record, its purpose, usage and format.

2. Terminology

A server that supports DNS-over-TLS is called a “DoT server” to differentiate it from a “DNS Server” (one that provides DNS service over any other protocol), likewise, a client that supports this protocol is called a “DoT client”

A secure delegation ([RFC4956] Section 2) is a signed name containing a delegation (NS RRset), and a signed DS RRset, signifying a delegation to a signed zone.

An insecure delegation ([RFC4956] Section 2) is a signed name containing a delegation (NS RRset), but lacking a DS RRset, signifying a delegation to an unsigned subzone.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Authenticating an insecure delegation

To authenticate a DoT server of a secure delegation, it is possible to use the TLSA resource record [RFC6698] of the nameserver as decribed in [I-D.bortzmeyer-dprive-resolver-to-auth] Section 2, while this method is valid, the absence of support of DNSSEC for such delegations precludes the onboarding and discovery of nameservers serving those zones as DoT servers.

Without the use of DNSSEC, a delegation is not able to authenticate itself as the chain of trust cannot be followed, however other mechanisms exist to have a server authenticate itself, such as Public Key Infrastructure (PKIX [RFC6125]) , SPKI, which have their own pros and cons.

3.1. Public Key Infranstructure (PKIX)

It would be possible to authenticate the nameservers of the insecure delegation using PKIX, relying on an existing trust model and trust anchors.

While simple, a single trusted CA that breaks said trust (voluntarily or involuntarily), can issue certificate for any domains, allowing an attacker to potentially impersonate both the application and the DoT server.

Another issue that rises is that the DoT servers may use an identity which belong to the same origin as application servers, which could permit personal information (such as cookies) to be leaked to the DoT servers.

3.2. Simple Public-Key Infrastructure (SPKI)

SPKI on the other hand does not have the same issues than PKIX, the certificates can be generated by the authority itself, adding a separation of privileges between the PKIX infrastructure and the DNS one.

The problem is now on how to advertise/distribute the delegation’s public key.

This is in essence what TLSA records solve, but with the use of DNSSEC enabled and functional for the queried zone. For insecure delegations, simply advertising the public key would be subject to interception and mangling.

3.3. Authenticating from the parent

While a delegation is not secured, the DNS core infrastructure already support DNSSEC, meaning that if the owner of an insecure delegation could set the public key to authenticate the DoT servers against, such key could be authenticated using DNSSEC at the parent level, which would then permit trusting the DoT servers providing their certificate validates against the ( then validated) public key provided by the parent.

From this stage, the “formerly” insecure delegation can be authenticated, and therefore considered secure, allowing delegating to other zones which can be authenticated by either DNSSEC or TLS.

In order to provide its public key to the DoT clients, an insecure would set the DSPKI RRset at the parent with the content of its extracted SPKI, which the parent then sign.

A DoT client which is about to talk with a DoT server can obtain and validate the DSPKI RRset from the parent and authenticate the DoT server, without needing the DoT server to serve a secure delegation.

3.3.1. Example

example.com is an insecure delegation from .com which has set the DSPKI RRset.

A DoT client looking for records under example.com will learn from .com that example.com is delegated to

example.com 172800 NS ns1.example.com
example.com 172800 NS ns2.example.com
example.com 86400 DSPKI h0KPxSKAPTEGXnvOPPA/5HUJZjHl4Hu9eg/eYMTPJcc=
ns1.example.com 172800 AAAA 2001:db8:abcd:12:1:2:3:4
ns2.example.com 172800 AAAA 2001:db8:abcd:ab:1:2:3:4

with the accompanying signature.

The DSPKI RRset signals that the nameservers are able to support DNS-over-TLS and the DoT client can authenticate them using the provided public key,

If subzone.example.com is a delegation from example.com, example.com can provide the DSPKI RRSet of the delegation. While example.com is not a secured delegation, because it has been authenticated using TLS, it is also able to be part of the chain of trust and provide either a DS or DSPKI RRset for subzone.example.com

4. DSPKI Resource Record

There may be 0 or more DSPKI served by the parent of the delegation. 0 would mean that DSPKI is not supported, therefore the DoT client could try other alternatives. 1 or multiple public keys can be distributed to let the DoT client validate multiple public keys, which can be useful while doing certificate rotation or when willing to provide different secret keys to different providers that may serve the delegated zone.

4.1. DSPKI RDATA Format

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                  PUBKEY                       /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Where PUBKEY: A base64 encoded string of the sha256sum of the public key, as generated by: ~~~~ openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform der | \ openssl dgst -sha256 -binary | openssl enc -base64 ~~~~

FIXME: consider * format that can evolve over time, e.g 1 byte specifying hashing algorithm. * no need for base64, raw bytes are fine. * alternate URI to support DoT (host, port, spki), DoH (host, port, URL template), DNS-over-QUIC… would rather be an ALTNS type of record * CDSPKI a la CDS, CDNSKEY

5. Security Considerations

TODO Security

6. IANA Considerations

TODO: This document requires IANA actions (new RR type).

7. Normative References

Acknowledgments

TODO acknowledge.

Author's Address