forked from tlswg/dnssec-chain-extension
-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-dukhovni-tls-dnssec-chain-04.xml
1463 lines (1406 loc) · 77.1 KB
/
draft-dukhovni-tls-dnssec-chain-04.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="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-dukhovni-tls-dnssec-chain-04" submissionType="independent" category="exp" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude">
<front>
<title abbrev="tls-dnssec-chain">TLS DNSSEC Chain Extension</title><seriesInfo value="draft-dukhovni-tls-dnssec-chain-04" stream="independent" status="experimental" name="Internet-Draft"></seriesInfo>
<author initials="V." surname="Dukhovni" fullname="Viktor Dukhovni"><organization>Two Sigma</organization><address><postal><street></street>
</postal><email>ietf-dane@dukhovni.org</email>
</address></author>
<author initials="S." surname="Huque" fullname="Shumon Huque"><organization>Salesforce</organization><address><postal><street>415 Mission Street, 3rd Floor</street>
<city>San Francisco</city>
<code>CA 94105</code>
<country>United States of America</country>
</postal><email>shuque@gmail.com</email>
</address></author>
<author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NLnet Labs</organization><address><postal><street>Science Park 400</street>
<city>Amsterdam</city>
<code>1098 XH</code>
<country>Netherlands</country>
</postal><email>willem@nlnetlabs.nl</email>
</address></author>
<author initials="P." surname="Wouters" fullname="Paul Wouters"><organization>No Hats</organization><address><postal><street></street>
<country>Canada</country>
</postal><email>paul@nohats.ca</email>
</address></author>
<author initials="M." surname="Shore" fullname="Melinda Shore"><organization>Fastly</organization><address><postal><street></street>
</postal><email>mshore@fastly.com</email>
</address></author>
<date year="2021" month="April" day="28"></date>
<area>Security</area>
<workgroup></workgroup>
<abstract>
<t>This document describes an experimental TLS extension for in-band
transport of the complete set of DNSSEC validated records needed to
perform DANE authentication of a TLS server without the need to
perform separate out-of-band DNS lookups. When the requisite DNS
records do not exist, the extension conveys a validated denial of
existence proof.</t>
<t>This experimental extension is developed outside the IETF and is
published here to guide implementation of the extension and to ensure
interoperability among implementations.</t>
</abstract>
</front>
<middle>
<section anchor="introduction"><name>Introduction</name>
<t>This document describes an experimental TLS <xref target="RFC5246"></xref><xref target="RFC8446"></xref>
extension for in-band transport of the complete set of DNSSEC
<xref target="RFC4033"></xref><xref target="RFC4034"></xref><xref target="RFC4035"></xref> validated Resource Records (RRs) that
enable a TLS client to perform DANE Authentication <xref target="RFC6698"></xref><xref target="RFC7671"></xref>
of a TLS server without the need to perform out-of-band DNS lookups.
Retrieval of the required DNS records may be unavailable to the client
<xref target="HAMPERING"></xref>, or may incur undesirable additional latency.</t>
<t>The extension described here allows a TLS client to request that the
TLS server return the DNSSEC authentication chain corresponding to
its DNSSEC-validated DANE TLSA Resource Record set (RRset), or
authenticated denial of existence of such an RRset (as described in
<xref target="denial_of_existence"></xref>). If the server supports this extension it
performs the appropriate DNS queries, builds the authentication
chain, and returns it to the client. The server will typically use a
previously cached authentication chain, but it will need to rebuild
it periodically as described in <xref target="sec_caching"></xref>. The client then
authenticates the chain using a pre-configured DNSSEC trust anchor.</t>
<t>In the absence of TLSA records, this extension conveys the
required authenticated denial of existence. Such proofs are needed to
securely signal that specified TLSA records are not available so that
TLS clients can safely fall back to WebPKI based authentication if
allowed by local policy. These proofs are also needed to avoid
downgrade from opportunistic authenticated TLS (when DANE TLSA
records are present) to unauthenticated opportunistic TLS (in the
absence of DANE). Denial of existence records are also used by the
TLS client to clear no longer relevant extension pins, as described
in <xref target="pinning"></xref>.</t>
<t>This extension supports DANE authentication of either X.509
certificates or raw public keys as described in the DANE
specification <xref target="RFC6698"></xref><xref target="RFC7671"></xref> and <xref target="RFC7250"></xref>.</t>
<t>This extension also mitigates against an unknown key share (UKS)
attack <xref target="I-D.barnes-dane-uks"></xref> when using raw public keys, since the
server commits to its DNS name (normally found in its certificate)
via the content of the returned TLSA RRset.</t>
<t>This experimental extension is developed outside the IETF and is
published here to guide implementation of the extension and to ensure
interoperability among implementations.</t>
<section anchor="scope-of-the-experiment"><name>Scope of the experiment</name>
<t>The mechanism described in this document, is intended to be done with
applications on the wider internet. One application of TLS well
suited for the TLS DNSSEC Chain extension is DNS over TLS <xref target="RFC7858"></xref>.
In fact, one of the authentication methods for DNS over TLS <em>is</em> the
mechanism described in this document, as specified in Section 8.2.2
of <xref target="RFC8310"></xref>.</t>
<t>The need for the mechanism when DANE authenticating DNS over TLS
resolver is obvious, since DNS may not be available to perform the
required DNS lookups. Other applications of TLS would benefit from
using this mechanism as well. The client sides of those applications
would not be required to be used on end-points with a working DNSSEC
resolver in order for them to use DANE authentication of the TLS
service. Therefore we invite other TLS services to try out this
mechanism as well.</t>
<t>In the TLS working group, concerns have been raised that the pinning
technique, as described in <xref target="pinning"></xref> would complicate deployability
of the TLS DNSSEC Chain extension. The goal of the experiment is to
study these complications in real world deployments. This experiment
hopefully will give the TLS working group some insight into whether
or not this is a problem.</t>
<t>If the experiment is successful, it is expected that the findings of
the experiment will result in an updated document for standards track
approval.</t>
</section>
<section anchor="requirements-notation"><name>Requirements Notation</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>",
"<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" 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>
</section>
</section>
<section anchor="dnssec-authentication-chain-extension"><name>DNSSEC Authentication Chain Extension</name>
<section anchor="protocol-tls-1-2"><name>Protocol, TLS 1.2</name>
<t>A client MAY include an extension of type <tt>dnssec_chain</tt> in the
(extended) ClientHello. The <tt>extension_data</tt> field of this extension
consists of the server's 16-bit TCP port number in network
(big-endian) byte order. Clients sending this extension MUST also
send the Server Name Identification (SNI, <xref target="RFC6066"></xref>)
extension. Together, these make it possible for the server to
determine which authenticated TLSA RRset chain needs to be used for
the <tt>dnssec_chain</tt> extension.</t>
<t>When a server that implements (and is configured to enable the use
of) this extension receives a <tt>dnssec_chain</tt> extension in the
ClientHello, it MUST first check whether the requested TLSA RRset
(based on the port number in this extension and hostname in the SNI
extension) is associated with the server. If the extension, the SNI
hostname or the port number is unsupported, the server's extended
ServerHello message MUST NOT include the <tt>dnssec_chain</tt> extension.</t>
<t>Otherwise, the server's extended ServerHello message MUST contain a
serialized authentication chain using the format described below. If
the server does not have access to the requested DNS chain - for
example due to a misconfiguration or expired chain - the server MUST
omit the extension rather than send an incomplete chain. Clients that
are expecting this extension MUST interpret this as a downgrade
attack and MUST abort the TLS session. Therefore, servers MUST send
denial of existence proofs, unless, for the particular application
protocol or service, clients are expected to continue even in the
absence of such a proof. As with all TLS extensions, if the server
does not support this extension it will not return any authentication
chain.</t>
<t>The set of supported combinations of port number and SNI name may be
configured explicitly by server administrators, or could be inferred
from the available certificates combined with a list of supported ports.
It is important to note that the client's notional port number may be
different from the actual port on which the server is receiving
connections.</t>
<t>Differences between the client's notional port number and the actual
port at the server could be a result of intermediate systems performing
network address translation, or perhaps a result of a redirect via HTTPS
or SVCB records (both defined in <xref target="I-D.ietf-dnsop-svcb-https"></xref>).</t>
<t>Though a DNS zone's HTTPS or SVCB records may be signed, a client
using this protocol might not have direct access to a validating resolver,
and might not be able to check the authenticity of the target port number
or hostname. In order to avoid downgrade attacks via forged DNS
records, the SNI name and port number inside the client extension MUST
be based on the original SNI name and port and MUST NOT be taken from
the encountered HTTPS or SVCB record. The client supporting this document
and HTTPS / SVCB records, MUST still use the HTTPS or SVCB records to
select the target transport endpoint. Servers supporting this extension
that are targets of HTTPS or SVCB records MUST be provisioned to process
client extensions based on the client's logical service endpoint's SNI
and port as it is prior to HTTPS or SVCB indirection.</t>
</section>
<section anchor="protocol-tls-1-3"><name>Protocol, TLS 1.3</name>
<t>In TLS 1.3 <xref target="RFC8446"></xref>, the server adds its <tt>dnssec_chain</tt> extension to the
extension block of the Certificate message containing the end entity
certificate being validated, rather than to the extended ServerHello
message.</t>
<t>The extension protocol behavior otherwise follows that specified for
TLS version 1.2 <xref target="RFC5246"></xref>.</t>
</section>
<section anchor="auth_chain_data"><name>DNSSEC Authentication Chain Data</name>
<t>The <tt>extension_data</tt> field of the client's <tt>dnssec_chain</tt> extension
MUST contain the server's 16-bit TCP port number in network
(big-endian) byte order:</t>
<artwork> struct {
uint16 PortNumber;
} DnssecChainExtension;
</artwork>
<t>The <tt>extension_data</tt> field of the server's <tt>dnssec_chain</tt> extension
MUST contain a DNSSEC Authentication Chain encoded in the following
form:</t>
<artwork> struct {
uint16 ExtSupportLifetime;
opaque AuthenticationChain<1..2^16-1>
} DnssecChainExtension;
</artwork>
<t>The ExtSupportLifetime value is the number of hours for which the TLS
server has committed itself to serving this extension. A value of
zero prohibits the client from unilaterally requiring ongoing use of
the extension based on prior observation of its use (extension
pinning). This is further described in <xref target="pinning"></xref>.</t>
<t>The AuthenticationChain is composed of a sequence of uncompressed
wire format DNS RRs (including all requisite RRSIG <xref target="RFC4034"></xref> RRs)
in no particular order. The format of the Resource Record is
described in <xref target="RFC1035"></xref>, Section 3.2.1.</t>
<artwork> RR = { owner, type, class, TTL, RDATA length, RDATA }
</artwork>
<t>The order of returned RRs is unspecified and a TLS client MUST NOT
assume any ordering of RRs.</t>
<t>Use of native DNS wire format records enables easier generation of
the data structure on the server and easier verification of the data
on client by means of existing DNS library functions.</t>
<t>The returned RRsets MUST contain either the requested TLSA RRset, or
else the associated denial of existence proof. In either case, the
chain of RRs MUST be accompanied with the full set of DNS records
needed to authenticate the TLSA record set or its denial of existence
up the DNS hierarchy to either the Root Zone or another trust anchor
mutually configured by the TLS server and client.</t>
<t>When some subtree in the chain is subject to redirection via DNAME
records, the associated inferred CNAME records need not be included,
they can be inferred by the DNS validation code in the client. Any
applicable ordinary CNAME records that are not synthesized from DNAME
records MUST be included along with their RRSIGs.</t>
<t>In case of a server-side DNS problem, servers may be unable to construct
the authentication chain and would then have no choice but to omit the
extension.</t>
<t>In the case of a denial of existence response, the authentication
chain MUST include all DNSSEC signed records from the trust-anchor
zone to a proof of non-existence of either the (possibly redirected
via aliases) TLSA records or else of an insecure delegation above or
at the (possibly redirected) owner name of the requested TLSA RRset.</t>
<t>Names that are aliased via CNAME and/or DNAME records may involve
multiple branches of the DNS tree. In this case, the authentication
chain structure needs to include DS and DNSKEY record sets that cover
all the necessary branches.</t>
<t>The returned chain should also include the DNSKEY RRSets of all relevant
trust anchors (typically just the root DNS zone). Though the same trust
anchors are presumably also preconfigured in the TLS client, including
them in the response from the server permits TLS clients to use the
automated trust anchor rollover mechanism defined in <xref target="RFC5011"></xref> to
update their configured trust anchors.</t>
<t>Barring prior knowledge of particular trust anchors that the server
shares with its clients, the chain constructed by the server MUST be
extended as close as possible to the root zone. Truncation of the chain
at some intermediate trust anchor is generally only appropriate inside
private networks where all clients and the server are expected to be
configured with DNS trust anchors for one or more non-root domains.</t>
<t>The following is an example of the records in the AuthenticationChain
structure for the HTTPS server at <tt>www.example.com</tt>, where there are
zone cuts at <tt>com.</tt> and <tt>example.com.</tt> (record data are omitted here
for brevity):</t>
<artwork>_443._tcp.www.example.com. TLSA
RRSIG(_443._tcp.www.example.com. TLSA)
example.com. DNSKEY
RRSIG(example.com. DNSKEY)
example.com. DS
RRSIG(example.com. DS)
com. DNSKEY
RRSIG(com. DNSKEY)
com. DS
RRSIG(com. DS)
. DNSKEY
RRSIG(. DNSKEY)
</artwork>
<t>The following is an example of denial of existence for a TLSA RRset
at <tt>_443._tcp.www.example.com</tt>. The NSEC record in this example
asserts the non-existence of both the requested RRset and any
potentially relevant wildcard records.</t>
<artwork>www.example.com. IN NSEC example.com. A NSEC RRSIG
RRSIG(www.example.com. NSEC)
example.com. DNSKEY
RRSIG(example.com. DNSKEY)
example.com. DS
RRSIG(example.com. DS)
com. DNSKEY
RRSIG(com. DNSKEY)
com. DS
RRSIG(com. DS)
. DNSKEY
RRSIG(. DNSKEY)
</artwork>
<t>The following is an example of (hypothetical) insecure delegation of
<tt>example.com</tt> from the <tt>.com</tt> zone. This example shows NSEC3 records
with opt-out.</t>
<artwork>; covers example.com
onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 -
onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG)
RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3)
; covers *.com
3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 -
3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG)
RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3)
; closest-encloser "com"
ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 -
ck0pojmg874ljref7efn8430qvit8bsm.com
NS SOA RRSIG DNSKEY NSEC3PARAM)
RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3)
com. DNSKEY
RRSIG(com. DNSKEY)
com. DS
RRSIG(com. DS)
. DNSKEY
RRSIG(. DNSKEY)
</artwork>
<section anchor="denial_of_existence"><name>Authenticated Denial of Existence</name>
<t>TLS servers supporting this extension that do not have a signed TLSA
record MUST instead return a DNSSEC chain that provides authenticated
denial of existence. A TLS client receiving proof of authenticated
denial of existence MUST use an alternative method to verify the TLS
server identity or close the connection. Such an alternative could be
the classic WebPKI model of preinstalled root CA's.</t>
<t>Authenticated denial chains include NSEC or NSEC3 records that
demonstrate one of the following facts:</t>
<ul>
<li><t>The TLSA record (after any DNSSEC validated alias redirection)
does not exist.</t>
</li>
<li><t>There is no signed delegation to a DNS zone which is either an
ancestor of, or the same as, the TLSA record name (after any
DNSSEC validated alias redirection).</t>
</li>
</ul>
</section>
</section>
</section>
<section anchor="construction"><name>Construction of Serialized Authentication Chains</name>
<t>This section describes a possible procedure for the server to use to
build the serialized DNSSEC chain.</t>
<t>When the goal is to perform DANE authentication <xref target="RFC6698"></xref><xref target="RFC7671"></xref>
of the server, the DNS record set to be serialized is a TLSA record
set corresponding to the server's domain name, protocol, and port
number.</t>
<t>The domain name of the server MUST be that included in the TLS
<tt>server_name</tt> (SNI) extension <xref target="RFC6066"></xref>. If the server
does not recognize the SNI name as one if its own names, but wishes
to proceed with the handshake rather than to abort the connection,
the server MUST NOT send a <tt>dnssec_chain</tt> extension to the client.</t>
<t>The name in client's SNI extension MUST NOT be CNAME-expanded by the
server. The TLSA base domain (Section 3 of <xref target="RFC6698"></xref>) SHALL be the
hostname from the client's SNI extension and the guidance in Section
7 of <xref target="RFC7671"></xref> does not apply. See <xref target="virtual"></xref> for further
discussion.</t>
<t>The TLSA record to be queried is constructed by prepending
underscore-prefixed port number and transport name labels to the domain
name as described in <xref target="RFC6698"></xref>. The port number is taken from the
client's <tt>dnssec_chain</tt> extension. The transport name is "tcp" for TLS
servers, and "udp" for DTLS servers. The port number label is the
left-most label, followed by the transport name label, followed by the
server domain name (from SNI).</t>
<t>The components of the authentication chain are typically built by
starting at the target record set and its corresponding RRSIG. Then
traversing the DNS tree upwards towards the trust anchor zone
(normally the DNS root). For each zone cut, the DNSKEY and DS RRsets
and their signatures are added. However, see <xref target="auth_chain_data"></xref> for
specific processing needed for aliases. If DNS response messages
contain any domain names utilizing name compression <xref target="RFC1035"></xref>, then
they MUST be uncompressed prior to inclusion in the chain.</t>
<t>Implementations of EDNS Chain Query Requests as specified in
<xref target="RFC7901"></xref> may offer an easier way to obtain all of the chain data
in one transaction with an upstream DNSSEC aware recursive server.</t>
</section>
<section anchor="sec_caching"><name>Caching and Regeneration of the Authentication Chain</name>
<t>DNS records have Time To Live (TTL) parameters, and DNSSEC signatures
have validity periods (specifically signature expiration times).
After the TLS server constructs the serialized authentication chain,
it SHOULD cache and reuse it in multiple TLS connection handshakes.
However, it SHOULD refresh and rebuild the chain as TTL values require.
A server implementation could carefully track TTL parameters and requery
component records in the chain correspondingly. Alternatively, it could
be configured to rebuild the entire chain at some predefined periodic
interval that does not exceed the DNS TTLs of the component records in
the chain. If a record in the chain has a very short TTL (eg 0 up to a
few seconds), the server MAY decide to serve the authentication chain a
few seconds past the minimum TTL in the chain. This allows an
implementation to dedicate a process or single thread to building the
authentication chain and re-use it for more than a single
waiting TLS client before needing to rebuild the authentication chain.</t>
</section>
<section anchor="sec_caching_exp"><name>Expired signatures in the Authentication Chain</name>
<t>A server MAY look at the signature expiration of RRSIG records. While
these should never expire before the TTL of the corresponding DNS record
is reached, if this situation is encountered nevertheless, the server
MAY lower the TTL to prevent serving expired RRSIGs if possible. If the
signatures are already expired, the server MUST still include these records
into the authentication chain. This allows the TLS client to either support
a grace period for staleness, or allows the TLS client to give a detailed
error, either as log message or to a potential interactive user of the TLS
connection. The TLS client SHOULD handle expired RRSIGs similar to how it
handles expired PKIX certificates.</t>
</section>
<section anchor="sec_verification"><name>Verification</name>
<t>A TLS client performing DANE based verification might not need to use
this extension. For example, the TLS client could perform native DNS
lookups and perform DANE verification without this extension. Or it
could fetch authentication chains via another protocol. If the TLS
client already possesses a valid TLSA record, it MAY omit using this
extension. However, if it includes this extension, it MUST use the
TLS server reply to update the extension pinning status of the TLS
server's extension lifetime. See <xref target="pinning"></xref>.</t>
<t>A TLS client making use of this specification, and which receives a
valid DNSSEC authentication chain extension from a server, MUST use
this information to perform DANE authentication of the server. In
order to perform the validation, it uses the mechanism specified by
the DNSSEC protocol <xref target="RFC4035"></xref><xref target="RFC5155"></xref>. This mechanism is
sometimes implemented in a DNSSEC validation engine or library.</t>
<t>If the authentication chain validates, the client then performs DANE
authentication of the server according to the DANE TLS protocol
<xref target="RFC6698"></xref><xref target="RFC7671"></xref>.</t>
<t>Clients MAY cache the server's validated TLSA RRset to amortize the
cost of receiving and validating the chain over multiple connections.
The period of such caching MUST NOT exceed the TTL associated with
those records. A client that possesses a validated and unexpired TLSA
RRset or the full chain in its cache does not need to send the
<tt>dnssec_chain</tt> extension for subsequent connections to the same TLS
server. It can use the cached information to perform DANE
authentication.</t>
<t>Note that when a client and server perform TLS session resumption the
server sends no <tt>dnssec_chain</tt>. This is particularly clear with TLS
1.3, where the certificate message to which the chain might be
attached is also not sent on resumption.</t>
</section>
<section anchor="pinning"><name>Extension Pinning</name>
<t>TLS applications can be designed to unconditionally mandate this
extension. Such TLS clients requesting this extension would abort a
connection to a TLS server that does not respond with a validatable
extension reply.</t>
<t>However, in a mixed-use deployment of WebPKI and DANE, there is the
possibility that the security of a TLS client is downgraded from DANE
to WebPKI. This can happen when a TLS client connection is
intercepted and redirected to a rogue TLS server presenting a TLS
certificate that is considered valid from a WebPKI point of view, but
one that does not match the legitimate server's TLSA records. By
omitting this extension, such a rogue TLS server could downgrade the
TLS client to validate the mis-issued certificate using only the
WebPKI and not via DANE, provided the TLS client is also not able to
fetch the TLSA records directly from DNS.</t>
<t>The ExtSupportLifetime element of the extension provides a
counter-measure against such downgrade attacks. It's value represents
the number of hours that the TLS server (or cluster of servers
serving the same Server Name) commit to serving this extension in the
future. This is referred to as the "pinning time" or "extension pin"
of the extension. A non-zero extension pin value received MUST ONLY
be used if the extension also contains a valid TLSA authentication
chain that matches the server's certificate chain (the server passes
DANE authentication based on the enclosed TLSA RRset).</t>
<t>Any existing extension pin for the server instance (name and port)
MUST be cleared on receipt of a valid denial of existence for the
associated TLSA RRset. The same also applies if the client obtained
the denial of existence proof via another method, such as through
direct DNS queries. Based on the TLS client's local policy, it MAY
then terminate the connection or MAY continue using WebPKI based
server authentication.</t>
<t>Extension pins MUST also be cleared upon the completion of a DANE
authenticated handshake with a server that returns a <tt>dnssec_chain</tt>
extension with a zero ExtSupportLifetime.</t>
<t>Upon completion of a full validated handshake with a server that
returns a <tt>dnssec_chain</tt> extension with a non-zero ExtSupport lifetime,
the client MUST update any existing pin lifetime for the service
(name and port) to a value that is no longer than that indicated by
the server. The client MAY, subject to local policy, create a
previously non-existent pin, again for a lifetime that is not longer
than that indicated by the server.</t>
<t>The extension support lifetime is not constrained by any DNS TTLs or
RRSIG expirations in the returned chain. The extension support lifetime
is the time for which the TLS server is committing itself to serve the
extension; it is not a validity time for the returned chain data.
During this period the DNSSEC chain may be updated. Therefore, the
ExtSupportLifetime value is not constrained by any DNS TTLs or RRSIG
expirations in the returned chain.</t>
<t>Clients MAY implement support for a subset of DANE certificate
usages. For example, clients may support only DANE-EE(3) and
DANE-TA(2) <xref target="RFC7218"></xref>, only PKIX-EE(1) and PKIX-TA(0)
or all four. Clients that implement DANE-EE(3) and DANE-TA(2) MUST
implement the relevant updates in <xref target="RFC7671"></xref>.</t>
<t>For a non-zero saved value of the ExtSupportLifetime element of the
extension, TLS clients MUST mandate ("pin") the use of this extension
by the corresponding TLS servers for the time period specified by the
pinning value. If during this time, the TLS client does not have a
valid TLSA record and connects to a TLS server using this extension
for the associated name and port, and it does not obtain a valid
authentication chain in this extension, it MUST either abort the
connection or delay communication with the server via the TLS session
until it is able to obtain valid TLSA records (or non-existence
proof) out of band, such as via direct DNS lookups. If attempts to
obtain the TLSA RRset out of band fail, the client MUST abort the TLS
session.</t>
<t>Note that requiring the extension is NOT the same as requiring the
use of DANE TLSA records or even DNSSEC. A DNS zone operator may at
any time delete the TLSA records, or even remove the DS records to
disable the secure delegation of the server's DNS zone. The TLS
server will, when it updates its cached TLSA authentication chain,
replace the chain with the corresponding denial of existence chain.
The server's only obligation is continued support for this extension.</t>
</section>
<section anchor="sec_trustmaint"><name>Trust Anchor Maintenance</name>
<t>The trust anchor may change periodically, e.g. when the operator of
the trust anchor zone performs a DNSSEC key rollover. TLS clients
using this specification MUST implement a mechanism to keep their
trust anchors up to date. They could use the method defined in
<xref target="RFC5011"></xref> to perform trust anchor updates inband in TLS, by tracking
the introduction of new keys seen in the trust anchor DNSKEY RRset.
However, alternative mechanisms external to TLS may also be utilized.
Some operating systems may have a system-wide service to maintain and
keep the root trust anchor up to date. In such cases, the TLS client
application could simply reference that as its trust anchor,
periodically checking whether it has changed. Some applications may
prefer to implement trust anchor updates as part of their automated
software updates.</t>
</section>
<section anchor="virtual"><name>Virtual Hosting</name>
<t>Delivery of application services is often provided by a third party
on behalf of the domain owner (hosting customer). Since the domain
owner may want to be able to move the service between providers,
non-zero support lifetimes for this extension should only be enabled
by mutual agreement between the provider and domain owner.</t>
<t>When CNAME records are employed to redirect network connections to
the provider's network, as mentioned in <xref target="construction"></xref> the server
uses the client's SNI hostname as the TLSA base domain without CNAME
expansion. When the certificate chain for the service is managed by
the provider, it is impractical to coordinate certificate changes by
the provider with updates in the hosting customer's DNS. Therefore,
the TLSA RRset for the hosted domain is best configured as a CNAME
from the customer's domain to a TLSA RRset that is managed by the
provider as part of delivering the hosted service. For example:</t>
<artwork>; Customer DNS
www.example.com. IN CNAME node1.provider.example.
_443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example.
; Provider DNS
node1.provider.example. IN A 192.0.2.1
_dane443.node1.provider.example. IN TLSA 1 1 1 ...
</artwork>
<t>Clients that obtain TLSA records directly from DNS, bypassing this
extension, may however perform CNAME-expansion as in Section 7 of
<xref target="RFC7671"></xref>, and if TLSA records are associated with the
fully-expanded name, may use that name as the TLSA base domain and
SNI name for the TLS handshake.</t>
<t>To avoid confusion, it is RECOMMENDED that server operators not
publish TLSA RRs (_port._tcp. + base domain) based on the expanded
CNAMEs used to locate their network addresses. Instead, the server
operator SHOULD publish TLSA RRs at an alternative DNS node (as in
the example above), to which the hosting customer will publish a
CNAME alias. This results in all clients (whether they obtain TLSA
records from DNS directly, or employ this extension) seeing the same
TLSA records and sending the same SNI name.</t>
</section>
<section anchor="operational-considerations"><name>Operational Considerations</name>
<t>When DANE is being introduced incrementally into an existing PKIX
environment, there may be scenarios in which DANE authentication for
a server fails but PKIX succeeds, or vice versa. What happens here
depends on TLS client policy. If DANE authentication fails, the
client may decide to fall back to traditional PKIX authentication. In
order to do so efficiently within the same TLS handshake, the TLS
server needs to have provided the full X.509 certificate chain. When
TLS servers only support DANE-EE or DANE-TA modes, they have the
option to send a much smaller certificate chain: just the EE
certificate for the former, and a short certificate chain from the
DANE trust anchor to the EE certificate for the latter. If the TLS
server supports both DANE and traditional PKIX, and wants to allow
efficient PKIX fallback within the same handshake, they should always
provide the full X.509 certificate chain.</t>
<t>When a TLS server operator wishes to no longer deploy this extension,
it must properly decommission its use. If a non-zero pin lifetime is
presently advertised, it must first be changed to 0. The extension
can be disabled once all previously advertised pin lifetimes have
expired. Removal of TLSA records or even DNSSEC signing of the zone
can be done at any time, but the server MUST still be able to return
the associated denial of existence proofs to any clients that have
unexpired pins.</t>
<t>TLS clients MAY reduce the received extension pin value to a maximum
set by local policy. This can mitigate a theoretical yet unlikely
attack where a compromised TLS server is modified to advertise a pin
value set to the maximum of 7 years. Care should be taken not to set
a local maximum that is too short as that would reduce the downgrade
attack protection that the extension pin offers.</t>
<t>If the hosting provider intends to use end-entity TLSA records
(certificate usage PKIX-EE(1) or DANE-EE(3)) then the simplest
approach is to use the same key-pair for all the certificates at a
given hosting node, and publish "1 1 1" or "3 1 1" RRs matching the
common public key. Since key rollover cannot be simultaneous across
multiple certificate updates, there will be times when multiple "1 1
1" (or "3 1 1") records will be required to match all the extant
certificates. Multiple TLSA records are in any case needed a few
TTLs before certificate updates as explained in Section 8 of
<xref target="RFC7671"></xref>.</t>
<t>If the hosting provider intends to use trust-anchor TLSA records
(certificate usage PKIX-TA(0) or DANE-TA(2)) then the same TLSA
record can match all end-entity certificates issues by the
certification authority in question, and continues to work across
end-entity certificate updates, so long as the issuer certificate or
public keys remains unchanged. This can be easier to implement, at
the cost of greater reliance on the security of the selected
certification authority.</t>
<t>The provider can of course publish separate TLSA records for each
customer, which increases the number of such RRsets that need to be
managed, but makes each one independent of the rest.</t>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>The security considerations of the normatively referenced RFCs all
pertain to this extension. Since the server is delivering a chain of
DNS records and signatures to the client, it MUST rebuild the chain
in accordance with TTL and signature expiration of the chain
components as described in <xref target="sec_caching"></xref>. TLS clients
need roughly accurate time in order to properly authenticate these
signatures. This could be achieved by running a time synchronization
protocol like NTP <xref target="RFC5905"></xref> or SNTP <xref target="RFC5905"></xref>, which are already widely used today. TLS clients
MUST support a mechanism to track and roll over the trust anchor key,
or be able to avail themselves of a service that does this, as
described in <xref target="sec_trustmaint"></xref>. Security
considerations related to mandating the use of this extension are
described in <xref target="pinning"></xref>.</t>
</section>
<section anchor="iana_requests"><name>IANA Considerations</name>
<t>This document defines one new entry in the TLS ExtensionType Values
registry:</t>
<table>
<thead>
<tr>
<th align="right">Value</th>
<th>Extension Name</th>
<th>TLS 1.3</th>
<th>Recommended</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">TBD</td>
<td>dnssec_chain</td>
<td>CH</td>
<td>No</td>
<td>[this document]</td>
</tr>
</tbody>
</table></section>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>Many thanks to Adam Langley for laying the groundwork for this
extension in <xref target="I-D.agl-dane-serializechain"></xref>. The original idea is his
but our acknowledgment in no way implies his endorsement. This
document also benefited from discussions with and review from the
following people: Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin,
Patrick McManus, Rick van Rein, Ilari Liusvaara, Eric Rescorla, Gowri
Visweswaran, Duane Wessels, Nico Williams, and Richard Barnes.</t>
</section>
</middle>
<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dnsop-svcb-https.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7218.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7671.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="HAMPERING" target="http://www.nlnetlabs.nl/downloads/publications/os3-2015-rp2-xavier-torrent-gorjon.pdf">
<front>
<title>Discovery method for a DNSSEC validating stub resolver</title>
<author fullname="Xavier Torrent Gorjon" initials="X." surname="Gorjon"></author>
<author fullname="Willem Toorop" initials="W." surname="Toorop"></author>
<date year="2015" month="July" day="14"></date>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.agl-dane-serializechain.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.barnes-dane-uks.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5011.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7901.xml"/>
</references>
<section anchor="test-vectors"><name>Test Vectors</name>
<t>The test vectors in this appendix are representations of the content
of the "opaque AuthenticationChain" field in DNS presentation format.
And except for the <tt>extention_data</tt> in <xref target="hex_dump"></xref>, do not contain
the "uint16 ExtSupportLifetime" field.</t>
<t>For brevity and reproducibility all DNS zones involved with the test
vectors are signed using keys with algorithm 13: ECDSA Curve P-256
with SHA-256.</t>
<t>To reflect operational practice, different zones in the examples are
in different phases of rolling their signing keys:</t>
<ul>
<li><t>All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK),
except for the example.com and example.net zones which use a
Combined Signing Key (CSK).</t>
</li>
<li><t>The root and org zones are rolling their ZSK's.</t>
</li>
<li><t>The com and org zones are rolling their KSK's.</t>
</li>
</ul>
<t>The test vectors are DNSSEC valid in the same period as the
certificate is valid, which is in between November 28 2018 and
December 2 2020, with the following root trust anchor:</t>
<artwork>. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634
641bb568746f2ffc4d4 )
</artwork>
<t>The test vectors will authenticate the certificate used with
<eref target="https://example.com/">https://example.com/</eref>, <eref target="https://example.net/">https://example.net/</eref> and <eref target="https://example.org/">https://example.org/</eref>
at the time of writing:</t>
<artwork>-----BEGIN CERTIFICATE-----
MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcN
MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju
aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw
b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsT
ClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV
rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5g
rJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80
eyRJRqzy8I0LSPTTkhr3okXuzOXXg38ugr1x3SgZWDNuEaE6oGpyYJIBWZ9jF3pJ
QnucP9vTBejMh374qvyd0QVQq3WxHrogy4nUbWw3gihMxT98wRD1oKVma1NTydvt
hcNtBfhkp8kO64/hxLHrLWgOFT/l4tz8IWQt7mkrBHjbd2XLVPkCAwEAAaOCA8Ew
ggO9MB8GA1UdIwQYMBaAFA+AYRyCMWHVLyjnjUY4tCzhxtniMB0GA1UdDgQWBBRm
mGIC4AmRp9njNvt2xrC/oW2nvjCBgQYDVR0RBHoweIIPd3d3LmV4YW1wbGUub3Jn
ggtleGFtcGxlLmNvbYILZXhhbXBsZS5lZHWCC2V4YW1wbGUubmV0ggtleGFtcGxl
Lm9yZ4IPd3d3LmV4YW1wbGUuY29tgg93d3cuZXhhbXBsZS5lZHWCD3d3dy5leGFt
cGxlLm5ldDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMGsGA1UdHwRkMGIwL6AtoCuGKWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNv
bS9zc2NhLXNoYTItZzYuY3JsMC+gLaArhilodHRwOi8vY3JsNC5kaWdpY2VydC5j
b20vc3NjYS1zaGEyLWc2LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgG
CCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAEC
AjB8BggrBgEFBQcBAQRwMG4wJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj
ZXJ0LmNvbTBGBggrBgEFBQcwAoY6aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29t
L0RpZ2lDZXJ0U0hBMlNlY3VyZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIB
fwYKKwYBBAHWeQIEAgSCAW8EggFrAWkAdwCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb
37jjd80OyA3cEAAAAWdcMZVGAAAEAwBIMEYCIQCEZIG3IR36Gkj1dq5L6EaGVycX
sHvpO7dKV0JsooTEbAIhALuTtf4wxGTkFkx8blhTV+7sf6pFT78ORo7+cP39jkJC
AHYAh3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8AAAFnXDGWFQAABAMA
RzBFAiBvqnfSHKeUwGMtLrOG3UGLQIoaL3+uZsGTX3MfSJNQEQIhANL5nUiGBR6g
l0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkC
wQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7z
RDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKM
MA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R
8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZM
v1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQu
N+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIa
X6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I
0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN
-----END CERTIFICATE-----
</artwork>
<section anchor="tv-straight"><name>_443._tcp.www.example.com</name>
<artwork>_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
20201202000000 20181128000000 1870 example.com.
rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S
z2BhaswpGLVVuoijuVdzxYjmw== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 1870 example.com.
nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
QHPGSpvRxTUC4tZi62z1UgGDw== )
example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd
25a986e8a44f319ac3cd302bafc08f5b81e16)
example.com. 172800 IN RRSIG ( DS 13 2 172800
20201202000000 20181128000000 34327 com.
sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
J1hhWSB6jgubEVl17rGNOA/YQ== )
com. 172800 IN DNSKEY ( 256 3 13
7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
com. 172800 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 172800 IN DNSKEY ( 257 3 13
szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 18931 com.
LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
7LFdPKpcvb8BvhM+GqKWGBEsg== )
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 28809 com.
sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
mDXqz6KEhhQjT+aQWDt6WFHlA== )
com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
f9eabb94487e658c188e7bcb52115 )
com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
70643bbde681db342a9e5cf2bb380 )
com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
vBKTf6pk8JRCqnfzlo2QY+WXA== )
. 86400 IN DNSKEY ( 256 3 13
zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
. 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== )
</artwork>
<t>A hex dump of the <tt>extension_data</tt> of the server's <tt>dnssec_chain</tt>
extension represention this with an ExtSupportLifetime value of 0 is:</t>
<artwork anchor="hex_dump">0000: 00 00 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77
0010: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00
0020: 01 00 00 0e 10 00 23 03 01 01 8b d1 da 95 27 2f
0030: 7f a4 ff b2 41 37 fc 0e d0 3a ae 67 e5 c4 d8 b3
0040: c5 07 34 e1 05 0a 79 20 b9 22 04 5f 34 34 33 04
0050: 5f 74 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65
0060: 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00
0070: 34 0d 05 00 00 0e 10 5f c6 d9 00 5b fd da 80 07
0080: 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ce 1d
0090: 3a de b7 dc 7c ee 65 6d 61 cf b4 72 c5 97 7c 8c
00a0: 9c ae ae 9b 76 51 55 c5 18 fb 10 7b 6a 1f e0 35
00b0: 5f ba af 75 3c 19 28 32 fa 62 1f a7 3a 8b 85 ed
00c0: 79 d3 74 11 73 87 59 8f cc 81 2e 1e f3 fb 07 65
00d0: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00
00e0: 00 0e 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d
00f0: 9c fe a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25
0100: 12 d8 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51
0110: ce b9 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be
0120: 5b 2e 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c
0130: 65 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f
0140: 00 30 0d 02 00 00 0e 10 5f c6 d9 00 5b fd da 80
0150: 07 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 46
0160: 28 38 30 75 b8 e3 4b 74 3a 20 9b 27 ae 14 8d 11
0170: 0d 4e 1a 24 61 38 a9 10 83 24 9c b4 a1 2a 2d 9b
0180: c4 c2 d7 ab 5e b3 af b9 f5 d1 03 7e 4d 5d a8 33
0190: 9c 16 2a 92 98 e9 be 18 07 41 a8 ca 74 ac cc 07
01a0: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01
01b0: 00 02 a3 00 00 24 07 4e 0d 02 e9 b5 33 a0 49 79
01c0: 8e 90 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac
01d0: 3c d3 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70
01e0: 6c 65 03 63 6f 6d 00 00 2e 00 01 00 02 a3 00 00
01f0: 57 00 2b 0d 02 00 02 a3 00 5f c6 d9 00 5b fd da
0200: 80 86 17 03 63 6f 6d 00 a2 03 e7 04 a6 fa cb eb
0210: 13 fc 93 84 fd d6 de 6b 50 de 56 59 27 1f 38 ce
0220: 81 49 86 84 e6 36 31 72 d4 7e 23 19 fd b4 a2 2a
0230: 58 a2 31 ed c2 f1 ff 4f b2 81 1a 18 07 be 72 cb
0240: 52 41 aa 26 fd ae e0 39 03 63 6f 6d 00 00 30 00
0250: 01 00 02 a3 00 00 44 01 00 03 0d ec 82 04 e4 3a
0260: 25 f2 34 8c 52 a1 d3 bc e3 a2 65 aa 5d 11 b4 3d
0270: c2 a4 71 16 2f f3 41 c4 9d b9 f5 0a 2e 1a 41 ca
0280: f2 e9 cd 20 10 4e a0 96 8f 75 11 21 9f 0b dc 56
0290: b6 80 12 cc 39 95 33 67 51 90 0b 03 63 6f 6d 00
02a0: 00 30 00 01 00 02 a3 00 00 44 01 01 03 0d 45 b9
02b0: 1c 3b ef 7a 5d 99 a7 a7 c8 d8 22 e3 38 96 bc 80
02c0: a7 77 a0 42 34 a6 05 a4 a8 88 0e c7 ef a4 e6 d1
02d0: 12 c7 3c d3 d4 c6 55 64 fa 74 34 7c 87 37 23 cc
02e0: 5f 64 33 70 f1 66 b4 3d ed ff 83 64 00 ff 03 63
02f0: 6f 6d 00 00 30 00 01 00 02 a3 00 00 44 01 01 03
0300: 0d b3 37 3b 6e 22 e8 e4 9e 0e 1e 59 1a 9f 5b d9
0310: ac 5e 1a 0f 86 18 7f e3 47 03 f1 80 a9 d3 6c 95
0320: 8f 71 c4 af 48 ce 0e bc 5c 79 2a 72 4e 11 b4 38
0330: 95 93 7e e5 34 04 26 81 29 47 6e b1 ae d3 23 93
0340: 90 03 63 6f 6d 00 00 2e 00 01 00 02 a3 00 00 57
0350: 00 30 0d 01 00 02 a3 00 5f c6 d9 00 5b fd da 80
0360: 49 f3 03 63 6f 6d 00 18 a9 48 eb 23 d4 4f 80 ab
0370: c9 92 38 fc b4 3c 5a 18 de be 57 00 4f 73 43 59
0380: 3f 6d eb 6e d7 1e 04 65 4a 43 3f 7a a1 97 21 30
0390: d9 bd 92 1c 73 dc f6 3f cf 66 5f 2f 05 a0 aa eb
03a0: af b0 59 dc 12 c9 65 03 63 6f 6d 00 00 2e 00 01
03b0: 00 02 a3 00 00 57 00 30 0d 01 00 02 a3 00 5f c6
03c0: d9 00 5b fd da 80 70 89 03 63 6f 6d 00 61 70 e6
03d0: 95 9b d9 ed 6e 57 58 37 b6 f5 80 bd 99 db d2 4a
03e0: 44 68 2b 0a 35 96 26 a2 46 b1 81 2f 5f 90 96 b7
03f0: 5e 15 7e 77 84 8f 06 8a e0 08 5e 1a 60 9f c1 92
0400: 98 c3 3b 73 68 63 fb cc d4 d8 1f 5e b2 03 63 6f
0410: 6d 00 00 2b 00 01 00 01 51 80 00 24 49 f3 0d 02
0420: 20 f7 a9 db 42 d0 e2 04 2f bb b9 f9 ea 01 59 41
0430: 20 2f 9e ab b9 44 87 e6 58 c1 88 e7 bc b5 21 15
0440: 03 63 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 70
0450: 89 0d 02 ad 66 b3 27 6f 79 62 23 aa 45 ed a7 73
0460: e9 2c 6d 98 e7 06 43 bb de 68 1d b3 42 a9 e5 cf
0470: 2b b3 80 03 63 6f 6d 00 00 2e 00 01 00 01 51 80
0480: 00 53 00 2b 0d 01 00 01 51 80 5f c6 d9 00 5b fd
0490: da 80 7c ae 00 12 2e 27 6d 45 d9 e9 81 6f 79 22
04a0: ad 6e a2 e7 3e 82 d2 6f ce 0a 4b 71 86 25 f3 14
04b0: 53 1a c9 2f 8a e8 24 18 df 9b 89 8f 98 9d 32 e8
04c0: 0b c4 de ab a7 c4 a7 c8 f1 72 ad b5 7c ed 7f b5
04d0: e7 7a 78 4b 07 00 00 30 00 01 00 01 51 80 00 44
04e0: 01 00 03 0d cc ac fe 0c 25 a4 34 0f ef ba 17 a2
04f0: 54 f7 06 aa c1 f8 d1 4f 38 29 90 25 ac c4 48 ca
0500: 8c e3 f5 61 f3 7f c3 ec 16 9f e8 47 c8 fc be 68
0510: e3 58 ff 7c 71 bb 5e e1 df 0d be 51 8b c7 36 d4
0520: ce 8d fe 14 00 00 30 00 01 00 01 51 80 00 44 01
0530: 00 03 0d f3 03 19 67 89 73 1d dc 8a 67 87 ef f2
0540: 4c ac fe dd d0 32 58 2f 11 a7 5b b1 bc aa 5a b3
0550: 21 c1 d7 52 5c 26 58 19 1a ec 01 b3 e9 8a b7 91
0560: 5b 16 d5 71 dd 55 b4 ea e5 14 17 11 0c c4 cd d1
0570: 1d 17 11 00 00 30 00 01 00 01 51 80 00 44 01 01
0580: 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad
0590: 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 42
05a0: 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 bd
05b0: 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 63
05c0: ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30 0d
05d0: 00 00 01 51 80 5f c6 d9 00 5b fd da 80 b7 9d 00
05e0: de 7a 67 40 ee ec ba 4b da 1e 5c 2d d4 89 9b 2c
05f0: 96 58 93 f3 78 6c e7 47 f4 1e 50 d9 de 8c 0a 72
0600: df 82 56 0d fb 48 d7 14 de 32 83 ae 99 a4 9c 0f
0610: cb 50 d3 aa ad b1 a3 fc 62 ee 3a 8a 09 88 b6 be
</artwork>
</section>
<section anchor="tv-wildcard-nsec"><name>_25._tcp.example.com NSEC wildcard</name>
<artwork>_25._tcp.example.com. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 )
_25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600
20201202000000 20181128000000 1870 example.com.
BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2
rfL4DFP8rO3VMgI0v+ogrox0w== )
*._tcp.example.com. 3600 IN NSEC ( smtp.example.com. RRSIG
NSEC TLSA )
*._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600
20201202000000 20181128000000 1870 example.com.
K6u8KrR8ca5bjtbce3w8yjMXr9vw12225lAwyIHpxptY43OMLCUCenwpYW5qd
mpFvAacqj4+tSkKiN279SI9pA== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 1870 example.com.
nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
QHPGSpvRxTUC4tZi62z1UgGDw== )
example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd
25a986e8a44f319ac3cd302bafc08f5b81e16 )
example.com. 172800 IN RRSIG ( DS 13 2 172800
20201202000000 20181128000000 34327 com.
sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
J1hhWSB6jgubEVl17rGNOA/YQ== )
com. 172800 IN DNSKEY ( 256 3 13
7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
com. 172800 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 172800 IN DNSKEY ( 257 3 13
szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 18931 com.
LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
7LFdPKpcvb8BvhM+GqKWGBEsg== )
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 28809 com.
sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
mDXqz6KEhhQjT+aQWDt6WFHlA== )
com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
f9eabb94487e658c188e7bcb52115 )
com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
70643bbde681db342a9e5cf2bb380 )
com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .