-
Notifications
You must be signed in to change notification settings - Fork 8
/
draft-ietf-tls-dnssec-chain-extension-07.xml
1231 lines (1121 loc) · 53.2 KB
/
draft-ietf-tls-dnssec-chain-extension-07.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc5011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY rfc5155 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5155.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY rfc6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY rfc6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY rfc7120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7120.xml">
<!ENTITY rfc7250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7250.xml">
<!ENTITY rfc7590 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7590.xml">
<!ENTITY rfc7633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7633.xml">
<!ENTITY rfc7671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7671.xml">
<!ENTITY rfc7672 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7672.xml">
<!ENTITY rfc7901 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7901.xml">
<!ENTITY rfc8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc docName="draft-ietf-tls-dnssec-chain-extension-07"
ipr="trust200902" category="std">
<front>
<title abbrev="TLS DNSSEC Chain Extension">
A DANE Record and DNSSEC Authentication Chain Extension for TLS
</title>
<author fullname="Melinda Shore" initials="M"
surname="Shore">
<organization>Fastly</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Richard Barnes" initials="R"
surname="Barnes">
<organization>Mozilla</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Shumon Huque" initials="S"
surname="Huque">
<organization>Salesforce</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Willem Toorop" initials="W"
surname="Toorop">
<organization>NLnet Labs</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2018" />
<area>Security</area>
<workgroup>TLS</workgroup>
<abstract>
<t>
This draft describes a new TLS extension for
transport of a DNS record set serialized with the DNSSEC
signatures needed to authenticate that record set. The
intent of this proposal is to allow TLS clients to
perform DANE authentication of a TLS server
without needing to perform additional DNS
record lookups. It is not intended to be used to validate
the TLS server's address records.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Notation">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" />
<xref target="RFC8174" /> when, and only when, they
appear in all capitals, as shown here.
</t>
</section>
<section title="Introduction">
<t>
This draft describes a new TLS
<xref target="RFC5246"/> <xref target="TLS13"/>
extension
for transport of a DNS record set serialized with the
<xref target="RFC4034">DNSSEC signatures</xref> needed
to authenticate that record set. The intent of this
proposal is to allow TLS clients to perform DANE
Authentication <xref target="RFC6698" />
<xref target="RFC7671" /> of a TLS
server without performing
additional DNS record lookups and incurring the
associated latency penalty. It also provides the
ability to avoid potential problems with TLS clients
being unable to look up DANE records because of an
interfering or broken middlebox on the path between
the client and a DNS server <xref target="HAMPERING"/>.
And lastly, it allows a
TLS client to validate the server's DANE (TLSA) records
itself without needing access to a validating DNS resolver
to which it has a secure connection.
</t>
<t>
This mechanism is useful
for TLS applications that need to address the problems
described above, typically web browsers or SIP/VoIP
<xref target="RFC3261"/> and XMPP <xref target="RFC7590"/>.
It may not be relevant for many other
applications. For example, SMTP MTAs are usually
located in data centers, may tolerate
extra DNS lookup latency, are on servers where it is
easier to provision a validating resolver, or are
less likely to experience traffic interference from
misconfigured middleboxes. Furthermore, SMTP MTAs usually
employ <xref target="RFC7672">Opportunistic Security</xref>,
in which the presence of the DNS TLSA records is used to determine
whether to enforce an authenticated TLS connection.
Hence DANE authentication of SMTP MTAs will typically not use
this mechanism.
</t>
<t>
The extension described here allows a TLS client to request that
the TLS server return the DNSSEC authentication chain corresponding
to its DANE record. If the server is configured for DANE authentication,
then it performs the appropriate DNS queries, builds the authentication
chain, and returns it to the client. The server will usually use a
previously cached authentication chain, but it will need to rebuild it
periodically as described in <xref target="sec_caching" />. The client
then authenticates the chain using a pre-configured trust anchor.
</t>
<t>
This specification is based on Adam Langley's original
proposal for serializing DNSSEC authentication chains
and delivering them in an X.509 certificate extension
<xref target="I-D.agl-dane-serializechain" />. It modifies the approach by using
wire format DNS records in the serialized data (assuming
that the data will be prepared and consumed by a DNS-specific
library), and by using a TLS extension to deliver the data.
</t>
<t>
As described in the DANE specification <xref target="RFC6698" />
<xref target="RFC7671" />, this
procedure applies to the DANE authentication of X.509
certificates or raw public keys <xref target="RFC7250" />.
</t>
</section> <!-- introduction -->
<section title="DNSSEC Authentication Chain Extension">
<section title="Protocol, TLS 1.2">
<t>
A client MAY include an extension of type
"dnssec_chain" in the (extended) ClientHello. The
"extension_data" field of this extension MUST be
empty.
</t>
<t>
Servers receiving a "dnssec_chain" extension in the
ClientHello and which are capable of being authenticated
via DANE, return a serialized authentication chain
in the extended ServerHello message using the format
described below. If a server is unable to return an
authentication chain, or does not wish to return an
authentication chain, it does not include a dnssec_chain
extension. As with all TLS extensions, if the server
does not support this extension it will not return any
authentication chain.
</t>
</section> <!-- protocol 1.2 -->
<section title="Protocol, TLS 1.3">
<t>
A client MAY include an extension of type
"dnssec_chain" in the ClientHello. The
"extension_data" field of this extension MUST be
empty.
</t>
<t>
Servers receiving a "dnssec_chain" extension in the
ClientHello, and which are capable of being authenticated
via DANE, return a serialized authentication chain
in the extension block of the Certificate message containing
the end entity certificate being validated, using the format
described below.
</t>
<t>
The extension protocol behavior otherwise follows that specified
for TLS version 1.2.
</t>
</section> <!-- protocol 1.3 -->
<section title="Raw Public Keys">
<t>
<xref target="RFC7250" /> specifies the use of raw
public keys for both server and client
authentication in TLS 1.2. It points out that in
cases where raw public keys are being used, code for
certificate path validation is not
required. However, DANE, when used in conjunction
with the dnssec_chain extension, provides a mechanism for
securely binding a raw public key to a named entity
in the DNS, and when using DANE for authentication a
raw key may be validated using a path chaining back
to a DNSSEC trust root. This has the added benefit
of mitigating an unknown key share attack, as
described in <xref target="I-D.barnes-dane-uks" />,
since it effectively augments the raw public key
with the server's name and provides a means to
commit both the server and the client to using that
binding.
</t>
<t>
The UKS attack is possible in situations in which
the association between a domain name and a public
key is not tightly bound, as in the case in DANE in
which a client either ignores the name in the
certificate (as specified in <xref target="RFC7671"
/>) or there is no attestation of trust outside of
the DNS. The vulnerability arises in the following
situations:
</t>
<t>
<list style="symbols">
<t>If the client does not verify the identity in the
server's certificate (as recommended in Section
5.1 of [RFC7671]), then an attacker can induce the
client to accept an unintended identity for the
server,
</t>
<t>If the client allows the use of raw public keys
in TLS, then it will not receive any
indication of the server's identity in the TLS
channel, and is thus unable to check that the
server's identity is as intended.
</t>
</list>
</t>
<t>The mechanism for conveying DNSSEC validation
chains described in this document results in a
commitment by both parties, via the TLS
handshake, to a validated domain name and EE key.</t>
<t>The mechanism for encoding DNSSEC authentication
chains in a TLS extension, as described in this
document, is not limited to public keys encapsulated
in X.509 containers but MAY be applied to raw
public keys and other representations, as well.
</t>
</section>
<section title="DNSSEC Authentication Chain Data"
anchor="auth_chain_data">
<t>
The "extension_data" field of the "dnssec_chain" extension
MUST contain a DNSSEC Authentication Chain encoded in the
following form:
</t>
<figure>
<artwork>
opaque AuthenticationChain<1..2^16-1>
</artwork>
</figure>
<t>
The AuthenticationChain structure is composed of a sequence of
uncompressed wire format DNS resource record sets (RRset) and
corresponding signatures (RRSIG) record sets.
</t>
<t>
This sequence 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>
Each RRset in the chain is composed of a sequence of wire format
DNS resource records. The format of the resource record is
described in <xref target="RFC1035">RFC 1035</xref>, Section
3.2.1.
</t>
<figure>
<artwork>
RR(i) = owner | type | class | TTL | RDATA length | RDATA
where RR(i) denotes the ith RR.
</artwork>
</figure>
<t>
The resource records that make up a RRset all have the same owner,
type and class, but different RDATA as specified
<xref target="RFC2181">RFC 2181</xref>, Section 5.
Each RRset in the sequence is followed by its associated
RRsig record set. This RRset has the same owner and class as the
preceding RRset, but has type RRSIG. The Type Covered
field in the RDATA of the RRsigs identifies the type of the
preceding RRset as described in
<xref target="RFC4034">RFC 4034</xref>, Section 3.
The RRsig record wire format is described in
<xref target="RFC4034">RFC 4034</xref>, Section 3.1. The
signature portion of the RDATA, as described in the same
section, is the following:
</t>
<figure>
<artwork>
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )
</artwork>
</figure>
<t>
where RRSIG_RDATA is the wire format of the RRSIG RDATA
fields with the Signer's Name field in canonical form and
the signature field excluded.
</t>
<t>
The first RRset in the chain MUST contain the TLSA record set
being presented. However, if the owner name of the TLSA record
set is an alias (CNAME or DNAME), then it MUST be preceded by the
chain of alias records needed to resolve it. DNAME chains SHOULD
omit unsigned CNAME records that may have been synthesized in the
response from a DNS resolver. (If unsigned synthetic CNAMES are
present, then the TLS client will just ignore them, as they are
not necessary to validate the chain.)
</t>
<t>
The subsequent RRsets MUST contain the full set
of DNS records needed to authenticate the TLSA record set from the
server's trust anchor. Typically this means a set of DNSKEY
and DS RRsets that cover all zones from the target zone containing
the TLSA record set to the trust anchor zone. The TLS client should
be prepared to receive this set of RRsets in any order.
</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>
If the TLSA record set was synthesized by a DNS wildcard, the
chain MUST include the signed NSEC or <xref target="RFC5155">
NSEC3</xref> records that prove
that there was no explicit match of the TLSA record name and no
closer wildcard match.
</t>
<t>
The final DNSKEY RRset in the authentication chain corresponds
to the trust anchor (typically the DNS root). This trust anchor
is also preconfigured in the TLS client, but including it in the
response from the server permits TLS clients to use the automated
trust anchor rollover mechanism defined in RFC 5011
<xref target="RFC5011" /> to update their configured trust anchor.
</t>
<t>
The following is an example of the records in the
AuthenticationChain structure for the HTTPS server at
www.example.com, where there are zone cuts at "com."
and "example.com." (record data are omitted here for brevity):
</t>
<figure>
<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>
</figure>
</section> <!-- authentication chain data -->
</section> <!-- dnssec authentication chain extension -->
<section title="Construction of Serialized Authentication Chains">
<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 target="RFC7671" /> 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 server_name extension <xref target="RFC6066"
/> when present. If the server_name extension is not
present, or if the server does not recognize the
provided name and wishes to proceed with the handshake
rather than to abort the connection, the server picks
one of its configured domain names associated with the
server IP address to which the connection has been established.
</t>
<t>
The TLSA record to be queried is constructed by prepending
the _port and _transport labels to the domain name as described
in <xref target="RFC6698" />, where "port" is the port number
associated with the TLS server. The transport is "tcp"
for TLS servers, and "udp" for DTLS servers. The port
number label is the left-most label, followed by the
transport, followed by the base domain name.
</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" /> for specific processing needed for
aliases and wildcards. If DNS response messages contain any
domain names utilizing name compression
<xref target="RFC1035"/>, then they MUST be uncompressed.
</t>
<t>
Newer DNS protocol enhancements, such as the <xref target="RFC7901">
EDNS Chain Query extension</xref> if supported, may offer easier ways
to obtain all of the chain data in one transaction with an upstream
DNSSEC aware recursive server.
</t>
</section> <!-- construction -->
<section title="Caching and Regeneration of the Authentication Chain"
anchor="sec_caching">
<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 MUST refresh and rebuild the chain as TTLs
and signature validity periods dictate. A server implementation
could carefully track these 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 or signature validity periods of the
component records in the chain.
</t>
</section>
<section title="Verification" anchor="sec_verification">
<t>
A TLS client making use of this specification, and
which receives a DNSSEC authentication chain extension
from a server, MUST use this information to perform
DANE authentication of the server. In
order to do this, it uses the mechanism specified by
the DNSSEC protocol <xref target="RFC4035"/> <xref target="RFC5155"/>.
This mechanism is sometimes implemented in a DNSSEC
validation engine or library.
</t>
<t>
If the authentication chain is correctly verified, the client then
performs DANE authentication of the server according to the DANE TLS
protocol <xref target="RFC6698"/> <xref target="RFC7671"/>.
</t>
<t>
Clients MAY cache the server's validated TLSA RRset or other
validated portions of the chain as an optimization to save
signature verification work for future 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
dnssec_chain extension for subsequent connections to the same TLS
server. It can use the cached information to perform DANE
authentication.
</t>
</section> <!-- verification -->
<section title="Trust Anchor Maintenance" anchor="sec_trustmaint">
<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" /> 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> <!-- trust anchor maintenance -->
<section title="Mandating use of this extension" anchor="mandating">
<t>
Green field applications that are designed to always employ this
extension, could of course unconditionally mandate its use.
</t>
<t>
If TLS applications want to mandate the use of this extension for
specific servers, clients could maintain a whitelist of sites where
the use of this extension is forced. The client would refuse to
authenticate such servers if they failed to deliver this extension.
Client applications could also employ a Trust on First Use (TOFU) like
strategy, whereby they would record the fact that a server offered the
extension and use that knowledge to require it for subsequent connections.
</t>
<t>
This protocol currently provides no way for a server to prove that
it doesn't have a TLSA record. Hence absent whitelists, a client
misdirected to a server that has fraudulently acquired a public CA
issued certificate for the real server's name, could be induced to
establish a PKIX verified connection to the rogue server that precluded
DANE authentication. This could be solved by enhancing this protocol
to require that servers without TLSA records need to provide a DNSSEC
authentication chain that proves this (i.e. the chain includes NSEC or
NSEC3 records that demonstrate either the absence of the TLSA record,
or the absence of a secure delegation to the associated zone). Such an
enhancement would be impossible to deploy incrementally though since it
requires all TLS servers to support this protocol.
</t>
<t>
One possible way to address the threat of attackers that have
fraudulently obtained valid PKIX credentials, is to use current
PKIX defense mechanisms, such as checking Certificate Transparency
logs to detect certificate misissuance. This may be necessary anyway,
as TLS servers may support both DANE and PKIX authentication. Even
TLS servers that support only DANE may be interested in detecting
PKIX adversaries impersonating their service to DANE unaware TLS
clients.
</t>
</section>
<section title="DANE and Traditional PKIX Interoperation" anchor="pkix-interop">
<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 fallback 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>
</section>
<section title="Security Considerations">
<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" />.
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" />
or SNTP <xref target="RFC5905" />, which are already widely used
today. TLS clients MUST support a mechanism to track and rollover
the trust anchor key, or be able to avail themselves of a service
that does this, as described in <xref target="sec_trustmaint" />.
Security considerations related to mandating the use of this
extension are described in <xref target="mandating" />.
</t>
</section>
<section title="IANA Considerations">
<t>This extension requires the registration of a new
value in the TLS ExtensionsType registry. The value
requested from IANA is 53, and the extension should
be marked "Recommended" in accordance with "IANA Registry
Updates for TLS and DTLS" <xref target="TLSIANA"/>.
</t>
</section> <!-- iana considerations -->
<section title="Acknowledgments">
<t>
Many thanks to Adam Langley for laying the groundwork
for this extension. 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: Viktor Dukhovni,
Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick McManus,
Rick van Rein, Ilari Liusvaara, Eric Rescorla, Gowri Visweswaran,
Duane Wessels, Nico Williams, and Paul Wouters.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1035;
&rfc2119;
&rfc2181;
&rfc4034;
&rfc4035;
&rfc5155;
&rfc5246;
&rfc6066;
&rfc6698;
&rfc7671;
&rfc8174;
<reference anchor="TLS13"
target="https://tools.ietf.org/html/draft-ietf-tls-tls13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla" />
<date year="2018" month="March" day="18"/>
</front>
</reference>
<reference anchor="TLSIANA"
target="https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates">
<front>
<title>IANA Registry Updates for TLS and DTLS</title>
<author fullname="Joe Salowey" initials="J" surname="Salowey" />
<author fullname="Sean Turner" initials="S" surname="Turner" />
<date />
</front>
</reference>
</references>
<references title="Informative References">
&rfc3261;
&rfc5011;
&rfc5905;
&rfc7120;
&rfc7250;
&rfc7590;
&rfc7672;
&rfc7901;
<?rfc include="reference.I-D.agl-dane-serializechain.xml"?>
<?rfc include="reference.I-D.draft-barnes-dane-uks-00.xml"?>
<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 fullname="Willem Toorop" initials="W" surname="Toorop" />
<date year="2015" month="July" day="14"/>
</front>
</reference>
</references>
<section title="Test vectors">
<t>
The provided test vectors will authenticate the certificate
used with https://example.com/, https://example.net/ and
https://example.org/ at the time of writing:
</t>
<figure>
<artwork>
-----BEGIN CERTIFICATE-----
MIIF8jCCBNqgAwIBAgIQDmTF+8I2reFLFyrrQceMsDANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xNTExMDMwMDAwMDBaFw0xODExMjgxMjAwMDBa
MIGlMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML
TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBB
c3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczETMBEGA1UECxMKVGVjaG5vbG9neTEY
MBYGA1UEAxMPd3d3LmV4YW1wbGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAs0CWL2FjPiXBl61lRfvvE0KzLJmG9LWAC3bcBjgsH6NiVVo2dt6u
Xfzi5bTm7F3K7srfUBYkLO78mraM9qizrHoIeyofrV/n+pZZJauQsPjCPxMEJnRo
D8Z4KpWKX0LyDu1SputoI4nlQ/htEhtiQnuoBfNZxF7WxcxGwEsZuS1KcXIkHl5V
RJOreKFHTaXcB1qcZ/QRaBIv0yhxvK1yBTwWddT4cli6GfHcCe3xGMaSL328Fgs3
jYrvG29PueB6VJi/tbbPu6qTfwp/H1brqdjh29U52Bhb0fJkM9DWxCP/Cattcc7a
z8EXnCO+LK8vkhw/kAiJWPKx4RBvgy73nwIDAQABo4ICUDCCAkwwHwYDVR0jBBgw
FoAUUWj/kK8CB3U8zNllZGKiErhZcjswHQYDVR0OBBYEFKZPYB4fLdHn8SOgKpUW
5Oia6m5IMIGBBgNVHREEejB4gg93d3cuZXhhbXBsZS5vcmeCC2V4YW1wbGUuY29t
ggtleGFtcGxlLmVkdYILZXhhbXBsZS5uZXSCC2V4YW1wbGUub3Jngg93d3cuZXhh
bXBsZS5jb22CD3d3dy5leGFtcGxlLmVkdYIPd3d3LmV4YW1wbGUubmV0MA4GA1Ud
DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0f
BG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItaGEtc2Vy
dmVyLWc0LmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTIt
aGEtc2VydmVyLWc0LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgGCCsG
AQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAECAjCB
gwYIKwYBBQUHAQEEdzB1MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wTQYIKwYBBQUHMAKGQWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydFNIQTJIaWdoQXNzdXJhbmNlU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQELBQADggEBAISomhGn2L0LJn5SJHuyVZ3qMIlRCIdvqe0Q
6ls+C8ctRwRO3UU3x8q8OH+2ahxlQmpzdC5al4XQzJLiLjiJ2Q1p+hub8MFiMmVP
PZjb2tZm2ipWVuMRM+zgpRVM6nVJ9F3vFfUSHOb4/JsEIUvPY+d8/Krc+kPQwLvy
ieqRbcuFjmqfyPmUv1U9QoI4TQikpw7TZU0zYZANP4C/gj4Ry48/znmUaRvy2kvI
l7gRQ21qJTK5suoiYoYNo3J9T+pXPGU7Lydz/HwW+w0DpArtAaukI8aNX4ohFUKS
wDSiIIWIWJiJGbEeIO0TIFwEVWTOnbNl/faPXpk5IRXicapqiII=
-----END CERTIFICATE-----
</artwork>
</figure>
<t>For brevity and reproducability 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:
<list>
<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>
<t>The root and org zones are rolling their ZSK's.</t>
<t>The com and org zones are rolling their KSK's.</t>
</list>
</t>
<t>The test vectors are DNSSEC valid in the same period as the certificate is
valid, which is in between November 3 2015 and November 28 2018, with the
following root trust anchor:</t>
<figure>
<artwork>
. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634
641bb568746f2ffc4d4 )
</artwork>
</figure>
<section title="_443._tcp.www.example.com">
<figure>
<artwork>
_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
20181128000000 20151103000000 1870 example.com.
uml1DUjp5RfrXn9WtuMxEQV+ygzrONcuzsnyfOGSszwaDdkSOJ0Kndcfbb2Il
LUV04Z+V488+Sd1jr7/21tsKA== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20181128000000 20151103000000 1870 example.com.
HujA9vQTbCxMeaYjDOCF0fYyHhajTl5xPztrp5u6P2vYV8naYQLG3zUF1gaer
WBOagXXblaSSbYwB96LU3uSdg== )
example.com. 900 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd25a
986e8a44f319ac3cd302bafc08f5b81e16 )
example.com. 900 IN RRSIG ( DS 13 2 900 20181128000000
20151103000000 34327 com.
1tua9ntAqZvOnK5UztzIjN38Bqs6mJ8KAT7L4+AxevDL+z0Jft7RC1/g6Qrfa
In1wqF4U7TvC8PYOD0U/HYtwQ== )
com. 900 IN DNSKEY ( 256 3 13
7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
com. 900 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 900 IN DNSKEY ( 257 3 13
szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
com. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000
20151103000000 18931 com.
lZmTBrfcRgVbqHJIfCVr6c3HUDgy3MlNSCSnrVV2S5/NmB3ZiFcvIDn0iqXPm
7YQfvfWi6utyxBu/fSD6S1ARw== )
com. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000
20151103000000 28809 com.
8qZOVM4X8wGt5XPWhG2HO4FAD6Kvs5eIhZUz+7DVCrZ/XMEVrMIHcm1Q+sq0s
hm4cSivK2BxOO24PHJXoZN2Lw== )
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 20181128000000
20151103000000 31918 .
5KQVa0NP+6k7VEGMmeky2/Y3wIGM70Fkm0vp5NmQ6KPk8L1XMJPltcJDWGGjc
EU3Uc4z2DUxzZyWgEDdrSOcdw== )
. 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 20181128000000
20151103000000 47005 .
ehAzuZD3yT0pShXkKavrMdz+DKvvFvbZ+sGRZ5iQTni+ulMzZxHQ5+kSha65B
Y2AIUphjyWcGr6VwP3Ne74iZA== )
</artwork>
</figure>
<t>A hex dump of the wire format data of this content is:</t>
<figure>
<artwork>
0000: 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 07 65
0010: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 01 00
0020: 00 0e 10 00 23 03 01 01 c6 6b ef 6a 5c 1a 3e 78
0030: b8 20 16 e1 3f 31 4f 3c c5 fa 25 b1 e5 2a ab 9a
0040: db 9e c5 98 9b 16 5a da 04 5f 34 34 33 04 5f 74
0050: 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63
0060: 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 34 0d
0070: 05 00 00 0e 10 5b fd da 80 56 37 f9 00 07 4e 07
0080: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ba 69 75 0d
0090: 48 e9 e5 17 eb 5e 7f 56 b6 e3 31 11 05 7e ca 0c
00a0: eb 38 d7 2e ce c9 f2 7c e1 92 b3 3c 1a 0d d9 12
00b0: 38 9d 0a 9d d7 1f 6d bd 88 94 b5 15 d3 86 7e 57
00c0: 8f 3c f9 27 75 8e be ff db 5b 6c 28 07 65 78 61
00d0: 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00 00 0e
00e0: 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d 9c fe
00f0: a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25 12 d8
0100: 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51 ce b9
0110: 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be 5b 2e
0120: 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c 65 03
0130: 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 30
0140: 0d 02 00 00 0e 10 5b fd da 80 56 37 f9 00 07 4e
0150: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 1e e8 c0
0160: f6 f4 13 6c 2c 4c 79 a6 23 0c e0 85 d1 f6 32 1e
0170: 16 a3 4e 5e 71 3f 3b 6b a7 9b ba 3f 6b d8 57 c9
0180: da 61 02 c6 df 35 05 d6 06 9e ad 60 4e 6a 05 d7
0190: 6e 56 92 49 b6 30 07 de 8b 53 7b 92 76 07 65 78
01a0: 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01 00 00
01b0: 03 84 00 24 07 4e 0d 02 e9 b5 33 a0 49 79 8e 90
01c0: 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac 3c d3
01d0: 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70 6c 65
01e0: 03 63 6f 6d 00 00 2e 00 01 00 00 03 84 00 57 00
01f0: 2b 0d 02 00 00 03 84 5b fd da 80 56 37 f9 00 86
0200: 17 03 63 6f 6d 00 d6 db 9a f6 7b 40 a9 9b ce 9c
0210: ae 54 ce dc c8 8c dd fc 06 ab 3a 98 9f 0a 01 3e
0220: cb e3 e0 31 7a f0 cb fb 3d 09 7e de d1 0b 5f e0
0230: e9 0a df 68 89 f5 c2 a1 78 53 b4 ef 0b c3 d8 38
0240: 3d 14 fc 76 2d c1 03 63 6f 6d 00 00 30 00 01 00
0250: 00 03 84 00 44 01 00 03 0d ec 82 04 e4 3a 25 f2
0260: 34 8c 52 a1 d3 bc e3 a2 65 aa 5d 11 b4 3d c2 a4
0270: 71 16 2f f3 41 c4 9d b9 f5 0a 2e 1a 41 ca f2 e9
0280: cd 20 10 4e a0 96 8f 75 11 21 9f 0b dc 56 b6 80
0290: 12 cc 39 95 33 67 51 90 0b 03 63 6f 6d 00 00 30
02a0: 00 01 00 00 03 84 00 44 01 01 03 0d 45 b9 1c 3b
02b0: ef 7a 5d 99 a7 a7 c8 d8 22 e3 38 96 bc 80 a7 77
02c0: a0 42 34 a6 05 a4 a8 88 0e c7 ef a4 e6 d1 12 c7
02d0: 3c d3 d4 c6 55 64 fa 74 34 7c 87 37 23 cc 5f 64
02e0: 33 70 f1 66 b4 3d ed ff 83 64 00 ff 03 63 6f 6d
02f0: 00 00 30 00 01 00 00 03 84 00 44 01 01 03 0d b3
0300: 37 3b 6e 22 e8 e4 9e 0e 1e 59 1a 9f 5b d9 ac 5e
0310: 1a 0f 86 18 7f e3 47 03 f1 80 a9 d3 6c 95 8f 71
0320: c4 af 48 ce 0e bc 5c 79 2a 72 4e 11 b4 38 95 93
0330: 7e e5 34 04 26 81 29 47 6e b1 ae d3 23 93 90 03
0340: 63 6f 6d 00 00 2e 00 01 00 00 03 84 00 57 00 30
0350: 0d 01 00 00 03 84 5b fd da 80 56 37 f9 00 49 f3
0360: 03 63 6f 6d 00 95 99 93 06 b7 dc 46 05 5b a8 72
0370: 48 7c 25 6b e9 cd c7 50 38 32 dc c9 4d 48 24 a7
0380: ad 55 76 4b 9f cd 98 1d d9 88 57 2f 20 39 f4 8a
0390: a5 cf 9b b6 10 7e f7 d6 8b ab ad cb 10 6e fd f4
03a0: 83 e9 2d 40 47 03 63 6f 6d 00 00 2e 00 01 00 00
03b0: 03 84 00 57 00 30 0d 01 00 00 03 84 5b fd da 80
03c0: 56 37 f9 00 70 89 03 63 6f 6d 00 f2 a6 4e 54 ce
03d0: 17 f3 01 ad e5 73 d6 84 6d 87 3b 81 40 0f a2 af
03e0: b3 97 88 85 95 33 fb b0 d5 0a b6 7f 5c c1 15 ac
03f0: c2 07 72 6d 50 fa ca b4 b2 19 b8 71 28 af 2b 60
0400: 71 38 ed b8 3c 72 57 a1 93 76 2f 03 63 6f 6d 00
0410: 00 2b 00 01 00 01 51 80 00 24 49 f3 0d 02 20 f7
0420: a9 db 42 d0 e2 04 2f bb b9 f9 ea 01 59 41 20 2f
0430: 9e ab b9 44 87 e6 58 c1 88 e7 bc b5 21 15 03 63
0440: 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 70 89 0d
0450: 02 ad 66 b3 27 6f 79 62 23 aa 45 ed a7 73 e9 2c
0460: 6d 98 e7 06 43 bb de 68 1d b3 42 a9 e5 cf 2b b3
0470: 80 03 63 6f 6d 00 00 2e 00 01 00 01 51 80 00 53
0480: 00 2b 0d 01 00 01 51 80 5b fd da 80 56 37 f9 00
0490: 7c ae 00 e4 a4 15 6b 43 4f fb a9 3b 54 41 8c 99
04a0: e9 32 db f6 37 c0 81 8c ef 41 64 9b 4b e9 e4 d9
04b0: 90 e8 a3 e4 f0 bd 57 30 93 e5 b5 c2 43 58 61 a3
04c0: 70 45 37 51 ce 33 d8 35 31 cd 9c 96 80 40 dd ad
04d0: 23 9c 77 00 00 30 00 01 00 01 51 80 00 44 01 00
04e0: 03 0d cc ac fe 0c 25 a4 34 0f ef ba 17 a2 54 f7
04f0: 06 aa c1 f8 d1 4f 38 29 90 25 ac c4 48 ca 8c e3
0500: f5 61 f3 7f c3 ec 16 9f e8 47 c8 fc be 68 e3 58
0510: ff 7c 71 bb 5e e1 df 0d be 51 8b c7 36 d4 ce 8d
0520: fe 14 00 00 30 00 01 00 01 51 80 00 44 01 00 03
0530: 0d f3 03 19 67 89 73 1d dc 8a 67 87 ef f2 4c ac
0540: fe dd d0 32 58 2f 11 a7 5b b1 bc aa 5a b3 21 c1
0550: d7 52 5c 26 58 19 1a ec 01 b3 e9 8a b7 91 5b 16
0560: d5 71 dd 55 b4 ea e5 14 17 11 0c c4 cd d1 1d 17
0570: 11 00 00 30 00 01 00 01 51 80 00 44 01 01 03 0d
0580: ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad 21 55
0590: ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 42 17 36
05a0: d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 bd 0f a0
05b0: 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 63 ad 46
05c0: 00 00 2e 00 01 00 01 51 80 00 53 00 30 0d 00 00
05d0: 01 51 80 5b fd da 80 56 37 f9 00 b7 9d 00 7a 10
05e0: 33 b9 90 f7 c9 3d 29 4a 15 e4 29 ab eb 31 dc fe
05f0: 0c ab ef 16 f6 d9 fa c1 91 67 98 90 4e 78 be ba
0600: 53 33 67 11 d0 e7 e9 12 85 ae b9 05 8d 80 21 4a
0610: 61 8f 25 9c 1a be 95 c0 fd cd 7b be 22 64
</artwork>
</figure>
</section> <!-- _443._tcp.www.example.com -->
<section title="_25._tcp.example.com wildcard">
<figure>
<artwork>
_25._tcp.example.com. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
_25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600
20181128000000 20151103000000 1870 example.com.
e7Q5L2x7Ca3SkSY6pRjqgtRxkEN1uYUcgyMlPp6GQ4zxAZxoO1Y1vGqxN4eNA
+yBnlUSIJQ46KKVS5PC79Qipg== )
*._tcp.example.com. 3600 IN NSEC (
_443._tcp.www.example.com. RRSIG NSEC TLSA )
*._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600
20181128000000 20151103000000 1870 example.com.
FlTtPqEPUPAQozlbt7bD9s2XIxdVPJ3nb+jK94Fxa2JsaZChH1n/DsYb5KS7J
G5GyubhMFTLeIqwTngx6JCktg== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s