-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathdraft-reddy-dprive-bootstrap-dns-server-06.xml
787 lines (663 loc) · 40 KB
/
draft-reddy-dprive-bootstrap-dns-server-06.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-dprive-bootstrap-dns-server-06"
ipr="trust200902">
<front>
<title abbrev="DoT/DoH server discovery">A Bootstrapping Procedure to
Discover and Authenticate DNS-over-(D)TLS and DNS-over-HTTPS
Servers</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="McAfee">McAfee, Inc.</organization>
<address>
<postal>
<street>Embassy Golf Link Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560071</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Citrix">Citrix Systems, Inc.</organization>
<address>
<postal>
<street></street>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Michael C. Richardson" initials="M."
surname="Richardson">
<organization>Sandelman Software Works</organization>
<address>
<postal>
<street></street>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="03" month="October" year="2019" />
<workgroup>DPRIVE WG</workgroup>
<abstract>
<t>This 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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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
<xref target="RFC7858"></xref> <xref target="RFC8094"></xref> or
DNS-over-HTTPS <xref target="RFC8484"></xref> 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:</t>
<t><list style="symbols">
<t>"Split DNS" <xref target="RFC2775"></xref> 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.</t>
<t>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 <xref
target="RFC7871"></xref> to the CDN's DNS authorities <xref
target="CDN"></xref>.</t>
</list></t>
<t>If public DNS servers are used instead of using local DNS servers,
the following discusses the impact on network-based security:</t>
<t><list style="symbols">
<t>Various network security services are provided by Enterprise
networks to protect endpoints (e.g,. Hosts, IoT devices).
Network-based security solutions such as Firewalls (FW) and
Intrusion Prevention Systems (IPS) rely on network traffic
inspection to implement perimeter-based security policies. The
network security services may for example prevent malware download,
block known malicious URLs, enforce use of strong ciphers, stop data
exfiltration, etc. These network security services act on DNS
requests originating from endpoints.</t>
<t>However, if an endpoint is configured to use public
DNS-over-(D)TLS or DNS-over-HTTPS servers, network security services
cannot act on DNS requests from these endpoints.</t>
<t>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 <xref
target="RFC8310"></xref>), 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.</t>
<t>If an endpoint has enabled opportunistic privacy profile (Section
5 of <xref target="RFC8310"></xref>), 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.</t>
</list></t>
<t>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:</t>
<t><list style="symbols">
<t>The network security service cannot prevent an endpoint from
accessing malicious domains.</t>
<t>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 <xref
target="RFC8520"></xref> 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 <xref
target="RFC8520"></xref>).</t>
</list></t>
<t>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:<list style="symbols">
<t>Pervasive monitoring of DNS traffic.</t>
<t>An internal attacker can modify the DNS responses to re-direct
the client to malicious servers.</t>
</list></t>
<t>In addition, the local network's DNS server is advertised using
DHCP/RA which is insecure and also provides no mechanism to securely
authenticate the DNS server. To overcome the above threats, this
document specifies a mechanism to automatically bootstrap endpoints to
discover and authenticate the DNS-over-(D)TLS and DNS-over-HTTPS servers
provided by their local network. The overall procedure can be structured
into the following steps:<list style="symbols">
<t><xref target="bootstrap-endpoint">Bootstrapping</xref> 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) <xref
target="RFC7030"></xref> 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.</t>
<t><xref target="discovery">Discovery</xref> 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 <xref
target="RFC8106">IPv6 Router Advertisement</xref>.</t>
<t><xref target="auth">Connection handshake and service
invocation</xref>: 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.</t>
</list></t>
<t>Note: The strict and opportunistic privacy profiles as defined in
<xref target="RFC8310"></xref> only applies to DNS-over-(D)TLS
protocols, there has been no such distinction made for DNS-over-HTTPS
protocol.</t>
</section>
<section anchor="scope" title="Scope">
<t>The problems discussed in <xref target="intro"></xref> 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.</t>
<t>WiFi as frequently deployed is vulnerable to various attacks (<xref
target="Evil-Twin"></xref>,<xref target="Krack"> </xref> and <xref
target="Dragonblood"></xref>). Because of these attacks, only
cryptographically authenticated communications are trusted on WiFi
networks. This means information provided by the network via DHCPv4,
DHCPv6, or RA (e.g., NTP server, DNS server, default domain) are
un-trusted because DHCP and RA are not authenticated.</t>
<t>The users have to indicate to their system in some way that they
desire bootstrapping to be performed only when connecting to a specific
network (e.g., organization for which a user works or a user works
temporarily within another corporation), 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 the
discovered DNS server meets the privacy preserving data policy
requirements of the user, the user can select to use the discovered
DNS-over-(D)TLS and DNS-over-HTTPS servers. In addition, if the
discovered DNS-over-(D)TLS and DNS-over-HTTPS servers are reachable on
the Internet, user can inform the system to use the servers in other
networks. It is strongly recommended to configure the DNS server to be
used in other networks provided the DNS server meets the privacy
preserving data policy requirements of the user and offers malware
filtering service. </t>
<t>If the device joins a public WiFi without any security credential
verification or joins a WiFi using a single shared password among all
the attached devices, such networks are typically not known to the user
or a compromised devices can spoof the access point or the attacker can
host a fake access point, and the device cannot be securely bootstrapped
with the network's DNS-over-HTTPS or DNS-over-TLS server. A compromised
device may, for example, expose to an attacker secrets (such as single
shared password) stored in the device. Such networks can also be
misconfigured or malicious. Further, the client cannot know if the
discovered DNS-over-HTTPS or DNS-over-(D)TLS server is hosted by the
network operator or by an attacker. In such networks, DNS-over-HTTPS and
DNS-over-(D)TLS server discovered using insecure discovery mechanisms
like DHCP can be used by the client if and only if the insecurely
discovered DNS-over-HTTPS and DNS-over-(D)TLS server is previously
securely discovered in a different network, offers malware filtering
service, meets the privacy preserving data policy requirements of the
user and configured to be used in other networks.</t>
</section>
<section anchor="notation" title="Terminology">
<t>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
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and
only when, they appear in all capitals, as shown here.</t>
<t>(D)TLS is used for statements that apply to both Transport Layer
Security <xref target="RFC8446"></xref> and Datagram Transport Layer
Security <xref target="RFC6347"></xref>. Specific terms are used for any
statement that applies to either protocol alone.</t>
<t>This document uses the terms defined in <xref
target="RFC8499"></xref>.</t>
</section>
<section anchor="bootstrap-endpoint"
title="Bootstrapping Endpoint Devices">
<t>The following steps detail the mechanism to automatically bootstrap
an endpoint with the local network's DNS server certificate: <list
style="numbers">
<t>The endpoint authenticates to the local network and discovers the
Enrollment over Secure Transport (EST) <xref
target="RFC7030"></xref> server using the procedure discussed in
<xref target="EST_Discovery"></xref>.</t>
<t>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 <xref target="I-D.barnes-tls-pake"></xref> as an
authentication method or uses the mutual authentication protocol for
HTTP <xref target="RFC8120"> </xref> to authenticate the discovered
EST server. <vspace blankLines="1" />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 <xref target="RFC8121"></xref>.</t>
<t>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
<xref target="RFC6125"></xref>.</t>
<t>The endpoint learns the End-Entity certificates <xref
target="RFC8295"></xref> 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 <xref target="RFC8295"></xref>). The
endpoint needs to identify the certificate provisioned to the DNS
server. The SRV-ID identifier type <xref target="RFC6125"></xref>
within subjectAltName entry MUST be used to identify the DNS server
certificate. <vspace blankLines="1" />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 <xref target="RFC7858"></xref>. As a reminder, the
protocol component is not included in the SRV-ID <xref
target="RFC4985"></xref>.</t>
<t>The endpoint configures the authentication domain name (ADN)
(defined in <xref target="RFC8310"></xref>) 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 <xref target="RFC7671"></xref>.</t>
</list></t>
<t><xref target="fig1"></xref> illustrates a sequence diagram for
bootstrapping an endpoint with the local network's DNS server
certificate.</t>
<t><figure anchor="fig1" title="Bootstrapping Endpoint Devices">
<artwork align="left"><![CDATA[
+----------+ +--------+ +--------+
| Endpoint | | EST | | DNS |
| | | Server | | Server |
+----------+ +--------+ +--------+
| DNS-SD query to discover the EST server | |
|-------------------------------------------------------->|
| | |
| optional: mDNS query to | |
| discover the EST server | |
|--------------------------------------------->| |
| | |
| Establish provisional TLS connection | |
|<-------------------------------------------->| |
| | |
| PAKE scheme to authenticate the EST server | |
|<-------------------------------------------->| |
| | |
[Generate reference identifier for the EST server | |
to compare with the EST server certificate | |
in subsequent TLS connections] | |
| | |
| Get EE certificates | |
|--------------------------------------------->| |
| | |
[Identify the DNS server certificate in EE | |
certificates to match with the certificate | |
by the DNS server in (D)TLS handshake] | |
| |
[Configure ADN and associate DNS server certificate] | |
| | |
]]></artwork>
</figure></t>
</section>
<section anchor="bootstrap-iot" title="Bootstrapping IoT Devices">
<t>The following steps explain the mechanism to automatically bootstrap
IoT devices with local network's CA certificates and DNS server
certificate: <list style="symbols">
<t>Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed
in <xref target="I-D.ietf-anima-bootstrapping-keyinfra"></xref>
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):<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>The IoT device requests the full EST distribution of current
CA certificates (Section 5.9.1 in <xref
target="I-D.ietf-anima-bootstrapping-keyinfra"></xref>) 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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</list></t>
</section>
<section anchor="discovery"
title="DNS-over-(D)TLS and DNS-over-HTTPS Server Discovery Procedure">
<t>A DNS client discovers the DNS server in the local network supporting
DNS-over-TLS, DNS-over-DTLS and DNS-over-HTTPS protocols by using
DNS-based Service Discovery (DNS-SD) <xref target="RFC6763"></xref>.
DNS-SD provides generic solution for discovering services available in a
local network. DNS-SD defines a set of naming rules for certain DNS
record types that they use for advertising and discovering services.
Section 4.1 of <xref target="RFC6763"></xref> specifies that a service
instance name in DNS-SD has the following structure:</t>
<figure>
<artwork><![CDATA[<Instance> . <Service> . <Domain>]]></artwork>
</figure>
<t></t>
<t>The <Domain> portion specifies the authentication domain name.
The <Service> portion of the DNS service instance name MUST be
"_dprive._udp" or "_dprive._tcp" or "_doh._tcp". If no DNS-SD records
can be retrieved, the discovery procedure fails for this authentication
domain name. However, before retrying a lookup that has failed, a DNS
client MUST wait a time period that is appropriate for the encountered
error (e.g., NXDOMAIN, timeout, etc.). If no DNS-SD records can be
retrieved, the client can try connecting to the pre-configured public
DNS servers. If the endpoint has enabled strict privacy profile and
access to the pre-configured public DNS servers is blocked, the DNS
service won't be available to the endpoint and ultimately the endpoint
cannot access Internet-reachable services. If the endpoint has enabled
opportunistic privacy profile and access to the pre-configured public
DNS servers is blocked, the endpoint will either fallback to an
encrypted connection without authenticating the DNS server provided by
the local network or fallback to clear text DNS.</t>
<t>If DNS-over-HTTPS protocol is supported by the DNS server, the DNS
client can query for the URI resource record type <xref
target="RFC7553"></xref> to use the https URI scheme (Section 3 of <xref
target="RFC8484"></xref>).</t>
</section>
<section anchor="auth" title="Connection Handshake and Service Invocation">
<t>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
<xref target="bootstrap-endpoint"></xref> or <xref
target="bootstrap-iot"></xref> 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).</t>
<t>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.</t>
</section>
<section anchor="EST_Discovery" title="EST Service Discovery Procedure">
<t>A EST client discovers the EST server in the local network by using
DNS-based Service Discovery (DNS-SD) <xref target="RFC6763"></xref> or
Multicast DNS (mDNS) <xref target="RFC6762"></xref>. 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".</t>
<section title="mDNS">
<t>A EST client application can proactively discover an EST server
being advertised in the site by multicasting a PTR query to the
following:</t>
<t><list style="symbols">
<t>"_est._tcp.local"</t>
</list>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.</t>
</section>
</section>
<section anchor="reattach" title="Network Reattachment">
<t>On subsequent attachments to the network, the endpoint discovers the
privacy-enabling DNS server using the authentication domain name
(configured in Step 5 of <xref target="bootstrap-endpoint"></xref> or
<xref target="bootstrap-iot"></xref>), initiates (D)TLS handshake with
the DNS server and follows the mechanism discussed in <xref
target="auth"></xref> to validate the DNS server certificate.</t>
<t>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 <xref target="RFC6125"></xref> to
compare the reference identifier (created in Step 2 of <xref
target="bootstrap-endpoint"></xref> in this document) to the EST server
certificate and verifies the entire certification path as per <xref
target="RFC5280"></xref>. 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 <xref
target="auth"></xref> to validate the DNS server certificate.</t>
<t><xref target="fig2"></xref> illustrates a sequence diagram for
re-configuring an endpoint with ADN and local network's DNS server
certificate on subsequent attachments to the network.</t>
<t><figure anchor="fig2"
title="Bootstrapping Endpoint Devices on subsequent attachments to the network">
<artwork align="left"><![CDATA[+----------+ +--------+ +--------+
| Endpoint | | EST | | DNS |
| | | Server | | Server |
+----------+ +--------+ +--------+
| DNS-SD query to discover the EST server | |
|-------------------------------------------------------->|
| | |
| optional: mDNS query to | |
| discover the EST server | |
|--------------------------------------------->| |
| | |
| Establish TLS connection | |
| and validate EST server certificate | |
|<-------------------------------------------->| |
| | |
| Get EE certificates | |
|<-------------------------------------------->| |
| | |
[Identify the DNS server certificate in EE | |
certificates to match with the certificate | |
by the DNS server in (D)TLS handshake] | |
| |
[Re-configure ADN and associate DNS server certificate]| |
| | |
]]></artwork>
</figure></t>
</section>
<section anchor="privacy" title="Privacy Considerations">
<t><xref target="RFC7626"></xref> discusses DNS privacy considerations
in both "on the wire" (Section 2.4 of <xref target="RFC7626"></xref>)
and "in the server" (Section 2.5 of <xref target="RFC7626"></xref>
contexts. The mechanism defined in
[I-D.reddy-dprive-dprive-privacy-policy] can be used by the client to
discover the privacy policy information of the DNS server.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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 <xref target="I-D.barnes-tls-pake"></xref> or <xref
target="RFC8120"></xref> and <xref target="RFC8121"></xref> need to be
taken into consideration.</t>
<t>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.</t>
<t>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.</t>
<t>The primary attacks against the methods described in <xref
target="discovery"></xref> are the ones that would lead to impersonation
of a DNS server and spoofing the DNS response to indicate that the DNS
server does not support any privacy-enabling protocols. To protect
against DNS-vectored attacks, secured DNS (DNSSEC) can be used to ensure
the validity of the DNS records received. Impersonation of the DNS
server is prevented by validating the certificate presented by the DNS
server. If the EST server conveys the DNS server certificate, but the
DNS-SD lookup indicates that the DNS server does not support any
privacy-enabling protocols, the client can detect the DNS response is
spoofed.</t>
<t>Security considerations in <xref
target="I-D.ietf-anima-bootstrapping-keyinfra"></xref> need to be taken
into consideration for IoT devices.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to allocate the SRV service name of "dprive" for
DNS-over-TLS or DNS-over-DTLS, and the service name of "doh" for
DNS-over-HTTPS.</t>
<t>IANA is requested to allocate the SRV service name of "est".</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick
McManus, Bob Harold, Livingood Jason, Winfield Alister, Eliot Lear,
Stephane Bortzmeyer and Sara Dickinson for the discussion and
comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.8174'?>
<?rfc include="reference.RFC.6125"?>
<?rfc include="reference.RFC.7030"?>
<?rfc include="reference.RFC.8295"?>
<?rfc include="reference.RFC.8484"?>
<?rfc include="reference.RFC.7858"?>
<?rfc include="reference.RFC.8094"?>
<?rfc include="reference.RFC.6763"?>
<?rfc include="reference.RFC.8499"?>
<?rfc include="reference.RFC.8446"?>
<?rfc include="reference.RFC.6347"?>
<?rfc include="reference.RFC.4985"?>
<?rfc include="reference.RFC.8121"?>
<?rfc include="reference.RFC.6762"?>
<?rfc include="reference.RFC.5280"?>
<?rfc include="reference.RFC.7553"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.8310"?>
<?rfc include="reference.RFC.8120"?>
<?rfc include='reference.I-D.barnes-tls-pake'?>
<?rfc include='reference.I-D.ietf-anima-bootstrapping-keyinfra'?>
<?rfc include="reference.RFC.2775"?>
<?rfc include="reference.RFC.8106"?>
<?rfc include="reference.RFC.7871"?>
<?rfc include="reference.RFC.7626"?>
<?rfc include='reference.RFC.8520'?>
<?rfc include='reference.RFC.7671'?>
<reference anchor="CDN"
target="https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p167.pdf">
<front>
<title>End-User Mapping: Next Generation Request Routing for Content
Delivery</title>
<author>
<organization></organization>
</author>
<date year="2015" />
</front>
</reference>
<reference anchor="Evil-Twin"
target="https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)">
<front>
<title>Evil twin (wireless networks)</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="Krack" target="https://www.krackattacks.com/">
<front>
<title>Key Reinstallation Attacks</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="2017" />
</front>
</reference>
<reference anchor="Dragonblood"
target="https://papers.mathyvanhoef.com/dragonblood.pdf">
<front>
<title>Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and
EAP-pwd</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
</references>
</back>
</rfc>