[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

ADD                                                             T. Reddy
Internet-Draft                                                    McAfee
Intended status: Informational                                   D. Wing
Expires: December 25, 2020                                        Citrix
                                                           June 23, 2020

  DNS-over-HTTPS and DNS-over-TLS Server Deployment Considerations for
                          Enterprise Networks


   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

Reddy & Wing            Expires December 25, 2020               [Page 1]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

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

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)

   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.

Reddy & Wing            Expires December 25, 2020               [Page 2]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

   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]:

   o  If an endpoint has enabled strict privacy profile (Section 5 of
      [RFC8310]), the endpoint cannot resolve DNS names.

   o  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

   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

   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].

Reddy & Wing            Expires December 25, 2020               [Page 3]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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

   '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

   o  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].

   o  [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]).

Reddy & Wing            Expires December 25, 2020               [Page 4]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

   o  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.

   o  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).

   o  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.

   o  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.

   o  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

Reddy & Wing            Expires December 25, 2020               [Page 5]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

      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:

   o  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.

   o  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.

   o  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

Reddy & Wing            Expires December 25, 2020               [Page 6]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

      closed OS like Windows 10 in S mode [win10s] or Chromebook
      [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.

Reddy & Wing            Expires December 25, 2020               [Page 7]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

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

   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

   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.

Reddy & Wing            Expires December 25, 2020               [Page 8]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

11.  References

11.1.  Normative References

              Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair,
              "A Bootstrapping Procedure to Discover and Authenticate
              DNS-over-TLS and DNS-over-HTTPS Servers for IoT and BYOD
              Devices", draft-reddy-add-iot-byod-bootstrap-00 (work in
              progress), May 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8310]  Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
              for DNS over TLS and DNS over DTLS", RFC 8310,
              DOI 10.17487/RFC8310, March 2018,

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,

11.2.  Informative References

              The Unicode Consortium, "Chrome DNS over HTTPS (aka DoH)",

              The Unicode Consortium, "Chrome policies for users or
              browsers", <https://support.google.com/chrome/a/

Reddy & Wing            Expires December 25, 2020               [Page 9]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

              Microsoft, "Chromebook security",

   [dpp]      Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol
              (DPP)", Wi-Fi Alliance , 2018, <https://www.wi-

              "Policy templates for Firefox",

              "Trusted Recursive Resolver",

              Arkko, J. and S. Farrell, "Challenges and Changes in the
              Internet Threat Model", draft-arkko-farrell-arch-model-
              t-03 (work in progress), March 2020.

              Boucadair, M., Reddy.K, T., Wing, D., and N. Cook,
              "Encrypted DNS Discovery and Deployment Considerations for
              Home Networks", draft-btw-add-home-06 (work in progress),
              May 2020.

              Boucadair, M., Reddy.K, T., Wing, D., and V. Smyslov,
              "Internet Key Exchange Protocol Version 2 (IKEv2)
              Configuration for Encrypted DNS", draft-btw-add-ipsecme-
              ike-00 (work in progress), April 2020.

              Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-41 (work in progress), April 2020.

              Hoffman, P., "Terminology for DNS Transports and
              Location", draft-ietf-dnsop-terminology-ter-01 (work in
              progress), February 2020.

Reddy & Wing            Expires December 25, 2020              [Page 10]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

              Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS
              Privacy Requirements for Exchanges between Recursive
              Resolvers and Authoritative Servers", draft-ietf-dprive-
              phase2-requirements-01 (work in progress), June 2020.

              Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
              Shao, "Discovering Provisioning Domain Names and Data",
              draft-ietf-intarea-provisioning-domains-11 (work in
              progress), January 2020.

              Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair,
              "DNS Server Selection: DNS Server Information with
              Assertion Token", draft-reddy-add-server-policy-
              selection-03 (work in progress), June 2020.

              Apple, "Mobile Device Management",

   [ocf]      Open Connectivity Foundation, "OCF Security
              Specification", Open Connectivitiy Foundation , June 2017,

   [oma]      Open Mobile Alliance, "Lightweight Machine to Machine
              Technical Specification: Core", Open Mobile Alliance ,
              June 2019,

   [OTA]      Apple, "Over-the-Air Profile Delivery Concepts", <https://

   [PEAP]     Microsoft, "[MS-PEAP]: Protected Extensible Authentication
              Protocol (PEAP)", <https://docs.microsoft.com/en-

Reddy & Wing            Expires December 25, 2020              [Page 11]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

   [PSK]      Cisco, "Identity PSK Feature Deployment Guide",

   [RFC4764]  Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
              Pre-Shared Key Extensible Authentication Protocol (EAP)
              Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,

   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
              "Tunnel Extensible Authentication Protocol (TEAP) Version
              1", RFC 7170, DOI 10.17487/RFC7170, May 2014,

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015,

   [RFC8146]  Harkins, D., "Adding Support for Salted Password Databases
              to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017,

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", RFC 8520,
              DOI 10.17487/RFC8520, March 2019,

   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
              Touch Provisioning (SZTP)", RFC 8572,
              DOI 10.17487/RFC8572, April 2019,

Reddy & Wing            Expires December 25, 2020              [Page 12]

Internet-Draft       DoH/DoT in Enterprise Networks            June 2020

   [RFC8598]  Pauly, T. and P. Wouters, "Split DNS Configuration for the
              Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 8598, DOI 10.17487/RFC8598, May 2019,

   [win10s]   Microsoft, "Windows 10 in S mode",

Authors' Addresses

   Tirumaleswar Reddy
   McAfee, Inc.
   Embassy Golf Link Business Park
   Bangalore, Karnataka  560071

   Email: kondtir@gmail.com

   Dan Wing
   Citrix Systems, Inc.

   Email: dwing-ietf@fuggles.com

Reddy & Wing            Expires December 25, 2020              [Page 13]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/