DNS-over-TLS for insecure delegationsFacebookchantra@fb.com
Internet
Network Working GroupInternet-DraftThis document describes an alternate mechanism to DANE () in order
to authenticate a DNS-over-TLS (DoT ) authoritative server by not
making DNSSEC a hard requirement, making DoT server authentication available for
insecure delegations.This document describes an alternate mechanism to as described in
Section 2 extending the
authentication of DoT to insecure delegations and therefore
enabling the onboarding of DoT authoritative servers without the requirement
for the authorities to support DNSSEC (, , and
).
To do so, this document introduce the Delegation SPKI (DSPKI) resource record,
its purpose, usage and format.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 ( 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 ( 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 when, and only when, they
appear in all capitals, as shown here.To authenticate a DoT server of a secure delegation, it is possible to use the
TLSA resource record of the nameserver as decribed in
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 ) , SPKI, which have their own pros and cons.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.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.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.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 towith 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.comThere 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.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, CDNSKEYTODO SecurityTODO: This document requires IANA actions (new RR type).Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.DNS Security Introduction and RequirementsThe Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]Resource Records for the DNS Security ExtensionsThis document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]Protocol Modifications for the DNS Security ExtensionsThis document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]DNS Security (DNSSEC) Opt-InIn the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. This memo defines an Experimental Protocol for the Internet community.Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSAEncrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.Specification for DNS over Transport Layer Security (TLS)This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Encryption and authentication of the DNS resolver-to-authoritative communicationThis document proposes a mechanism for securing (privacy-wise) the communication between the DNS resolver and the authoritative name server. REMOVE BEFORE PUBLICATION: this document should be discussed in the IETF DPRIVE group, through its mailing list. The source of the document, as well as a list of open issues, is currently kept at Github [1].TODO acknowledge.