-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ietf-dprive-dns-over-tls.xml
1322 lines (1229 loc) · 56.4 KB
/
draft-ietf-dprive-dns-over-tls.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
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1034 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC4033 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC6698 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC5246 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC2595 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2595.xml">
<!ENTITY RFC3501 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY RFC3207 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml">
<!ENTITY RFC3234 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3234.xml">
<!ENTITY RFC1939 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!ENTITY RFC5280 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC2818 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC2131 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC6891 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml">
<!ENTITY RFC4648 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC4892 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4892.xml">
<!ENTITY RFC5077 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY RFC6234 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml">
<!ENTITY RFC6335 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY RFC7766 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml">
<!ENTITY RFC7120 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7120.xml">
<!ENTITY RFC7258 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml">
<!ENTITY RFC7413 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.xml">
<!ENTITY RFC7435 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml">
<!ENTITY RFC7469 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7469.xml">
<!ENTITY RFC7525 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml">
<!ENTITY RFC7626 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7626.xml">
<!ENTITY RFC3646 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3646.xml">
<!ENTITY RFC7830 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7830.xml">
<!ENTITY RFC7828 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7828.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<?rfc toc="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-dprive-dns-over-tls-10" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="DNS over TLS">Specification for DNS over TLS</title>
<author fullname="Zi Hu" initials="Z." surname="Hu">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 1133</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>United States</country>
</postal>
<phone>+1 213 587 1057</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Liang Zhu" initials="L." surname="Zhu">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 1133</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>United States</country>
</postal>
<phone>+1 310 448 8323</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="John Heidemann" initials="J." surname="Heidemann">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>United States</country>
</postal>
<phone>+1 310 822 1511</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization>Independent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
</postal>
<phone>+1 301 728 7198</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>Verisign Labs</organization>
<address>
<postal>
<street>12061 Bluemont Way</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
<country>United States</country>
</postal>
<phone>+1 703 948 3200</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>ICANN</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document describes the use of TLS to provide privacy
for DNS. Encryption provided by TLS eliminates opportunities
for eavesdropping and on-path tampering with DNS queries in the network, such as
discussed in RFC 7626.
In addition, this document specifies
two usage profiles for DNS-over-TLS and provides advice on
performance considerations to minimize overhead from using
TCP and TLS with DNS.
</t>
<t>
This document focuses on securing stub-to-recursive traffic, as per the
charter of the DPRIVE working group. It does not prevent future applications
of the protocol to recursive-to-authoritative traffic.
</t>
<t>
Note: this document was formerly named
draft-ietf-dprive-start-tls-for-dns. Its name has been
changed to better describe the mechanism now used. Please
refer to working group archives under the former name for
history and previous discussion. [RFC Editor: please remove
this paragraph prior to publication]
</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>
Today, nearly all DNS queries <xref target="RFC1034"/>,
<xref target="RFC1035"/> are sent unencrypted, which makes
them vulnerable to eavesdropping by an attacker that has
access to the network channel, reducing the privacy of the
querier. Recent news reports have elevated these concerns,
and recent IETF work has specified privacy considerations
for DNS <xref target="RFC7626"/>.
</t>
<t>
Prior work has addressed some aspects of DNS security, but
until recently there has been little work on privacy between
a DNS client and server. DNS Security Extensions (DNSSEC),
<xref target="RFC4033"/> provide <spanx style="emph">response
integrity</spanx> by defining mechanisms to cryptographically
sign zones, allowing end-users (or their first-hop resolver)
to verify replies are correct. By intention, DNSSEC does not
protect request and response privacy. Traditionally, either
privacy was not considered a requirement for DNS traffic, or
it was assumed that network traffic was sufficiently private,
however these perceptions are evolving due to recent events
<xref target="RFC7258"/>.
</t>
<t>
Other work that has offered the potential to encrypt
between DNS clients and servers includes
DNSCurve <xref target="dempsky-dnscurve"/>,
DNSCrypt <xref target="dnscrypt-website"/>,
ConfidentialDNS <xref target="I-D.confidentialdns"/>
and IPSECA <xref target="I-D.ipseca"/>.
In addition to the present draft, the DPRIVE working group
has also adopted a DNS-over-DTLS
<xref target="draft-ietf-dprive-dnsodtls"/> proposal.
</t>
<t>
This document describes using DNS-over-TLS on a well-known port and
also offers advice on performance considerations to minimize overheads from
using TCP and TLS with DNS.
</t>
<t>
Initiation of DNS-over-TLS is very straightforward. By
establishing a connection over a well-known port, clients and
servers expect and agree to negotiate a TLS session to secure
the channel. Deployment will be gradual. Not all servers will
support DNS-over-TLS and the well-known port might be blocked
by some firewalls. Clients will be expected to keep track
of servers that support TLS and those that don't. Clients and
servers will adhere to the TLS implementation recommendations
and security considerations of <xref target="BCP195"/>.
</t>
<t>
The protocol described here works
for queries and responses between stub clients and recursive
servers. It might work equally between recursive clients
and authoritative servers, but this application of the
protocol is out of scope for the DNS PRIVate Exchange
(DPRIVE) Working Group per its current charter.
</t>
<t>
This document describes two profiles in <xref target="profiles"/>
providing different levels of assurance of privacy: an opportunistic
privacy profile and an out-of-band key-pinned privacy profile.
It is expected that a future document based on <xref target="dgr-dprive-dtls-and-tls-profiles"/> will further
describe additional privacy profiles for DNS over both TLS and DTLS.
</t>
<t>
An earlier version of this document described a technique for
upgrading a DNS-over-TCP connection to a DNS-over-TLS session
with, essentially, "STARTTLS for DNS".
To simplify the protocol, this document now
only uses a well-known port to specify TLS use,
omitting the upgrade approach.
The upgrade approach no longer
appears in this document, which now focuses exclusively on
the use of a well-known port for DNS-over-TLS.
</t>
</section>
<section title="Reserved Words">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section anchor="Establishment" title="Establishing and Managing DNS-over-TLS Sessions">
<section anchor="Initiation" title="Session Initiation">
<t>
A DNS server that supports DNS-over-TLS MUST by default listen for
and accept TCP connections on port 853, unless it has mutual agreement
with its clients to use a port other than
853 for DNS-over-TLS.
In order to use a port other than 853, both clients and servers
would need a configuration option in their software.
</t>
<t>
DNS clients desiring privacy from DNS-over-TLS from a
particular server MUST by default establish a TCP connection to
port 853 on the server, unless it has mutual agreement with its server
to use a port other than port 853 for DNS-over-TLS.
Such an other port MUST NOT be port 53, but MAY be from the
"first-come, first-served" port range.
This recommendation against use of port 53 for DNS-over-TLS
is to avoid
complication in selecting use or non-use of TLS,
and to reduce risk of downgrade attacks.
The first data exchange on this TCP
connection MUST be the client and server
initiating a TLS handshake using the procedure described
in <xref target="RFC5246"/>.
</t>
<t>
DNS clients and servers MUST NOT use port 853 to transport
clear text DNS messages. DNS clients MUST NOT send and
DNS servers MUST NOT respond to clear text DNS messages
on any port used for DNS-over-TLS (including, for example,
after a failed TLS handshake). There are significant
security issues in mixing protected and unprotected data
and for this reason TCP connections on a port designated
by a given server for DNS-over-TLS are reserved purely
for encrypted communications.
</t>
<t>
DNS clients SHOULD remember server IP addresses that don't
support DNS-over-TLS, including timeouts, connection
refusals, and TLS handshake failures, and not request
DNS-over-TLS from them for a reasonable period (such as
one hour per server). DNS clients following an out-of-band key-pinned
privacy profile (<xref target="oobkppp"/>) MAY be more aggressive about retrying
DNS-over-TLS connection failures.
</t>
</section>
<section anchor="handshake" title="TLS Handshake and Authentication">
<t>
Once the DNS client succeeds in connecting via TCP on the well-known port for
DNS-over-TLS, it proceeds with the TLS handshake <xref target="RFC5246"/>,
following
the best practices specified in <xref target="BCP195"/>.
</t>
<t>
The client will then authenticate the server, if required.
This document does
not propose new ideas for authentication.
Depending on the privacy profile in use (<xref target="profiles"/>), the DNS client may
choose not to require authentication of the server, or it may make use of
a trusted Subject Public Key Info (SPKI) Fingerprint pinset.
</t>
<t>
After TLS negotiation completes, the connection will be encrypted
and is now protected from eavesdropping.
<!-- Suggested for removal during IESG review
At this point, normal DNS queries SHOULD take place.
-->
</t>
</section>
<section anchor="transmitting" title="Transmitting and Receiving Messages">
<t>
All messages (requests and responses) in the established TLS session
MUST use the two-octet length field described in Section 4.2.2 of
<xref target="RFC1035"/>.
For reasons of efficiency, DNS clients and servers SHOULD
pass the two-octet length field, and the message
described by that length field, to the TCP layer at the
same time (e.g., in a single "write" system call) to make
it more likely that all the data will be transmitted in
a single TCP segment
(<xref target="RFC7766"/>, Section 8).
</t>
<t>
<!-- cut-n-paste with edits from rfc7766 sec 6.2.1.1 -->
In order to minimize latency, clients SHOULD pipeline
multiple queries over a TLS session. When a DNS client sends
multiple queries to a server, it should not wait for an
outstanding reply before sending the next query (<xref
target="RFC7766"/>, Section 6.2.1.1).
</t>
<t>
<!-- cut-n-paste from rfc7766 sec 7 with s/TCP/TLS/ -->
Since pipelined responses can arrive out of order, clients
MUST match responses to outstanding queries on the same
TLS connection using the Message ID. If the response
contains a question section, the client MUST match the
QNAME, QCLASS, and QTYPE fields. Failure by clients to
properly
match responses to outstanding queries can have serious
consequences for interoperability (<xref
target="RFC7766"/>, Section 7).
</t>
</section>
<section anchor="Connection" title="Connection Reuse, Close and Reestablishment">
<t>
For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()",
current implementations are known to open and close TCP connections for each DNS
query. To avoid excess TCP connections, each with a single query,
clients SHOULD reuse a single TCP connection to the
recursive resolver. Alternatively they may prefer to use UDP
to a DNS-over-TLS enabled caching resolver on the same machine
that then uses a system-wide TCP connection to the recursive
resolver.
</t>
<t>
In order to amortize TCP and TLS connection setup costs, clients
and servers SHOULD NOT immediately close a connection after
each response. Instead, clients and servers SHOULD reuse
existing connections for subsequent queries as long as they
have sufficient resources. In some cases, this means that
clients and servers may need to keep idle connections open for
some amount of time.
</t>
<t>
Proper management of established and idle connections is important
to the healthy operation of a DNS server. An implementor of
DNS-over-TLS SHOULD follow best practices for DNS-over-TCP, as
described in <xref target="RFC7766"/>. Failure
to do so may lead to resource exhaustion and denial-of-service.
</t>
<t>
Whereas client and server implementations from the <xref
target="RFC1035"/> era are known to have poor TCP connection
management, this document stipulates that successful negotiation
of TLS indicates the willingness of both parties to keep idle
DNS connections open, independent of timeouts or other
recommendations for DNS-over-TCP without TLS. In other words,
software implementing this protocol is assumed to support idle,
persistent connections and be prepared to manage
multiple, potentially long-lived TCP connections.
</t>
<t>
This document does not make specific recommendations for timeout
values on idle connections. Clients and servers should reuse
and/or close connections depending on the level of available
resources. Timeouts may be longer during periods of low activity
and shorter during periods of high activity. Current work in
this area may also assist DNS-over-TLS clients and servers
in selecting useful timeout values <xref
target="RFC7828"/> <xref target="tdns"/>.
</t>
<t>
Clients and servers that keep idle connections open MUST be
robust to termination of idle connection by either party. As
with current DNS-over-TCP, DNS servers MAY close the connection
at any time (perhaps due to resource constraints). As with current
DNS-over-TCP, clients MUST handle abrupt closes and be prepared
to reestablish connections and/or retry queries.
</t>
<t>
When reestablishing a DNS-over-TCP connection that was terminated,
as discussed in <xref target="RFC7766"/>, TCP Fast Open <xref
target="RFC7413"/> is of benefit.
Underlining the requirement for sending only encrypted
DNS data on a DNS-over-TLS port (Section 3.2), when
using TCP Fast Open the client and server MUST immediately
initiate or resume a TLS handshake (clear text DNS MUST
NOT be exchanged).
DNS servers SHOULD enable fast
TLS session resumption <xref target="RFC5077"/> and this SHOULD
be used when reestablishing connections.
</t>
<t>
When closing a connection, DNS servers SHOULD use the TLS
close-notify request to shift TCP TIME-WAIT state to the clients.
Additional requirements and guidance for optimizing DNS-over-TCP
are provided by <xref target="RFC7766"/>.
</t>
</section>
</section>
<section anchor="profiles" title="Usage Profiles">
<t>
This protocol provides flexibility to accommodate several different use cases.
This document defines two usage profiles: (1) opportunistic privacy, and
(2) out-of-band key-pinned authentication that can be used to obtain
stronger privacy guarantees if the client has a trusted
relationship with a DNS server supporting TLS. Additional
methods of authentication will be defined in a forthcoming
draft <xref target="dgr-dprive-dtls-and-tls-profiles"/>.
</t>
<section title="Opportunistic Privacy Profile">
<t>
For opportunistic privacy, analogous to SMTP opportunistic
security <xref target="RFC7435"/>, one does not require privacy,
but one desires privacy when
possible.
</t>
<t>
With opportunistic privacy, a client might learn of a
TLS-enabled recursive DNS resolver from an untrusted
source (such as DHCP's DNS server option <xref target="RFC3646"/> to
discover the IP address followed by attemting the
DNS-over-TLS on port 853, or with a future DHCP option
that specifies DNS port). With such a discovered DNS
server, the client might or might not validate the resolver.
These choices maximize availability and performance, but
they leave the client vulnerable to on-path attacks that
remove privacy.
</t>
<t>
Opportunistic privacy can be used by any current client, but
it only provides privacy when there are no on-path
active attackers.
</t>
</section>
<section title="Out-of-band Key-pinned Privacy Profile" anchor="oobkppp">
<t>
The out-of-band key-pinned privacy profile can be used in
environments where an established trust relationship already
exists between DNS clients and servers (e.g.,
stub-to-recursive in enterprise networks,
actively-maintained contractual service relationships,
or a client using a public DNS resolver).
The result of this profile is that the client has strong guarantees
about the privacy of its DNS data by
connecting only to servers it can authenticate.
Operators
of a DNS-over-TLS service in this profile are expected to provide pins
that are specific to the service being pinned (i.e., public
keys belonging directly to the end-entity or to a
service-specific private CA) and not to public key(s) of a
generic public CA.
</t>
<t>
In this profile, clients authenticate servers by matching
a set of Subject Public Key Info (SPKI) Fingerprints in an analogous
manner to that described in <xref target="RFC7469"/>.
With this out-of-band key-pinned privacy profile, client administrators
SHOULD deploy a backup pin along with the primary pin, for the reasons explained in <xref target="RFC7469"/>.
A backup pin is especially helpful in the event of a key rollover,
so that a server
operator does not have to coordinate key transitions with
all its clients simultaneously. After a change of keys on
the server, an updated pinset SHOULD be distributed to all
clients in some secure way in preparation for future key
rollover. The mechanism for out-of-band pinset update is
out of scope for this document.
</t>
<t>
Such a client will only use DNS servers for which an SPKI
Fingerprint pinset has been provided.
The possession of trusted pre-deployed pinset
allows the client to detect and prevent person-in-the-middle and
downgrade attacks.
</t>
<t>
However, a configured DNS server may be temporarily unavailable
when configuring a network. For example, for clients on
networks that require authentication through web-based login,
such authentication may rely on DNS interception and spoofing.
Techniques such as those used by DNSSEC-trigger <xref
target="dnssec-trigger"/> MAY be used during network
configuration, with the intent to transition to the designated
DNS provider after authentication. The user MUST be alerted
whenever possible
that the DNS is not private during such bootstrap.
</t>
<t>
Upon successful TLS connection and handshake, the client
computes the SPKI Fingerprints for the public keys found
in the validated server's certificate chain (or in the raw public key, if
the server provides that instead). If a computed
fingerprint exactly matches one of the configured pins the
client continues with the connection as normal. Otherwise,
the client MUST treat the SPKI validation failure as a
non-recoverable error. <xref target="example"/> provides a detailed example
of how this authentication could be performed in practice.
</t>
<t>
Implementations of this privacy profile MUST support
the calculation of a fingerprint as the SHA-256
<xref target="RFC6234"/> hash of the DER-encoded ASN.1
representation of the Subject Public Key Info (SPKI) of
an X.509 certificate.
Implementations MUST support the representation of a
SHA-256 fingerprint as a base 64 encoded character string
<xref target="RFC4648"/>.
Additional fingerprint types MAY also be supported.
</t>
</section>
</section>
<section anchor="Performance" title="Performance Considerations">
<t>
DNS-over-TLS incurs additional latency at session startup. It
also requires additional state (memory) and increased processing
(CPU).
<list style="hanging">
<t hangText="Latency:">
Compared to UDP, DNS-over-TCP requires an additional
round-trip-time (RTT) of latency to establish a TCP connection.
TCP Fast Open <xref target="RFC7413"/> can eliminate that RTT
when information exists from prior connections.
The TLS handshake adds another two RTTs of latency. Clients
and servers should support connection keepalive (reuse) and
out of order processing to amortize connection setup costs.
Fast TLS connection
resumption <xref target="RFC5077"/> further reduces the
setup delay and avoids the DNS server keeping per-client session state.
</t>
<t>
TLS False Start <xref target="draft-ietf-tls-falsestart"/> can also lead to a latency
reduction in certain situations.
Implementations supporting TLS false start need to be
aware that it imposes additional constraints on how one
uses TLS, over and above those stated in <xref
target="BCP195"/>.
It is unsafe to use false start if your implementation
and deployment does not adhere to these specific
requirements.
See <xref target="draft-ietf-tls-falsestart"/> for the
details of these additional constraints.
</t>
<t hangText="State:">
The use of connection-oriented TCP requires keeping additional
state at the server in both the kernel and application.
The state requirements
are of particular concern on servers with many clients,
although memory-optimized TLS can add only modest state over TCP.
Smaller timeout values will reduce the number of concurrent
connections, and servers can preemptively close connections
when resource limits are exceeded.
</t>
<t hangText="Processing:">
Use of TLS encryption algorithms results in slightly higher
CPU usage. Servers can choose to refuse new DNS-over-TLS
clients if processing limits are exceeded.
</t>
<t hangText="Number of connections:">
To minimize state on DNS servers and
connection startup time, clients SHOULD minimize creation
of new TCP connections. Use of a local DNS request aggregator
(a particular type of forwarder) allows a single active
DNS-over-TLS connection from any given client computer to
its server. Additional guidance can be found in <xref
target="RFC7766"/>.
</t>
</list>
A full performance evaluation is outside the scope of this
specification. A more detailed analysis of the performance
implications of DNS-over-TLS (and DNS-over-TCP) is discussed
in <xref target="tdns"/> and <xref
target="RFC7766"/>.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is requested to add the following value to the "Service Name
and Transport Protocol Port Number Registry" registry in the System
Range. The registry for that range requires IETF Review or IESG Approval
<xref target="RFC6335"/> and such a review was requested using the
Early Allocation process <xref target="RFC7120"/> for the well-known TCP port
in this document.
</t>
<t>
We further recommend that IANA reserve the same port number over UDP
for the proposed DNS-over-DTLS protocol <xref
target="draft-ietf-dprive-dnsodtls"/>.
</t>
<t>
IANA responded to the early allocation request with the following
TEMPORARY assignment:
</t>
<figure>
<artwork><![CDATA[
Service Name domain-s
Port Number 853
Transport Protocol(s) TCP/UDP
Assignee IETF DPRIVE Chairs
Contact Paul Hoffman
Description DNS query-response protocol run over TLS/DTLS
Reference This document
]]></artwork>
</figure>
<t>
The TEMPORARY assignment expires 2016-10-08. IANA is requested to make the
assigmnent permanent upon publication of this document as an RFC.
</t>
</section>
<section anchor="Evolution" title="Design Evolution">
<t>
[Note to RFC Editor: please do not remove this section
as it may be useful to future Foo-over-TLS efforts]
</t>
<t>
Earlier versions of this document
proposed an upgrade-based approach to establish a TLS
session. The client would signal its interest in TLS by
setting a "TLS OK" bit in the EDNS0 flags field. A server
would signal its acceptance by responding with the TLS OK
bit set.
</t>
<t>
Since we assume the client doesn't want to reveal (leak)
any information prior to securing the channel, we proposed
the use of a "dummy query" that clients could send for this
purpose. The proposed query name was STARTTLS, query type
TXT, and query class CH.
</t>
<t>
The TLS OK signaling approach has both advantages and
disadvantages. One important advantage is that clients and
servers could negotiate TLS. If the server is too busy,
or doesn't want to provide TLS service to a particular
client, it can respond negatively to the TLS probe. An
ancillary benefit is that servers could collect information
on adoption of DNS-over-TLS (via the TLS OK bit in queries)
before implementation and deployment. Another anticipated
advantage is the expectation that DNS-over-TLS would work
over port 53. That is, no need to "waste" another port and
deploy new firewall rules on middleboxes.
</t>
<t>
However, at the same time, there was uncertainty whether
or not middleboxes would pass the TLS OK bit, given that
the EDNS0 flags field has been unchanged for many years.
Another disadvantage is that the TLS OK bit may make downgrade
attacks easy and indistinguishable from broken middleboxes.
From a performance standpoint, the upgrade-based approach
had the disadvantage of requiring 1xRTT additional latency
for the dummy query.
</t>
<t>
Following this proposal, DNS-over-DTLS was proposed separately.
DNS-over-DTLS claimed it could work over port 53, but only
because a non-DTLS server interprets a DNS-over-DTLS query
as a response. That is, the non-DTLS server observes the
QR flag set to 1. While this technically works, it seems
unfortunate and perhaps even undesirable.
</t>
<t>
DNS over both TLS and DTLS can benefit from a single
well-known port and avoid extra latency and mis-interpreted
queries as responses.
</t>
</section>
<section anchor="Implementation" title="Implementation Status">
<t>
[Note to RFC Editor: please remove this section and reference to
RFC 6982 prior to publication.]
</t>
<t>
This section records the status of known implementations of the
protocol defined by this specification at the time of posting
of this Internet-Draft, and is based on a proposal described
in RFC 6982. The description of implementations in this section
is intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of
any individual implementation here does not imply endorsement
by the IETF. Furthermore, no effort has been spent to verify
the information presented here that was supplied by IETF
contributors. This is not intended as, and must not be construed
to be, a catalog of available implementations or their features.
Readers are advised to note that other implementations may
exist.
</t>
<t>
According to RFC 6982, "this will allow reviewers and working
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working
groups to use this information as they see fit".
</t>
<section title="Unbound">
<t>
The Unbound recursive name server software added support for
DNS-over-TLS in version 1.4.14. The unbound.conf configuration file
has the following configuration directives: ssl-port, ssl-service-key,
ssl-service-pem, ssl-upstream. See https://unbound.net/documentation/unbound.conf.html.
</t>
</section>
<section title="ldns">
<t>
Sinodun Internet Technologies has implemented DNS-over-TLS
in the ldns library from NLnetLabs. This also gives DNS-over-TLS
support to the drill DNS client program. Patches available
at
https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/browse.
</t>
</section>
<section title="digit">
<t>
The digit DNS client from USC/ISI supports DNS-over-TLS.
Source code available at http://www.isi.edu/ant/software/tdns/index.html.
</t>
</section>
<section title="getdns">
<t>
The getdns API implementation supports DNS-over-TLS.
Source code available at https://getdnsapi.net.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Use of DNS-over-TLS is designed to address the privacy
risks that arise out of the ability to eavesdrop on DNS messages. It
does not address other security issues in DNS, and there are a
number of residual risks that may affect its success at protecting
privacy:
<list style="numbers">
<t>
There are known attacks on TLS, such as person-in-the-middle
and protocol downgrade. These are general attacks on TLS
and not specific to DNS-over-TLS; please refer to the TLS
RFCs for discussion of these security issues.
Clients and
servers MUST adhere to the TLS implementation recommendations
and security considerations of <xref target="BCP195"/>.
DNS clients keeping track of servers known to support TLS
enables clients to detect downgrade attacks.
For servers with no connection history and no apparent
support for TLS, depending on their Privacy
Profile and privacy requirements, clients may choose to (a) try another server when
available, (b) continue without TLS, or (c) refuse to
forward the query.
</t>
<t>
Middleboxes <xref target="RFC3234"/> are present in some
networks and have been known to interfere with normal DNS
resolution.
Use of a designated port for DNS-over-TLS
should avoid such interference.
In general, clients that attempt TLS and fail can either fall
back on unencrypted DNS, or wait and retry later, depending
on their Privacy Profile and privacy requirements.
</t>
<!--
XXX The authors debated whether or not the following
paragraph belongs in the document. On one hand,
person-in-the-middle attacks are generally about data
integrity, which would be protected by DNSSEC rather
than TLS. On the other hand, it specifically calls out
server capabilities, which is something that clients
learn via responses and is not protected by DNSSEC.
-->
<t>
Any DNS protocol interactions
performed in the clear can be modified by a person-in-the-middle
attacker. For example, unencrypted queries and responses
might take place over port 53 between a client and server.
For this reason, clients MAY discard cached
information about server capabilities advertised in clear text.
</t>
<t>
This document does not itself specify ideas to resist
known traffic analysis or side channel leaks. Even with encrypted
messages, a well-positioned party may be able to glean
certain details from an analysis of message timings and
sizes. Clients and servers may consider the use of a padding
method to address privacy leakage due to message sizes
<xref target="RFC7830"/>.
Since traffic analysis can be based on many kinds of
patterns and many kinds of classifiers, simple padding
schemes alone might not be sufficient to mitigate
such an attack.
Padding will, however, form a part of more
complex mitigations for traffic analysis attacks
that are likely to be developed over time.
Implementers
who can offer flexibility in terms of how padding can
be used may be in a better position to enable such
mitigations to be deployed in future.
</t>
</list>
</t>
<t>
As noted earlier, DNSSEC and DNS-over-TLS are independent
and fully compatible protocols, each solving different
problems. The use of one does not diminish the need nor
the usefulness of the other.
</t>
</section>
<section anchor="contrib" title="Contributing Authors">
<t>
The below individuals contributed significantly to the draft,
and so
we have listed additional authors in this section.
</t>
<figure>
<artwork><![CDATA[
Sara Dickinson
Sinodun Internet Technologies
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Email: [email protected]
URI: http://sinodun.com
Daniel Kahn Gillmor
ACLU
125 Broad Street, 18th Floor
New York, NY 10004
United States
]]></artwork>
</figure>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
The authors would like to thank
Stephane Bortzmeyer,
John Dickinson,
Brian Haberman,
Christian Huitema,
Shumon Huque,
Kim-Minh Kaplan,
Simon Joseffson,
Simon Kelley,
Warren Kumari,
John Levine,
Ilari Liusvaara,
Bill Manning,
George Michaelson,
Eric Osterweil,
Jinmei Tatuya,
Tim Wicinski,
and
Glen Wiley
for reviewing this Internet-draft.
They also thank
Nikita Somaiya for early work on this idea.
</t>
<t>
Work by Zi Hu, Liang Zhu, and John Heidemann on this document is
partially sponsored by the U.S. Dept. of Homeland Security (DHS)
Science and Technology Directorate, HSARPA, Cyber Security
Division, BAA 11-01-RIKA and Air Force Research Laboratory,
Information Directorate under agreement number FA8750-12-2-0344,
and contract number D08PC75599.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC1034;
&RFC1035;
&RFC4648;
&RFC5246;
<!-- &RFC6891; -->
&RFC5077;
&RFC6234;
&RFC6335;
&RFC7766;
&RFC7120;
&RFC7469;
<reference anchor="BCP195">