< draft-reddy-dprive-bootstrap-dns-server-03.txt   draft-reddy-dprive-bootstrap-dns-server-04.txt >
DPRIVE WG T. Reddy DPRIVE WG T. Reddy
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: November 8, 2019 Citrix Expires: December 16, 2019 Citrix
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
M. Boucadair M. Boucadair
Orange Orange
May 7, 2019 June 14, 2019
A Bootstrapping Procedure to Discover and Authenticate DNS-over-(D)TLS A Bootstrapping Procedure to Discover and Authenticate DNS-over-(D)TLS
and DNS-over-HTTPS Servers and DNS-over-HTTPS Servers
draft-reddy-dprive-bootstrap-dns-server-03 draft-reddy-dprive-bootstrap-dns-server-04
Abstract Abstract
This document specifies mechanisms to automatically bootstrap This document specifies mechanisms to automatically bootstrap
endpoints (e.g., hosts, Customer Equipment) to discover and endpoints (e.g., hosts, Customer Equipment) to discover and
authenticate DNS-over-(D)TLS and DNS-over-HTTPS servers provided by a authenticate DNS-over-(D)TLS and DNS-over-HTTPS servers provided by a
local network. local network.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2019. This Internet-Draft will expire on December 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Bootstrapping Endpoint Devices . . . . . . . . . . . . . . . 5 4. Bootstrapping Endpoint Devices . . . . . . . . . . . . . . . 5
5. Bootstrapping IoT Devices . . . . . . . . . . . . . . . . . . 7 5. Bootstrapping IoT Devices . . . . . . . . . . . . . . . . . . 7
6. DNS-over-(D)TLS and DNS-over-HTTPS Server Discovery Procedure 8 6. DNS-over-(D)TLS and DNS-over-HTTPS Server Discovery Procedure 8
7. Connection Handshake and Service Invocation . . . . . . . . . 10 7. Connection Handshake and Service Invocation . . . . . . . . . 10
8. EST Service Discovery Procedure . . . . . . . . . . . . . . . 10 8. EST Service Discovery Procedure . . . . . . . . . . . . . . . 10
8.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Network Reattachment . . . . . . . . . . . . . . . . . . . . 11 9. Network Reattachment . . . . . . . . . . . . . . . . . . . . 11
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. Privacy Extension Format . . . . . . . . . . . . . . . . 12 10.1. Privacy Extension Format . . . . . . . . . . . . . . . . 12
10.2. Privacy Extension Syntax . . . . . . . . . . . . . . . . 13 10.2. Privacy Extension Syntax . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12.1. Application Service & Application Protocol Tags . . . . 16 12.1. Application Service & Application Protocol Tags . . . . 16
12.1.1. DNS Application Service Tag Registration . . . . . . 16 12.1.1. DNS Application Service Tag Registration . . . . . . 17
12.1.2. dns.tls Application Protocol Tag Registration . . . 16 12.1.2. dns.tls Application Protocol Tag Registration . . . 17
12.1.3. dns.dtls Application Protocol Tag Registration . . . 16 12.1.3. dns.dtls Application Protocol Tag Registration . . . 17
12.1.4. dns.https Application Protocol Tag Registration . . 17 12.1.4. dns.https Application Protocol Tag Registration . . 17
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Traditionally a caching DNS server has been provided by local Traditionally a caching DNS server has been provided by local
networks. This provides benefits such as low latency to reach that networks. This provides benefits such as low latency to reach that
DNS server (owing to its network proximity to the endpoint). DNS server (owing to its network proximity to the endpoint).
However, if an endpoint is configured to use Internet-hosted or However, if an endpoint is configured to use Internet-hosted or
public DNS-over-(D)TLS [RFC7858] [RFC8094] or DNS-over-HTTPS public DNS-over-(D)TLS [RFC7858] [RFC8094] or DNS-over-HTTPS
[RFC8484] servers, any available local DNS server cannot serve DNS [RFC8484] servers, any available local DNS server cannot serve DNS
requests from local endpoints. If public DNS servers are used requests from local endpoints. If public DNS servers are used
skipping to change at page 4, line 14 skipping to change at page 4, line 14
o If the endpoint is an IoT device which is configured to use public o 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 DNS-over-(D)TLS or DNS-over-HTTPS servers, and if a policy
enforcement point in the local network is programmed using, for enforcement point in the local network is programmed using, for
example, a Manufacturer Usage Description (MUD) file [RFC8520] by example, a Manufacturer Usage Description (MUD) file [RFC8520] by
a MUD manager to only allow intented communications to and from a MUD manager to only allow intented communications to and from
the IoT device, the policy enforcement point cannot enforce the the IoT device, the policy enforcement point cannot enforce the
network Access Control List (ACL) rules based on domain names network Access Control List (ACL) rules based on domain names
(Section 8 of [RFC8520]). (Section 8 of [RFC8520]).
If the network security service sucessfully blocks DNS-over-(D)TLS If the network security service successfully blocks DNS-over-(D)TLS
and DNS-over-HTTPS traffic, this can still compromise the endpoint and DNS-over-HTTPS traffic, this can still compromise the endpoint
security and privacy; some of the potential security threats are security and privacy; some of the potential security threats are
listed below: listed below:
o Pervasive monitoring of DNS traffic. o Pervasive monitoring of DNS traffic.
o An internal attacker can modify the DNS responses to re-direct the o An internal attacker can modify the DNS responses to re-direct the
client to malicious servers. client to malicious servers.
To overcome the above threats, this document specifies a mechanism to To overcome the above threats, this document specifies a mechanism to
skipping to change at page 6, line 9 skipping to change at page 6, line 9
server, i.e., the endpoint provisionally accepts the unverified server, i.e., the endpoint provisionally accepts the unverified
TLS server certificate. However, the endpoint MUST authenticate TLS server certificate. However, the endpoint MUST authenticate
the EST server before it accepts the DNS server certificate. The the EST server before it accepts the DNS server certificate. The
endpoint either uses password-based authenticated key exchange endpoint either uses password-based authenticated key exchange
(PAKE) with TLS 1.3 [I-D.barnes-tls-pake] as an authentication (PAKE) with TLS 1.3 [I-D.barnes-tls-pake] as an authentication
method or uses the mutual authentication protocol for HTTP method or uses the mutual authentication protocol for HTTP
[RFC8120] to authenticate the discovered EST server. [RFC8120] to authenticate the discovered EST server.
As a reminder, PAKE is an authentication method that allows the As a reminder, PAKE is an authentication method that allows the
use of usernames and passwords over unencrypted channels without use of usernames and passwords over unencrypted channels without
revealing the passwords to an eavesdropper. Similarty, the revealing the passwords to an eavesdropper. Similarly, the
mutual authentication for HTTP is based on PAKE and provides mutual authentication for HTTP is based on PAKE and provides
mutual authentication between an HTTP client and an HTTP server mutual authentication between an HTTP client and an HTTP server
using username and password as credentials. The cryptographic using username and password as credentials. The cryptographic
algorithms to use with the mutual authentication protocol for algorithms to use with the mutual authentication protocol for
HTTP are defined in [RFC8121]. HTTP are defined in [RFC8121].
3. The endpoint needs to use PAKE scheme to perform authentication 3. The endpoint needs to use PAKE scheme to perform authentication
the first time it connects to an EST server. If the EST server the first time it connects to an EST server. If the EST server
authentication is successful, the server's identity can be used authentication is successful, the server's identity can be used
to authenticate subsequent TLS connections to that EST server. to authenticate subsequent TLS connections to that EST server.
The endpoint configures the reference identifier for the EST The endpoint configures the reference identifier for the EST
server using the DNS-ID identifier type in the EST server server using the DNS-ID identifier type in the EST server
certificate. On subsequent connections to the EST server, the certificate. On subsequent connections to the EST server, the
endpoint MUST validate the EST server certificate using the endpoint MUST validate the EST server certificate using the
Implict Trust Anchor database (i.e, the EST server certificate Implict Trust Anchor database (i.e, the EST server certificate
must pass PKIX certification path validation) and matches the must pass PKIX certification path validation) and match the
reference identifier against the EST server's identity according reference identifier against the EST server's identity according
to the rules specified in Section 6.4 of [RFC6125]. to the rules specified in Section 6.4 of [RFC6125].
4. The endpoint learns the End-Entity certificates [RFC8295] from 4. The endpoint learns the End-Entity certificates [RFC8295] from
the EST server. The certificate provisioned to the DNS server in the EST server. The certificate provisioned to the DNS server in
the local network will be treated as a End-Entity certificate. the local network will be treated as a End-Entity certificate.
As a reminder, the End-Entity certificates must be validated by As a reminder, the End-Entity certificates must be validated by
the endpoint using an authorized trust anchor (Section 3.2 of the endpoint using an authorized trust anchor (Section 3.2 of
[RFC8295]). The endpoint needs to identify the certificate [RFC8295]). The endpoint needs to identify the certificate
provisioned to the DNS server. The SRV-ID identifier type provisioned to the DNS server. The SRV-ID identifier type
skipping to change at page 10, line 45 skipping to change at page 10, line 45
<Instance> . <Service> . <Domain> <Instance> . <Service> . <Domain>
The <Domain> portion specifies the DNS sub-domain where the service The <Domain> portion specifies the DNS sub-domain where the service
instance is registered. It may be "local.", indicating the mDNS instance is registered. It may be "local.", indicating the mDNS
local domain, or it may be a conventional domain name such as local domain, or it may be a conventional domain name such as
"example.com.". The <Service> portion of the EST service instance "example.com.". The <Service> portion of the EST service instance
name MUST be "_est._tcp". name MUST be "_est._tcp".
8.1. mDNS 8.1. mDNS
A EST client application can proactively discover EST server being A EST client application can proactively discover an EST server being
advertised in the site by multicasting a PTR query to the following: advertised in the site by multicasting a PTR query to the following:
o "_est._tcp.local" o "_est._tcp.local"
A EST server can send out gratuitous multicast DNS answer packets A EST server can send out gratuitous multicast DNS answer packets
whenever it starts up, wakes from sleep, or detects a change in EST whenever it starts up, wakes from sleep, or detects a change in EST
server configuration. EST client application receive these server configuration. EST client application can receive these
gratuitous packets and cache information contained in it. gratuitous packets and cache information contained in them.
9. Network Reattachment 9. Network Reattachment
On subsequent attachments to the network, the endpoint discovers the On subsequent attachments to the network, the endpoint discovers the
privacy-enabling DNS server using the authentication domain name privacy-enabling DNS server using the authentication domain name
(configured in Step 5 of Section 4 or Section 5), initiates (D)TLS (configured in Step 5 of Section 4 or Section 5), initiates (D)TLS
handshake with the DNS server and follows the mechanism discussed in handshake with the DNS server and follows the mechanism discussed in
Section 7 to validate the DNS server certificate. Section 7 to validate the DNS server certificate.
If the DNS server certificate invalid (e.g., revoked or expired) or If the DNS server certificate is invalid (e.g., revoked or expired)
the procedure to discover the privacy-enabling DNS server fails (e.g. or the procedure to discover the privacy-enabling DNS server fails
the domain name of the privacy-enabling DNS server has changed (e.g. the domain name of the privacy-enabling DNS server has changed
because the Enterprise network has switched to a public privacy- because the Enterprise network has switched to a public privacy-
enabling DNS server capable of blocking access to malicious domains), enabling DNS server capable of blocking access to malicious domains),
the endpoint discovers and initiates TLS handshake with the EST the endpoint discovers and initiates TLS handshake with the EST
server, and uses the validation techniques described in [RFC6125] to server, and uses the validation techniques described in [RFC6125] to
compare the reference identifier (created in Step 2 of Section 4 in compare the reference identifier (created in Step 2 of Section 4 in
this document) to the EST server certificate and verifies the entire this document) to the EST server certificate and verifies the entire
certification path as per [RFC5280]. The endpoint then gets the DNS certification path as per [RFC5280]. The endpoint then gets the DNS
server certificate from the EST server. If the DNS-ID identifier server certificate from the EST server. If the DNS-ID identifier
type within subjectAltName entry in the DNS server certificate does type within subjectAltName entry in the DNS server certificate does
not match the configured ADN, the ADN is replaced with the DNS-ID not match the configured ADN, the ADN is replaced with the DNS-ID
skipping to change at page 13, line 25 skipping to change at page 13, line 25
PKIX modules PKIX modules
id-mod-privacy-extn OBJECT IDENTIFIER ::= { id-mod TBD2 } id-mod-privacy-extn OBJECT IDENTIFIER ::= { id-mod TBD2 }
id-pe-privacy OBJECT IDENTIFIER ::= { id-pe TBD1 } id-pe-privacy OBJECT IDENTIFIER ::= { id-pe TBD1 }
A non-null privacy always includes a base privacy. The privacy A non-null privacy always includes a base privacy. The privacy
extension includes the following information: extension includes the following information:
o If the client IP address is Personally Identifiable Information o If the client IP address is Personally Identifiable Information
(PII) data or non PII-data. (PII) data or non PII-data.
o If the client IP address is logged or not, and if client IP o If the user identity that sent the DNS query is logged or not, and
address is indeed logged, it is stored in temporary or permanant if user identity address is indeed logged, the period for which
logs. 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.
o If the server clears the stored transaction data (e.g., DNS o If the transaction data (e.g., DNS messages) is logged or not, and
messages) or not, and if the server clears the stored transaction if transaction data is logged, the period for which the
data, the period for which the transaction data is stored. transaction data is stored.
o 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.
o If the transaction data is shared with partners or not, and if the o If the transaction data is shared with partners or not, and if the
transaction data is shared with partners, the names of the transaction data is shared with partners, the names of the
partners. If anonymized data or client identifiable data is partners. If anonymized data or client identifiable data is
shared with partners. shared with partners.
o If the transaction data is shared or sold to third parties. o If the transaction data is shared or sold to third parties.
o If the DNS server will block DNS resolution of certain domains o If the DNS server will block DNS resolution of certain domains
(e.g., malicious domains). (e.g., malicious domains).
skipping to change at page 14, line 17 skipping to change at page 14, line 25
-- No privacy policy provided -- No privacy policy provided
pPolicy PrivacyPolicy pPolicy PrivacyPolicy
-- Privacy preserving data policy } -- Privacy preserving data policy }
PrivacyPolicy ::= SEQUENCE { PrivacyPolicy ::= SEQUENCE {
base PrivacyInfo, base PrivacyInfo,
pURL [0] PrivacyURL OPTIONAL, pURL [0] PrivacyURL OPTIONAL,
aURL [1] AuditURL OPTIONAL } aURL [1] AuditURL OPTIONAL }
PrivacyInfo ::= SEQUENCE { PrivacyInfo ::= SEQUENCE {
ipaddresspii BOOLEAN, ipaddresspii BOOLEAN,
-- TRUE means client IP address is PII -- TRUE means client IP address is PII
log [0] Logging, log [0] Logging,
retention [1] DataRetention, sdata [2] ShareData,
sdata [2] ShareData, transferdata [3] BOOLEAN,
transferdata [3] BOOLEAN, -- TRUE means share or sell data to third parties
-- TRUE means share or sell data to third parties blockdomains [4] BOOLEAN
blockdomains [4] BOOLEAN -- TRUE means domains will be blocked }
-- TRUE means domains will be blocked }
Logging ::= SEQUENCE { LoggingTypes ::= BIT STRING {
logip BOOLEAN, none (0),
-- TRUE means client IP address logging -- No logging
temporary BOOLEAN OPTIONAL all (1),
-- TRUE means temporary logs } -- Log all transaction data
useridentity (2),
-- Log user identity (e.g., username, IP address)
notifyuser (3),
-- Log to notify user access
-- to certain domains is blocked
knownmalware (4),
-- Log access to malicious domains
analytics (5)
-- Log transaction data for analytics
-- (e.g. to detect malicious domains) }
DataRetention ::= SEQUENCE { LoggingDuration ::= SEQUENCE {
cleardata BOOLEAN, all [0] INTEGER OPTIONAL,
-- TRUE means the server clears
-- the stored transaction data
period INTEGER OPTIONAL
-- Number of Hours the -- Number of Hours the
-- transaction data is stored } -- transcation data is stored
useridentity [1] INTEGER OPTIONAL,
notifyuser [2] INTEGER OPTIONAL,
knownmalware [3] INTEGER OPTIONAL,
analytics [4] INTEGER OPTIONAL }
Logging ::= SEQUENCE {
loggingTypes LoggingTypes DEFAULT {none},
loggingDuration LoggingDuration OPTIONAL
-- Transaction data is cleared
-- after logging duration,
-- Negative one (-1) indicates indefinite
-- duration }
ShareData ::= SEQUENCE { ShareData ::= SEQUENCE {
sharepartners BOOLEAN, sharepartners BOOLEAN,
-- TRUE means data is shared with partners -- TRUE means data is shared with partners
partners [1] SEQUENCE SIZE (1..MAX) OF UTF8String OPTIONAL, partners [1] SEQUENCE SIZE (1..MAX) OF UTF8String OPTIONAL,
-- Names of the partners -- Names of the partners
anonymizeddata [0] BOOLEAN OPTIONAL anonymizeddata [0] BOOLEAN OPTIONAL
-- TRUE means anonymized data -- TRUE means anonymized data
-- is shared with partners } -- is shared with partners }
skipping to change at page 17, line 18 skipping to change at page 17, line 48
o Intended Usage: See Section 6 o Intended Usage: See Section 6
o Security Considerations: See Section 11 o Security Considerations: See Section 11
o Contact Information: <one of the authors> o Contact Information: <one of the authors>
13. Acknowledgments 13. Acknowledgments
Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick
McManus, Eliot Lear and Sara Dickinson for the discussion and McManus, Bob Harold, Livingood Jason, Winfield Alister, Eliot Lear
comments. and Sara Dickinson for the discussion and comments.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-doh-resolver-associated-doh] [I-D.ietf-doh-resolver-associated-doh]
Hoffman, P., "Associating a DoH Server with a Resolver", Hoffman, P., "Associating a DoH Server with a Resolver",
draft-ietf-doh-resolver-associated-doh-03 (work in draft-ietf-doh-resolver-associated-doh-03 (work in
progress), March 2019. progress), March 2019.
skipping to change at page 19, line 41 skipping to change at page 20, line 23
[I-D.camwinget-tls-use-cases] [I-D.camwinget-tls-use-cases]
Andreasen, F., Cam-Winget, N., and E. Wang, "TLS 1.3 Andreasen, F., Cam-Winget, N., and E. Wang, "TLS 1.3
Impact on Network-Based Security", draft-camwinget-tls- Impact on Network-Based Security", draft-camwinget-tls-
use-cases-04 (work in progress), March 2019. use-cases-04 (work in progress), March 2019.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-19 (work in progress), March 2019. keyinfra-21 (work in progress), June 2019.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
DOI 10.17487/RFC2775, February 2000, DOI 10.17487/RFC2775, February 2000,
<https://www.rfc-editor.org/info/rfc2775>. <https://www.rfc-editor.org/info/rfc2775>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, DOI 10.17487/RFC7626, August 2015,
<https://www.rfc-editor.org/info/rfc7626>. <https://www.rfc-editor.org/info/rfc7626>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
 End of changes. 23 change blocks. 
50 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/