-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ietf-dprive-dns-over-tls.txt
1120 lines (768 loc) · 45.9 KB
/
draft-ietf-dprive-dns-over-tls.txt
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
Network Working Group Z. Hu
Internet-Draft L. Zhu
Intended status: Standards Track J. Heidemann
Expires: November 12, 2016 USC/Information Sciences Institute
A. Mankin
Independent
D. Wessels
Verisign Labs
P. Hoffman
ICANN
May 11, 2016
Specification for DNS over TLS
draft-ietf-dprive-dns-over-tls-10
Abstract
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.
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.
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]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Hu, et al. Expires November 12, 2016 [Page 1]
Internet-Draft DNS over TLS May 2016
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. TLS Handshake and Authentication . . . . . . . . . . . . 5
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5
3.4. Connection Reuse, Close and Reestablishment . . . . . . . 6
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . 7
5. Performance Considerations . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 10
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 15
Hu, et al. Expires November 12, 2016 [Page 2]
Internet-Draft DNS over TLS May 2016
Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Today, nearly all DNS queries [RFC1034], [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
[RFC7626].
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), [RFC4033] provide
_response integrity_ 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 [RFC7258].
Other work that has offered the potential to encrypt between DNS
clients and servers includes DNSCurve [dempsky-dnscurve], DNSCrypt
[dnscrypt-website], ConfidentialDNS [I-D.confidentialdns] and IPSECA
[I-D.ipseca]. In addition to the present draft, the DPRIVE working
group has also adopted a DNS-over-DTLS [draft-ietf-dprive-dnsodtls]
proposal.
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.
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 [BCP195].
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.
Hu, et al. Expires November 12, 2016 [Page 3]
Internet-Draft DNS over TLS May 2016
This document describes two profiles in Section 4 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 [dgr-dprive-dtls-and-tls-profiles] will
further describe additional privacy profiles for DNS over both TLS
and DTLS.
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.
2. Reserved Words
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 RFC 2119 [RFC2119].
3. Establishing and Managing DNS-over-TLS Sessions
3.1. Session Initiation
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.
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 [RFC5246].
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
Hu, et al. Expires November 12, 2016 [Page 4]
Internet-Draft DNS over TLS May 2016
server for DNS-over-TLS are reserved purely for encrypted
communications.
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 (Section 4.2) MAY
be more aggressive about retrying DNS-over-TLS connection failures.
3.2. TLS Handshake and Authentication
Once the DNS client succeeds in connecting via TCP on the well-known
port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246],
following the best practices specified in [BCP195].
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 (Section 4), 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.
After TLS negotiation completes, the connection will be encrypted and
is now protected from eavesdropping.
3.3. Transmitting and Receiving Messages
All messages (requests and responses) in the established TLS session
MUST use the two-octet length field described in Section 4.2.2 of
[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 ([RFC7766], Section 8).
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 ([RFC7766], Section 6.2.1.1).
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 ([RFC7766], Section 7).
Hu, et al. Expires November 12, 2016 [Page 5]
Internet-Draft DNS over TLS May 2016
3.4. Connection Reuse, Close and Reestablishment
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.
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.
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
[RFC7766]. Failure to do so may lead to resource exhaustion and
denial-of-service.
Whereas client and server implementations from the [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.
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 [RFC7828] [tdns].
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.
Hu, et al. Expires November 12, 2016 [Page 6]
Internet-Draft DNS over TLS May 2016
When reestablishing a DNS-over-TCP connection that was terminated, as
discussed in [RFC7766], TCP Fast Open [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 [RFC5077] and this SHOULD be used when
reestablishing connections.
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 [RFC7766].
4. Usage Profiles
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 [dgr-dprive-dtls-and-tls-profiles].
4.1. Opportunistic Privacy Profile
For opportunistic privacy, analogous to SMTP opportunistic security
[RFC7435], one does not require privacy, but one desires privacy when
possible.
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 [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.
Opportunistic privacy can be used by any current client, but it only
provides privacy when there are no on-path active attackers.
4.2. Out-of-band Key-pinned Privacy Profile
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
Hu, et al. Expires November 12, 2016 [Page 7]
Internet-Draft DNS over TLS May 2016
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.
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 [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 [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.
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.
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 [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.
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. Appendix A provides a detailed example of how
this authentication could be performed in practice.
Implementations of this privacy profile MUST support the calculation
of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded
ASN.1 representation of the Subject Public Key Info (SPKI) of an
Hu, et al. Expires November 12, 2016 [Page 8]
Internet-Draft DNS over TLS May 2016
X.509 certificate. Implementations MUST support the representation
of a SHA-256 fingerprint as a base 64 encoded character string
[RFC4648]. Additional fingerprint types MAY also be supported.
5. Performance Considerations
DNS-over-TLS incurs additional latency at session startup. It also
requires additional state (memory) and increased processing (CPU).
Latency: Compared to UDP, DNS-over-TCP requires an additional round-
trip-time (RTT) of latency to establish a TCP connection. TCP
Fast Open [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 [RFC5077]
further reduces the setup delay and avoids the DNS server keeping
per-client session state.
TLS False Start [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 [BCP195]. It is unsafe to use false start if your
implementation and deployment does not adhere to these specific
requirements. See [draft-ietf-tls-falsestart] for the details of
these additional constraints.
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.
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.
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 [RFC7766].
Hu, et al. Expires November 12, 2016 [Page 9]
Internet-Draft DNS over TLS May 2016
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
[tdns] and [RFC7766].
6. IANA Considerations
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 [RFC6335] and such a review was requested using the Early
Allocation process [RFC7120] for the well-known TCP port in this
document.
We further recommend that IANA reserve the same port number over UDP
for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls].
IANA responded to the early allocation request with the following
TEMPORARY assignment:
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
The TEMPORARY assignment expires 2016-10-08. IANA is requested to
make the assigmnent permanent upon publication of this document as an
RFC.
7. Design Evolution
[Note to RFC Editor: please do not remove this section as it may be
useful to future Foo-over-TLS efforts]
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.
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.
Hu, et al. Expires November 12, 2016 [Page 10]
Internet-Draft DNS over TLS May 2016
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.
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.
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.
DNS over both TLS and DTLS can benefit from a single well-known port
and avoid extra latency and mis-interpreted queries as responses.
8. Implementation Status
[Note to RFC Editor: please remove this section and reference to RFC
6982 prior to publication.]
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.
According to RFC 6982, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
Hu, et al. Expires November 12, 2016 [Page 11]
Internet-Draft DNS over TLS May 2016
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".
8.1. Unbound
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.
8.2. ldns
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.
8.3. digit
The digit DNS client from USC/ISI supports DNS-over-TLS. Source code
available at http://www.isi.edu/ant/software/tdns/index.html.
8.4. getdns
The getdns API implementation supports DNS-over-TLS. Source code
available at https://getdnsapi.net.
9. Security Considerations
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:
1. 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 [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
Hu, et al. Expires November 12, 2016 [Page 12]
Internet-Draft DNS over TLS May 2016
available, (b) continue without TLS, or (c) refuse to forward the
query.
2. Middleboxes [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.
3. 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.
4. 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 [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.
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.
10. Contributing Authors
The below individuals contributed significantly to the draft, and so
we have listed additional authors in this section.
Sara Dickinson
Sinodun Internet Technologies
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Email: [email protected]
Hu, et al. Expires November 12, 2016 [Page 13]
Internet-Draft DNS over TLS May 2016
URI: http://sinodun.com
Daniel Kahn Gillmor
ACLU
125 Broad Street, 18th Floor
New York, NY 10004
United States
11. Acknowledgments
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.
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.
12. References
12.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Hu, et al. Expires November 12, 2016 [Page 14]
Internet-Draft DNS over TLS May 2016
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487
/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC
6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<http://www.rfc-editor.org/info/rfc7766>.
12.2. Informative References
[I-D.confidentialdns]
Wijngaards, W., "Confidential DNS", draft-wijngaards-
dnsop-confidentialdns-03 (work in progress), March 2015,
<http://tools.ietf.org/html/draft-wijngaards-dnsop-
confidentialdns-03>.
[I-D.ipseca]
Hu, et al. Expires November 12, 2016 [Page 15]
Internet-Draft DNS over TLS May 2016
Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A.
Mohaisen, "Opportunistic Encryption with DANE Semantics
and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in
progress), July 2015, <http://tools.ietf.org/html/draft-
osterweil-dane-ipsec-03>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<http://www.rfc-editor.org/info/rfc3234>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003,
<http://www.rfc-editor.org/info/rfc3646>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
Hu, et al. Expires November 12, 2016 [Page 16]
Internet-Draft DNS over TLS May 2016
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/
RFC7828, April 2016,
<http://www.rfc-editor.org/info/rfc7828>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI
10.17487/RFC7830, May 2016,
<http://www.rfc-editor.org/info/rfc7830>.
[dempsky-dnscurve]
Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work
in progress), August 2010,
<http://tools.ietf.org/html/draft-dempsky-dnscurve-01>.
[dgr-dprive-dtls-and-tls-profiles]
Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
draft-dgr-dprive-dtls-and-tls-profiles-00 (work in
progress), December 2015, <https://tools.ietf.org/html/
draft-dgr-dprive-dtls-and-tls-profiles-00>.
[dnscrypt-website]
Denis, F., "DNSCrypt", December 2015, <https://
www.dnscrypt.org/>.
[dnssec-trigger]
NLnet Labs, "Dnssec-Trigger", May 2014, <https://
www.nlnetlabs.nl/projects/dnssec-trigger/>.
[draft-ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", draft-ietf-dprive-dnsodtls-06 (work in
progress), April 2016, <https://tools.ietf.org/html/draft-
ietf-dprive-dnsodtls-06>.
[draft-ietf-tls-falsestart]
Moeller, B., Langley, A., and N. Modadugu, "Transport
Layer Security (TLS) False Start", draft-ietf-tls-
falsestart-01 (work in progress), November 2015,
<http://tools.ietf.org/html/draft-ietf-tls-falsestart-01>.
[tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
and N. Somaiya, "Connection-Oriented DNS to Improve
Privacy and Security", Proceedings of the 36th IEEE
Hu, et al. Expires November 12, 2016 [Page 17]
Internet-Draft DNS over TLS May 2016
Symposium on Security and Privacy, DOI 10.1109/SP.2015.18,
May 2015, <http://dx.doi.org/10.1109/SP.2015.18>.
Appendix A. Out-of-band Key-pinned Privacy Profile Example
This section presents an example of how the out-of-band key-pinned
privacy profile could work in practice based on a minimal pinset (two
pins).
A DNS client system is configured with an out-of-band key-pinned
privacy profile from a network service, using a pinset containing two
pins. Represented in HPKP [RFC7469] style, the pins are:
o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="
The client also configures the IP addresses of its expected DNS
server, perhaps 192.0.2.3 and 2001:db8::2:4.
The client connects to one of these addresses on TCP port 853 and
begins the TLS handshake, negotiation TLS 1.2 with a diffie-hellman
key exchange. The server sends a Certificate message with a list of
three certificates (A, B, and C), and signs the ServerKeyExchange
message correctly with the public key found certificate A.
The client now takes the SHA-256 digest of the SPKI in cert A, and
compares it against both pins in the pinset. If either pin matches,
the verification is successful; the client continues with the TLS
connection and can make its first DNS query.
If neither pin matches the SPKI of cert A, the client verifies that
cert A is actually issued by cert B. If it is, it takes the SHA-256
digest of the SPKI in cert B and compares it against both pins in the
pinset. If either pin matches, the verification is successful.
Otherwise, it verifes that B was issued by C, and then compares the
pins against the digest of C's SPKI.
If none of the SPKIs in the cryptographically-valid chain of certs
match any pin in the pinset, the client closes the connection with an
error, and marks the IP address as failed.
Authors' Addresses