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). discusses some of the
network-based security service use cases. 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 efficiently 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.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.This specification defines "DPRIVE" as the application service tag
() and "dns.tls" (), "dns.dtls" (),
and "dns.https" () as application
protocol tags. 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 makes an S-NAPTR
lookup with the authentication domain name and the 'DPRIVE'
application service tag 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.
The S-NAPTR lookup is performed using an recursive DNS resolver
discovered from an untrusted source (such as DHCP).In the example depicted in , 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 ).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
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.DNS-based Service Discovery (DNS-SD)
and Multicast DNS (mDNS) provide generic
solutions for discovering services available in a local network.
DNS-SD/mDNS define 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:<Instance> . <Service> . <Domain>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 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.Like all X.509 certificate extensions, the privacy certificate
extension is defined using ASN.1 . The
non-critical privacy extension is identified by id-pe-privacy.A non-null privacy always includes a base privacy. The privacy
extension includes the following information:If the client IP address is Personally Identifiable Information
(PII) data or non PII-data.If the user identity that sent the DNS query is logged or not,
and if user identity address is indeed logged, the period for
which the user identity is logged. User identity such as username,
IP address, MAC address or personally identifiable data. Logging
duration is represented in hours. A negative one (-1) of logging
duration indicates indefinite duration.If the transaction data (e.g., DNS messages) is logged or not,
and if transaction data is logged, the period for which the
transaction data is stored.If the transaction data is logged to notify the user access to
certain domains (e.g., malicious domains) is blocked, the period
for which the transaction data is stored. If access to malicious
domains is logged, the period for which the transaction data is
stored. If the transaction data is logged for analytics (e.g. to
detect malicious domains), the period for which the transaction
data is stored.If the transaction data is shared with partners or not, and if
the transaction data is shared with partners, the names of the
partners. If anonymized data or client identifiable data is shared
with partners.If the transaction data is shared or sold to third parties.If the DNS server will block DNS resolution of certain domains
(e.g., malicious domains).A URL that points to the privacy preserving data policy, and a
URL that points to the security assessment report of the DNS
server by a third party auditor.The syntax for the privacy extension is as follows: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
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 need to be taken
into consideration for IoT devices.IANA is requested to allocate the SRV service name of "est".IANA is requested to add the following entry in the "SMI Security for
PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry:IANA is requested to add the following entry in the "SMI Security for
PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry: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, 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
DeliveryInternational Telephone and Telegraph Consultative Committee,
"Specification of Abstract Syntax Notation One (ASN.1)", CCITT
Recommendation X.208, 1988.