A Bootstrapping Procedure to
Discover and Authenticate DNS-over-(D)TLS and DNS-over-HTTPS
ServersMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comUSAdan@danwing.orgSandelman Software WorksUSAmcr+ietf@sandelman.caOrangeRennes35000Francemohamed.boucadair@orange.comDPRIVE WGThis document specifies mechanisms to automatically bootstrap
endpoints (e.g., hosts, Customer Equipment) to discover and authenticate
DNS-over-(D)TLS and DNS-over-HTTPS servers provided by a local
network.Traditionally a caching DNS server has been provided by the local
network. This provides benefits like low latency to that DNS server (due
to its network proximity to the endpoint). However, if an endpoint is
configured to use Internet-hosted or public DNS-over-(D)TLS or
DNS-over-HTTPS servers, the local DNS
server cannot serve the DNS requests from the endpoints. If public DNS
servers are used instead of using local DNS servers, the operational
problems are listed below:"Split DNS" to use the special
internal-only domain names (e.g., "internal.example.com") in
enterprise networks will not work, and ".local" and "home.arpa"
names cannot be locally resolved in home networks.Content Delivery Networks (CDNs) that map traffic based on DNS
may lose the ability to direct end-user traffic to a nearby cluster
in cases where a DNS service is being used that is not affiliated
with the local network and which does not send "EDNS Client Subnet"
(ECS) information to the CDN's DNS
authorities .Some clients have pre-configured specific public DNS servers
(such as Mozilla using Cloudflare's DNS-over-HTTPS server). If
endpoints continue to use pre-configured public DNS servers, this
has a risk of relying on few centralized DNS services.If public DNS servers are used instead of using local DNS servers,
the following paragraph discusses the impact on Network-based
security:Various network security services are provided by Enterprise, secure
home and wall-gardened networks to protect endpoints (e.g,. Hosts, IoT
devices). discusses
some of the Network-based security use cases. These network security
services act on DNS requests from endpoints. However, if an endpoint is
configured to use public DNS-over-(D)TLS or DNS-over-HTTPS servers,
network security services cannot act efficiently on DNS requests from
the endpoints. In order to act on DNS requests from endpoints, network
security services can block DNS-over-(D)TLS traffic by dropping outgoing
packets to destination port 853. Identifying DNS-over-HTTPS traffic is
far more challenging than DNS-over-(D)TLS traffic. Network security
services can try to identify the domains offering DNS-over-HTTPS
servers, and DNS-over-HTTPS traffic can be blocked by dropping outgoing
packets to these domains. If the endpoint has enabled strict privacy
profile (Section 5 of ), and the network
security service blocks the traffic to the public DNS server, DNS
service is not available to the endpoint and ultimately the endpoint
cannot access Internet. If the endpoint has enabled opportunistic
privacy profile (Section 5 of ), and the
network security service blocks traffic to the public DNS server, the
endpoint will either fallback to an encrypted connection without
authenticating the DNS server provided by the local network or fallback
to clear text DNS, and cannot exchange encrypted DNS messages.If the network security service fails to block DNS-over-(D)TLS or
DNS-over-HTTPS traffic, this can compromise the endpoint security; some
of the potential security threats are listed below:The network security service cannot prevent an endpoint from
accessing malicious domains.If the endpoint is an IoT device which is configured to use
public DNS-over-(D)TLS or DNS-over-HTTPS servers, and if a policy
enforcement point in the local network is programmed using a
Manufacturer Usage Description (MUD) file by a MUD manager to only allow
intented communications to and from the IoT device, the policy
enforcement point cannot enforce the Network Access Control List
rules based on domain names (Section 8 of ).If the network security service sucessfully blocks DNS-over-(D)TLS
and DNS-over-HTTPS traffic, this can still compromise the endpoint
security and privacy; some of the potential security threats are listed
below:Pervasive monitoring of DNS traffic.An internal attacker can modify the DNS responses to re-direct
the client to incorrect and malicious servers.To overcome the above threats, the document proposes a mechanism to
automatically bootstrap the endpoints to discover and authenticate the
DNS-over-(D)TLS and DNS-over-HTTPS servers provided by the local
network. The overall procedure can be structured into the following
steps:Bootstrapping phase (
and ) is meant to automatically
bootstrap endpoints with local network's CA certificates and DNS
server certificate.Discovery phase () is meant to
discover the privacy-enabling protocols supported by the DNS server
and usable DNS server IP addresses and port numbers.Connection handshake and service invocation: The DNS client
initiates (D)TLS handshake with the DNS server learned in the
discovery phase. Furthermore, DNS client uses the credentials
discovered during the bootstrapping phase to validate the server
certificate.Note: The strict and opportunistic privacy profiles as defined in
only applies to DNS-over-(D)TLS
protocols, there has been no such distinction made for DNS-over-HTTPS
protocol.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.(D)TLS is used for statements that apply to both Transport Layer
Security and Datagram Transport Layer
Security . Specific terms are used for any
statement that applies to either protocol alone.This document uses the terms defined in .The following steps explain the mechanism to automatically bootstrap
an endpoint with the local network's CA certificates and DNS server
certificate: The endpoint authenticates to the local network and discovers the
EST server using DNS-based Service Discovery .The endpoint establishes provisional TLS connection with the EST
server, i.e. the endpoint provisionally accepts the unverified TLS
server certificate. However, the endpoint MUST authenticate the EST
server before it can accept the CA certificates. The endpoint either
uses Secure Remote Password protocol (SRP) as an authentication method for the Transport
Layer Security protocol or uses the
mutual authentication scheme discussed in to authenticate the discovered EST server.
SRP is an authentication method that allows the use of usernames and
passwords over unencrypted channels without revealing the password
to an eavesdropper. Similarty, the mutual authentication scheme is
based on password-based authenticated key exchange (PAKE) and
provides mutual authentication between a HTTP client and an HTTP
server using username and password as credentials.If the EST server authentication is successful, the endpoint
requests the full EST distribution of current CA certificates and
validates the EST server certificate. If the EST server certificate
cannot be verified using the CA certificates downloaded, the TLS
connection is immediately discarded and the endpoint abandons the
attempt to bootstrap from the EST server and discards the CA
certificates conveyed by the EST server. If the EST server
certificate is verified using the CA certificates downloaded, the
endpoint stores the CA certificates as Explicit Trust Anchor
database entries. The endpoint uses the Explicit Trust Anchor
database to validate the DNS server certificate. The endpoint needs
to perform SCRAM authentication the first time it connects EST
server. On subsequent connections to the EST server, the endpoint
can validate the EST server certificate using the Explicit Trust
Anchor database.The endpoint learns the End-Entity certificates from the EST server. The certificate
provisioned to the DNS server in the local network will be treated
as a End-Entity certificate. The endpoint needs to identify the
certificate provisioned to the DNS server. The SRV-ID identifier
type within subjectAltName entry can
be used to identify the DNS server certificate. For example, DNS
server certificate will include SRV-ID "_domain-s.example.net" along
with DNS-ID "example.net". This specification defines SRV service
label "domain-s" in . As a reminder, the
protocol component is not included in the SRV-ID .The following steps explain the mechanism to automatically bootstrap
IoT devices with local network's CA certificates and DNS server
certificate. The below steps can also be used by CPE acting as DNS
forwarder to discover and authenticate DNS-over-(D)TLS and
DNS-over-HTTPS servers provided by the access network.Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed
in
provides a solution for secure automated bootstrap of devices. BRSKI
specifies means to provision credentials on devices to be used to
operationally access networks. In addition, BRSKI provides an
automated mechanism for the bootstrap distribution of CA
certificates from the EST server. The IoT device can use BRSKI to
automatically bootstrap the IoT device using the IoT manufacturer
provisioned X.509 certificate, in combination with a registrar
provided by the local network and IoT device manufacturer's
authorizing service (MASA). The IoT device authenticates to the local network using the
IoT manufacturer provisioned X.509 certificate. The IoT device
can request and get a voucher from the MASA service via the
registrar. The voucher is signed by the MASA service and
includes the local network's CA public key.The IoT device validates the signed voucher using the
manufacturer installed trust anchor associated with the MASA,
stores the CA's public key and validates the provisional TLS
connection to the registrar.The IoT device requests the full Enrollment over Secure
Transport (EST) distribution of
current CA certificates (Section 5.9.1 in ) from the
registrar operating as a BRSKI-EST server. The IoT devices
stores the CA certificates as Explicit Trust Anchor database
entries. The IoT device uses the Explicit Trust Anchor database
to validate the DNS server certificate.The IoT device learns the End-Entity certificates from the BRSKI-EST server. The
certificate provisioned to the DNS server in the local network
will be treated as a End-Entity certificate. The IoT device
needs to identify the certificate provisioned to the DNS server.
The SRV-ID identifier type within
subjectAltName entry can be used to identify the DNS server
certificate. For example, DNS server certificate will include
SRV-ID "_domain-s.example.net" along with DNS-ID "example.net".
This specification defines SRV service label "domain-s" in . As a reminder, the protocol component is
not included in the SRV-ID .A DNS client discovers the DNS server in the local network supporting
DNS-over-TLS, DNS-over-DTLS and DNS-over-HTTPS protocols by using the
following discovery mechanism:The DNS client retrieves the authentication domain name for the
DNS server from the DNS-ID identifier type within subjectAltName
entry in the DNS server certificate.The DNS client then uses the authentication domain name for
S-NAPTR lookup to learn the protocols
DNS-over-TLS, DNS-over-DTLS, and DNS-over-HTTPS supported by the DNS
server and the DNS privacy protocol preferred by the DNS server
administrators, as specified in and
. This specification adds a SRV service
label "domain-s" for privacy-enabling DNS servers. In the example
below, for authentication domain name 'example.net', the resolution
algorithm will result in the privacy-enabling protocols supported by
the DNS server and usable DNS server IP addresses and port
numbers.If DNS-over-HTTPS protocol is supported by the DNS server, the
DNS client finds the URI template of the DNS-over-HTTPS server using
one of the mechanisms discussed in to use the
https URI scheme (Section 3 of ).Once the DNS client has retrieved the authentication domain name
for the DNS server, an S-NAPTR lookup with 'DPRIVE' application
service and the desired protocol tag is made to obtain information
necessary to securely connect to the DNS server. The S-NAPTR lookup is
performed using an recursive DNS resolver discovered from an untrusted
source (such as DHCP).This specification defines "DPRIVE" as an application service tag
() and "dns.tls" (), "dns.dtls" (),
and "dns.https" () as application
protocol tags.If no DNS-specific S-NAPTR records can be retrieved, the discovery
procedure fails for this authentication domain name. However, before
retrying a lookup that has failed, a DNS client MUST wait a time
period that is appropriate for the encountered error (e.g., NXDOMAIN,
timeout, etc.).The DNS client initiates (D)TLS handshake with the DNS server, the
server presents its certificate in ServerHello message, and the DNS
client matches the DNS server certificate downloaded in step 4 in and with the certificate provided by the DNS
server in (D)TLS handshake. If the match is successful, the DNS client
validates the server certificate using the Explicit Trust Anchor
database entries downloaded in step 3 in and .If the match is successful and server certificate is successfully
validated, the client continues with the connection as normal.
Otherwise, the client MUST treat the server certificate validation
failure as a non-recoverable error. If the DNS client cannot reach or
establish an authenticated and encrypted connection with the
privacy-enabling DNS server provided by the local network, the DNS
client can fallback to the privacy-enabling public DNS server.The bootstrapping procedure to discover and authenticate
DNS-over-(D)TLS and DNS-over-HTTPS Servers MUST be enabled by the
endpoint in a trusted network (e.g. Enterprise, Secure home networks)
and disabled in a untrusted network (e.g. Public WiFi network), similar
to the way VPN connection from the endpoint to a VPN gateway is
disconnected in a trusted network and VPN connection is established in a
untrusted network.If the endpoint has enabled strict privacy profile, and the network
security service blocks the traffic to the privacy-enabling public DNS
server, a hard failure occurs and the user is notified. The user has a
choice to switch to another network or if the user trusts the network,
the user can enable strict privacy profile with the DNS-over-(D)TLS or
DNS-over-HTTPS server discovered in the network instead of downgrading
to opportunistic privacy profile.The primary attacks against the methods described in are the ones that would lead to impersonation
of a DNS server and spoofing the DNS response to indicate that the DNS
server does not support any privacy-enabling protocols. To protect
against DNS-vectored attacks, secured DNS (DNSSEC) can be used to ensure
the validity of the DNS records received. The explicit trust anchor
database entries downloaded in step 3 in and can be used by the endpoint to validate
the DNSSEC signature. Impersonation of the DNS server is prevented by
validating the certificate presented by the DNS server. If the BRSKI-EST
server conveys the DNS server certificate, but the S-NAPTR lookup
indicates that the DNS server does not support any privacy-enabling
protocols, the client can detect the DNS response is spoofed.Security considerations in , and need to be
taken into consideration. discusses DNS privacy considerations
in both "on the wire" (Section 2.4 of )
and "in the server" (Section 2.5 of
contexts. The endpoint may not know if the DNS-over-(D)TLS or
DNS-over-HTTPS server in the local network has a privacy preserving data
policy. A new privacy certificate extension is defined that identifies
the privacy preserving data policy of the DNS server. The extension
contains a URL that points to the privacy preserving data policy.The syntax for the privacy extension is:IANA is requested to allocate the SRV service name of "domain-s" for
DNS-over-(D)TLS and DNS-over-HTTPS.This document requests IANA to make the following allocations from
the registry available at:
https://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xhtml.Application Protocol Tag: DPRIVEIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Application Protocol Tag: dns.tlsIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Application Protocol Tag: dns.dtlsIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Application Protocol Tag: dnshttpsIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick
McManus, Eliot Lear and Sara Dickinson for the discussion and
comments.End-User Mapping: Next Generation Request Routing for Content
DeliverySRP-6: Improvements and Refinements to the Secure Remote
Password Protocol