A Bootstrapping Procedure to
Discover and Authenticate DNS-over-(D)TLS and DNS-over-HTTPS
ServersMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comCitrix Systems, Inc.USAdwing-ietf@fuggles.comSandelman 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 local
networks. This provides benefits such as low latency to reach that DNS
server (owing 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, any available
local DNS server cannot serve DNS requests from local endpoints. If
public DNS servers are used instead of using local DNS servers, some
operational problems can occur such as those 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
service-specific 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 .If public DNS servers are used instead of using local DNS servers,
the following discusses the impact on network-based security:Various network security services are provided by Enterprise
networks to protect endpoints (e.g,. Hosts, IoT devices).
Network-based security solutions such as Firewalls (FW) and
Intrusion Prevention Systems (IPS) rely on network traffic
inspection to implement perimeter-based security policies. The
network security services may for example prevent malware download,
block known malicious URLs, enforce use of strong ciphers, stop data
exfiltration, etc. These network security services act on DNS
requests originating 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 on DNS requests from these 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 may 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 an endpoint has
enabled strict privacy profile (Section 5 of ), and the network security service blocks
the traffic to the public DNS server, the DNS service won't be
available to the endpoint and ultimately the endpoint cannot access
Internet-reachable services.If an 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, for
example, 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 (ACL) rules
based on domain names (Section 8 of ).If the network security service successfully 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 malicious servers.In addition, the local network's DNS server is advertised using
DHCP/RA which is insecure and also provides no mechanism to securely
authenticate the DNS server. To overcome the above threats, this
document specifies a mechanism to automatically bootstrap endpoints to
discover and authenticate the DNS-over-(D)TLS and DNS-over-HTTPS servers
provided by their local network. The overall procedure can be structured
into the following steps:Bootstrapping is
necessary only when connecting to a new network or when the
network's DNS certificate has changed. Bootstrapping authenticates
the Enrollment over Secure Transport (EST) server to the endpoint. After
authenticating the EST server, DNS server certificate used by the
local network is downloaded to the endpoint. This DNS server
certificate enables subsequent authenticated encrypted communication
with the local DNS server (e.g., DNS-over-HTTPS) during in the
connection phase.Discovery is performed by a
previously bootstrapped endpoint whenever connecting to a network.
During discovery, the endpoint is instructed which privacy-enabling
DNS protocol(s), port number(s), and IP addresses are supported on a
local network. This effectively takes the place of DNS server IP
address traditionally provided by IPv4 or IPv6 DHCP or by IPv6 Router Advertisement.Connection handshake and service
invocation: The DNS client initiates a (D)TLS handshake with
the DNS server learned in the discovery phase, and validates the DNS
server's identity using the credentials obtained in the
bootstrapping phase.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 problems discussed in will be
encountered in Enterprise networks. Typically Enterprise networks do not
assume that all devices in their network are managed by the IT team or
Mobile Device Management (MDM) devices, especially in the quite common
BYOD ("Bring Your Own Device") scenario. The mechanisms specified in
this document can be used by BYOD devices to discover and authenticate
DNS-over-(D)TLS and DNS-over-HTTPS servers provided by the Enterprise
network. This mechanism can also be used by IoT devices (managed by IT
team) after onboarding to discover and authenticate DNS-over-(D)TLS and
DNS-over-HTTPS servers provided by the Enterprise network.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 detail the mechanism to automatically bootstrap
an endpoint with the local network's DNS server certificate: The endpoint authenticates to the local network and discovers the
Enrollment over Secure Transport (EST) server using the procedure discussed in
.The endpoint establishes provisional TLS connection with that EST
server, i.e., the endpoint provisionally accepts the unverified TLS
server certificate. However, the endpoint MUST authenticate the EST
server before it accepts the DNS server certificate. The endpoint
either uses password-based authenticated key exchange (PAKE) with
TLS 1.3 as an
authentication method or uses the mutual authentication protocol for
HTTP to authenticate the discovered
EST server. As a reminder, PAKE is an
authentication method that allows the use of usernames and passwords
over unencrypted channels without revealing the passwords to an
eavesdropper. Similarly, the mutual authentication for HTTP is based
on PAKE and provides mutual authentication between an HTTP client
and an HTTP server using username and password as credentials. The
cryptographic algorithms to use with the mutual authentication
protocol for HTTP are defined in .The endpoint needs to use PAKE scheme to perform authentication
the first time it connects to an EST server. If the EST server
authentication is successful, the server's identity can be used to
authenticate subsequent TLS connections to that EST server. The
endpoint configures the reference identifier for the EST server
using the DNS-ID identifier type in the EST server certificate. On
subsequent connections to the EST server, the endpoint MUST validate
the EST server certificate using the Implict Trust Anchor database
(i.e, the EST server certificate must pass PKIX certification path
validation) and match the reference identifier against the EST
server's identity according to the rules specified in Section 6.4 of
.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. As a reminder, the End-Entity
certificates must be validated by the endpoint using an authorized
trust anchor (Section 3.2 of ). The
endpoint needs to identify the certificate provisioned to the DNS
server. The SRV-ID identifier type
within subjectAltName entry MUST 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". The SRV service label "domain-s" is defined in
Section 6 of . As a reminder, the
protocol component is not included in the SRV-ID .The endpoint configures the authentication domain name (ADN)
(defined in ) for the DNS server from
the DNS-ID identifier type within subjectAltName entry in the DNS
server certificate. The DNS server certificate is associated with
the ADN to be matched with the certificate given by the DNS server
in (D)TLS. To some extent, this approach is similar to certificate
usage PKIX-EE(1) defined in . illustrates a sequence diagram for
bootstrapping an endpoint with the local network's DNS server
certificate.The following steps explain the mechanism to automatically bootstrap
IoT devices with local network's CA certificates and DNS server
certificate: 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 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 an End-Entity
certificate. The IoT device needs to identify the certificate
provisioned to the DNS server. The SRV-ID identifier type within
subjectAltName entry MUST be used to identify the DNS server
certificate.The endpoint configures the ADN for the DNS server from the
DNS-ID identifier type within subjectAltName entry in the DNS
server certificate. The DNS server certificate is associated
with the ADN to be matched with the certificate given by the DNS
server in (D)TLS.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
DNS-based Service Discovery (DNS-SD) .
DNS-SD provides generic solution for discovering services available in a
local network. DNS-SD defines a set of naming rules for certain DNS
record types that they use for advertising and discovering services.
Section 4.1 of specifies that a service
instance name in DNS-SD has the following structure:The <Domain> portion specifies the authentication domain name.
The <Service> portion of the DNS service instance name MUST be
"_dprive._udp" or "_dprive._tcp" or "_doh._tcp". If no DNS-SD 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.). If no DNS-SD records can be
retrieved, the client can try connecting to the pre-configured public
DNS servers. If the endpoint has enabled strict privacy profile and
access to the pre-configured public DNS servers is blocked, the DNS
service won't be available to the endpoint and ultimately the endpoint
cannot access Internet-reachable services. If the endpoint has enabled
opportunistic privacy profile and access to the pre-configured public
DNS servers is blocked, 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.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 the
mechanism specified in to use
the https URI scheme (Section 3 of ).The DNS client initiates (D)TLS handshake with the DNS server, the
DNS server presents its certificate in ServerHello message, and the DNS
client MUST match the DNS server certificate downloaded in Step 4 in
or with the certificate provided by the DNS
server in (D)TLS handshake. If the match is successful, the DNS client
MUST validate the server certificate using the Implicit Trust Anchor
database (i.e., the DNS server certificate must pass PKIX certification
path validation).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.A EST client discovers the EST server in the local network by using
DNS-based Service Discovery (DNS-SD) or
Multicast DNS (mDNS) . The <Domain>
portion specifies the DNS sub-domain where the service instance is
registered. It may be "local.", indicating the mDNS local domain, or it
may be a conventional domain name such as "example.com.". The
<Service> portion of the EST service instance name MUST be
"_est._tcp".A EST client application can proactively discover an EST server
being advertised in the site by multicasting a PTR query to the
following:"_est._tcp.local"A EST server can send out gratuitous multicast DNS answer
packets whenever it starts up, wakes from sleep, or detects a change
in EST server configuration. EST client application can receive these
gratuitous packets and cache information contained in them.On subsequent attachments to the network, the endpoint discovers the
privacy-enabling DNS server using the authentication domain name
(configured in Step 5 of or
), initiates (D)TLS handshake with
the DNS server and follows the mechanism discussed in to validate the DNS server certificate.If the DNS server certificate is invalid (e.g., revoked or expired)
or the procedure to discover the privacy-enabling DNS server fails (e.g.
the domain name of the privacy-enabling DNS server has changed because
the Enterprise network has switched to a public privacy-enabling DNS
server capable of blocking access to malicious domains), the endpoint
discovers and initiates TLS handshake with the EST server, and uses the
validation techniques described in to
compare the reference identifier (created in Step 2 of in this document) to the EST server
certificate and verifies the entire certification path as per . The endpoint then gets the DNS server
certificate from the EST server. If the DNS-ID identifier type within
subjectAltName entry in the DNS server certificate does not match the
configured ADN, the ADN is replaced with the DNS-ID identifier type. The
DNS server certificate associated with the ADN is replaced with the one
provided by the EST server. If the ADN has changed, the endpoint
discovers the privacy-enabling DNS server, initiates (D)TLS handshake
with the DNS server and follows the mechanism discussed in to validate the DNS server certificate. illustrates a sequence diagram for
re-configuring an endpoint with ADN and local network's DNS server
certificate on subsequent attachments to the network. discusses DNS privacy considerations
in both "on the wire" (Section 2.4 of )
and "in the server" (Section 2.5 of
contexts. The mechanism defined in
[I-D.reddy-dprive-dprive-privacy-policy] can be used by the client to
discover the privacy policy information of the DNS server.The bootstrapping procedure to obtain the certificate of the local
networks DNS server uses a client identity and password to authenticate
the EST server using PAKE schemes. Security considerations such as those
discussed in or and need to be
taken into consideration.Users cannot be expected to enable or disable the bootstrapping or
the discovery procedure as they switch networks. Thus, it is RECOMMENDED
that users indicate to their system in some way that they desire
bootstrapping to be performed when connecting to a specific network,
similar to the way users disable VPN connection in specific network
(e.g., Enterprise network) and enable VPN connection by default in other
networks.If an 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. Impersonation of the DNS
server is prevented by validating the certificate presented by the DNS
server. If the EST server conveys the DNS server certificate, but the
DNS-SD 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 need to be taken
into consideration for IoT devices.IANA is requested to allocate the SRV service name of "dprive" for
DNS-over-TLS or DNS-over-DTLS, and the service name of "doh" for
DNS-over-HTTPS.IANA is requested to allocate the SRV service name of "est".Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick
McManus, Bob Harold, Livingood Jason, Winfield Alister, Eliot Lear and
Sara Dickinson for the discussion and comments.End-User Mapping: Next Generation Request Routing for Content
Delivery