DNS-over-HTTPS and DNS-over-TLS Server Deployment Considerations for Enterprise Networks
draft-reddy-add-enterprise-00

Abstract

This document discusses DoH/DoT deployment considerations for Enterprise networks. It particularly sketches the required steps to use DNS-over-TLS (DoT) and/or DNS-over-HTTPS (DoH) server provided by the Enterprise network.

One of the goals of the document is to assess to what extent existing tools can be used to provide such service.

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 December 25, 2020.

Copyright Notice

Copyright (c) 2020 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. IT-owned devices
• 4. IoT Devices
• 5. BYOD
• 6. Roaming Enterprise Users
• 6.1. VPN tunnel
• 6.2. Client Authentication
• 7. Upstream Encryption
• 8. Security Considerations
• 9. IANA Considerations
• 10. Acknowledgements
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Authors' Addresses

1. Introduction

[RFC7626] discusses DNS privacy considerations in both "on the wire" (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of [RFC7626]) contexts. In recent years there has also been an increase in the availability of "public resolvers" [RFC8499] which DNS clients may be pre-configured to use instead of the default network resolver for a variety of reasons (e.g., offer a good reachability, support an encrypted transport, provide a strong privacy policy, (lack of) filtering).

If public (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484] servers are used instead of using local DNS servers, it can adversely impact Enterprise network-based security. Various network security services are provided by Enterprise networks to protect endpoints (e.g., laptops, printers, IoT devices), and to enforce enterprise policies. These policies may be necessary to protect employees, customers, or citizens. They are not the subject of this memo.

Enterprise DNS servers in place for these purpose act on DNS requests originating from endpoints. However, if an endpoint uses public DoT or DoH servers, the desired enterprise protection and enforcement can be bypassed.

In order to act on DNS requests from endpoints, network security services can block DoT traffic by dropping outgoing packets to destination port 853. Identifying DoH traffic is far more challenging than DoT traffic. Network security services may try to identify the well-known DoH resolvers by their domain name, and DNS-over-HTTPS traffic can be blocked by dropping outgoing packets to these domains. However, DoH traffic can not be fully identified without acting as a TLS proxy.

If a network security service blocks access to the public DoH/DoT server, there are incompatibilities with the privacy profiles discussed in [RFC8310]:

• If an endpoint has enabled strict privacy profile (Section 5 of [RFC8310]), the endpoint cannot resolve DNS names.
• If an endpoint has enabled opportunistic privacy profile (Section 5 of [RFC8310]), 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. The fallback adversely impacts security and privacy as internal attacks are possible in Enterprise networks. For example, an internal attacker can modify the DNS responses to re-direct the client to malicious servers or pervasively monitor the DNS traffic. The reader may refer to Section 3.2.1 of [I-D.arkko-farrell-arch-model-t] for a discussion on the need for more awareness about attacks from within closed domains.

To overcome the above threats, this document specifies mechanisms to configure endpoints to use Enterprise provided DoT and DoH servers, and bootstrap IoT devices and unmanaged endpoints to discover and authenticate the DoT and DoH servers provided by the Enterprise network.

A common usage pattern for an IoT device is for it to "call home" to a service that resides on the public Internet, where that service is referenced through a domain name (A or AAAA record). As discussed in Manufacturer Usage Description Specification [RFC8520], because these devices tend to require access to very few sites, all other access should be considered suspect. However, if the query is not accessible for inspection, it becomes quite difficult for the infrastructure to suspect anything.

This document focuses on DoH/DoT deployment considerations for Enterprise networks, DoH/DoT sever discovery and deployment considerations for home networks are discussed in [I-D.btw-add-home].

2. Terminology

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.

This document makes use of the terms defined in [RFC8499] and [I-D.ietf-dnsop-terminology-ter].

'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS.

3. IT-owned devices

If a device is managed by an enterprise's IT department, the device can be configured to use Enterprise-provided DoH/DoT servers. This configuration might be manual or rely upon whatever deployed device management tool in an Enterprise. For example, customizing Firefox using Group Policy to use the Enterprise DoH server is discussed in [Firefox-Policy] for Windows and MacOS, and setting Chrome policies is discussed in [Chrome-Policy] and [Chrome-DoH].

4. IoT Devices

The solution described in this document is aimed in general at non-constrained IoT devices (i.e., class 2+ [RFC7228]) operating on a Enterprise network without a device management tool and require agentless or standardized approaches. The basis for trust, therefore, is quite different from that of a laptop, tablet, or smart phone. The following bootstrapping mechanisms can be used to securely provision IoT devices to use Enterprise provided DoT and DoH servers:

• IoT devices supporting Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed in [I-D.ietf-anima-bootstrapping-keyinfra] can be bootstrapped with the Enterprise-provided DoH/DoT servers using the mechanism discussed in Section 5 of [I-D.reddy-add-iot-byod-bootstrap].
• [RFC8572] defines a bootstrapping strategy for enabling devices to securely obtain the required configuration information with no installer input. DHCP/RA [I-D.btw-add-home] can be used to discover the DoH/DoT information. If the insecurely discovered DoH/DoT information is not pre-configured in the IoT device, the client can validate the Policy Assertion Token signature (Section 7 [I-D.reddy-add-server-policy-selection]) using the owner certificate (Section 3.2 of [RFC8572]).
• When IoT devices connect to a network via EAP methods such as Tunnel Extensible Authentication Protocol (TEAP) [RFC7170], it would be possible to extend these methods to return additional configuration elements as part of completion of the authentication transaction. One simple approach would be after successful completion of the EAP method in Phase 2 for a TEAP server to return a new TLV that indicates the local DoH/DoT information.
• Not all of IoT devices support 802.1x supplicant and need an alternate mechanism to connect to the Enterprise network. To address this limitation, unique pre-shared keys are created for each IoT device and WPA-PSK is used [PSK]. In other words, WPA-PSK is used with unique pre-shared keys for different IoT devices to deal security issues.
  • The IoT device needs to be provisioned with a Pre-Shared Key (PSK) for mutual authentication. The PSK is only known to the IoT device and the WPA server. In this case, the bootstrapping mechanism discussed in Section 4 of [I-D.reddy-add-iot-byod-bootstrap] may be used to securely bootstrap IoT device with the authentication domain name (ADN) and DNS server certificate of the local network's DoH/ DoT server. It uses password-based authenticated key exchange (PAKE) scheme to authenticate the EST server and fetch the DoH/DoT server certificate. Note that provisioning massive number of IoT devices with PSK is not a scalable onboarding mechanism but will work in Small Office/Home Office (SOHO) and Small/Medium Enterprise (SME).
• If Device Provisioning Protocol (DPP) [dpp] is used, the configurator can securely configure IoT devices with the local DoH/DoT server by extending the content of the configuration elements provided by the configurator. Because DPP can provide a private shared key for use with WPA-PSK, it can be combined with the above methods.
• The OMA LWM2M specification [oma] defines an architecture where a new device (LWM2M client) contacts a Bootstrap-server which is responsible for "provisioning" essential bootstrap information. The current standard defines the following four bootstrapping modes (1) Factory Bootstrap (2) Bootstrap from Smartcard (3) Client Initiated Bootstrap (4) Server Initiated Bootstrap. The bootstrap information can be extended to include the local DoH/DoT server details.
• The Open Connectivitiy Foundation [ocf] defines the onboarding process before a device is operational. Once the onboarding tool and the new device have authenticated and established secure communication, the onboarding tool can provision the IoT device with the local DoH/DoT server.

This document does not discuss opportunistic or leap-of-faith bootstrapping methods, they are susceptible to security issues (e.g., IoT device can be configured with the attacker's DoH/DoT server or disable the use of DoH/DoT).

5. BYOD

The following mechanisms can be used to bootstrap BYOD (bring your own device) with the DoH/DoT server used by the Enterprise network:

• If mobile device management (MDM) [MDM-Apple] is used to secure BYOD, MDM can be used to configure OS/browser with the Enterprise provided DoH/DoT server.
• If an endpoint is on-boarded, for example, using Over-The-Air (OTA) enrollment [OTA] to provision the device with a certificate and configuration profile, the configuration profile can include the authentication domain name (ADN) of the DoH/DoT server. The OS/Browser can use the configuration profile to use the Enterprise provided DoH/DoT server. In this case, MDM is not installed on the device.
• If an endpoint uses the credentials (username and password) provided by the IT admin to mutually authenticate to the Enterprise WiFi Access Point (e.g., PEAP-MSCHAPv2 [PEAP], EAP-pwd [RFC8146], EAP-PSK [RFC4764]), the boostrapping mechanism discussed in Section 4 of [I-D.reddy-add-iot-byod-bootstrap] can be used to securely bootstrap the endpoint with the ADN and DNS server certificate of the local network's DoH/DoT server.
  
  The DNS client uses PAKE scheme to authenticate the EST server using the credentials to authenticate to the network. In this case, the endpoint is neither provisioned with a configuration profile or MDM is installed on the device. Many users have privacy and personal data sovereignty concerns with employers installing MDM on their personal devices; they are concerned that admin can glean personal information and could control how they use their devices. Yet when users do not install MDM on their devices, IT admins do not get visibility into the security posture of those devices.
  
  To overcome this problem, a host agent can cryptographically attest the security status associated with device, such as minimum passcode length, biometric login enabled, OS version etc. This approach is fast gaining traction especially with the advent of closed OS like Windows 10 in S mode or Chromebook, where applications are sandboxed (e.g., ransomware attack is not possbile) and applications can only be installed via the OS store.

When attached to the enterprise network yet needing to use the enterprise's DoH server only to access the internal-only DNS names, the client device can learn about domains for which the local network's resolver is authoritative via dnsZones key defined in Section 4.3 of [I-D.ietf-intarea-provisioning-domains] (as other DoH/DoT servers will be unaware of the internal-only DNS names).

6. Roaming Enterprise Users

6.1. VPN tunnel

In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming user connects to the Enterprise network through an VPN tunnel (e.g., IPsec, SSL, Wireguard). The split-tunnel Virtual Private Network (VPN) configuration allows the endpoint to access hosts that reside in the Enterprise network [RFC8598] using that tunnel; other traffic not destined to the Enterprise does not traverse the tunnel. In contrast, a non-split- tunnel VPN configuration causes all traffic to traverse the tunnel into the enterprise.

When the VPN tunnel is IPsec, The DoH/DoT server hosted by the Enterprise network can be securely discovered by the endpoint using the INTERNAL_ENC_DNS IKEv2 Configuration Payload Attribute Type defined in [I-D.btw-add-ipsecme-ike]. For split-tunnel VPN configurations, the endpoint uses the Enterprise-provided DoT/DoH server to resolve internal-only domain names. For non-split-tunnel VPN configurations, the endpoint uses the Enterprise-provided DoT/DoH server to resolve both internal and external domain names.

Other VPN tunnel types have similar configuration capabilities, not detailed here.

6.2. Client Authentication

When not on the local enterprise network (e.g., at home or coffee shop) yet needing to access the enterprise DoH/DoT server but not through a tunnel, roaming users can use client authentication to access the Enterprise provided DoH/DoT server. For example, Firefox DoH setting accepts user credentials [Firefox-TRR] to authenticate the client to access the DoH server. The exact client authentication mechanism to authenticate to the DoH/DoT server is outside the scope of this specification.

7. Upstream Encryption

If the Enterprise network is using the local DoH/DoT server configured as a Forwarding DNS server [RFC8499] relying on the upstream resolver (e.g., at an ISP) to perform recursive DNS lookups, DNS messages exchanged between the local DoH/DoT server and recursive resolver MUST be encrypted. If the Enterprise network is using the local DoH/DoT server configured as a recursive DNS server, DNS messages exchanges between the recursive resolver and authoritative servers SHOULD be encrypted to conform to the requirements discussed in [I-D.ietf-dprive-phase2-requirements].

8. Security Considerations

Security and privacy considerations in [I-D.reddy-add-iot-byod-bootstrap] need to be taken into consideration.

The mechanism defined in [I-D.reddy-add-server-policy-selection] can be used by the DNS server to communicate its privacy statement URL and filtering policy to a DNS client. This communication is cryptographically signed to attest to its authenticity.

The DNS client can validate the signatory (i.e., cryptographically attested by the Organization hosting the DoH/DoT server) and the user can review human-readable privacy policy information of the DNS server and assess whether the DNS server performs DNS-based content filtering.

If the discovered DoH/DoT server does not meet the privacy preserving data policy and filtering requirements of the user, the user can instruct the DNS client to take appropriate actions. For example, the action can be to use the local DNS server only to access internal-only DNS names and use another DNS server (adhering with his/her expectations) for public domains.

9. IANA Considerations

This document has no actions for IANA.

10. Acknowledgements

Thanks to Mohamed Boucadair, Sandeep Rao, Vinny Parla, Nancy Cam-Winget and Eliot Lear for the discussion and comments.

11. References

11.1. Normative References

11.2. Informative References

Authors' Addresses