idnits 2.17.1 draft-ietf-tls-dnssec-chain-extension-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 689 has weird spacing: '...a 66 ac a4 a7...' == Line 694 has weird spacing: '...e c7 ef a4 e6...' == Line 700 has weird spacing: '...2 76 fd a5 82...' == Line 714 has weird spacing: '...7 d1 fa ad 5b...' == Line 719 has weird spacing: '...e 8d bd e6 e1...' -- The document date (June 1, 2017) is 2521 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS M. Shore 3 Internet-Draft Fastly 4 Intended status: Standards Track R. Barnes 5 Expires: December 3, 2017 Mozilla 6 S. Huque 7 Salesforce 8 W. Toorop 9 NLNet Labs 10 June 1, 2017 12 A DANE Record and DNSSEC Authentication Chain Extension for TLS 13 draft-ietf-tls-dnssec-chain-extension-04 15 Abstract 17 This draft describes a new TLS extension for transport of a DNS 18 record set serialized with the DNSSEC signatures needed to 19 authenticate that record set. The intent of this proposal is to 20 allow TLS clients to perform DANE authentication of a TLS server 21 without needing to perform additional DNS record lookups. It will 22 typically not be used for general DNSSEC validation of TLS endpoint 23 names. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 3, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 4 62 3.1. Protocol, TLS 1.2 . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Protocol, TLS 1.3 . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 4 65 3.4. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5 66 4. Construction of Serialized Authentication Chains . . . . . . 7 67 5. Caching and Regeneration of the Authentication Chain . . . . 8 68 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9 70 8. Mandating use of this extension . . . . . . . . . . . . . . . 9 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 12.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 13 78 Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 13 79 Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 13 80 Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 13 81 D.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 15 82 D.2. _25._tcp.example.com wildcard . . . . . . . . . . . . . . 17 83 D.3. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 19 84 D.4. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Requirements Notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Introduction 95 This draft describes a new TLS [RFC5246] extension for transport of a 96 DNS record set serialized with the DNSSEC signatures [RFC4034] needed 97 to authenticate that record set. The intent of this proposal is to 98 allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671] 99 of a TLS server without performing additional DNS record lookups and 100 incurring the associated latency penalty. It also provides the 101 ability to avoid potential problems with TLS clients being unable to 102 look up DANE records because of an interfering or broken middlebox on 103 the path between the client and a DNS server. And lastly, it allows 104 a TLS client to validate DANE records itself without necessarily 105 needing access to a validating DNS resolver to which it has a secure 106 connection. It will typically not be used for general DNSSEC 107 validation of endpoint names, but is more appropriate for validation 108 of DANE TLSA records. 110 This mechanism is useful for TLS applications that need to address 111 the problems described above, typically web browsers or VoIP and XMPP 112 applications. It may not be relevant for many other applications. 113 For example, SMTP MTAs are usually located in data centers, may 114 tolerate extra DNS lookup latency, are on servers where it is easier 115 to provision a validating resolver, or are less likely to experience 116 traffic interference from misconfigured middleboxes. Furthermore, 117 SMTP MTAs usually employ Opportunistic Security [RFC7672], in which 118 the presence of the DNS TLSA records is used to determine whether to 119 enforce an authenticated TLS connection. Hence DANE authentication 120 of SMTP MTAs will typically not use this mechanism. 122 The extension described here allows a TLS client to request in the 123 ClientHello message that the DNS authentication chain be returned in 124 the (extended) ServerHello message. If the server is configured for 125 DANE authentication, then it performs the appropriate DNS queries, 126 builds the authentication chain, and returns it to the client. The 127 server will usually use a previously cached authentication chain, but 128 it will need to rebuild it periodically as described in Section 5. 129 The client then authenticates the chain using a pre-configured trust 130 anchor. 132 This specification is based on Adam Langley's original proposal for 133 serializing DNSSEC authentication chains and delivering them in an 134 X.509 certificate extension [I-D.agl-dane-serializechain]. It 135 modifies the approach by using wire format DNS records in the 136 serialized data (assuming that the data will be prepared and consumed 137 by a DNS-specific library), and by using a TLS extension to deliver 138 the data. 140 As described in the DANE specification [RFC6698] [RFC7671], this 141 procedure applies to the DANE authentication of X.509 certificates or 142 raw public keys [RFC7250]. 144 3. DNSSEC Authentication Chain Extension 146 3.1. Protocol, TLS 1.2 148 A client MAY include an extension of type "dnssec_chain" in the 149 (extended) ClientHello. The "extension_data" field of this extension 150 MUST be empty. 152 Servers receiving a "dnssec_chain" extension in the ClientHello, and 153 which are capable of being authenticated via DANE, MAY return a 154 serialized authentication chain in the extended ServerHello message, 155 using the format described below. If a server is unable to return an 156 authentication chain, or does not wish to return an authentication 157 chain, it does not include a dnssec_chain extension. As with all TLS 158 extensions, if the server does not support this extension it will not 159 return any authentication chain. 161 A client must not be able to force a server to perform lookups on 162 arbitrary domain names using this mechanism. Therefore, a server 163 MUST NOT construct chains for domain names other than its own. 165 3.2. Protocol, TLS 1.3 167 A client MAY include an extension of type "dnssec_chain" in the 168 ClientHello. The "extension_data" field of this extension MUST be 169 empty. 171 Servers receiving a "dnssec_chain" extension in the ClientHello, and 172 which are capable of being authenticated via DANE, SHOULD return a 173 serialized authentication chain in the Certificate message associated 174 with the end entity certificate being validated, using the format 175 described below. The authentication chain will be an extension to 176 the certificate_list to which the certificate being authenticated 177 belongs. 179 The extension protocol behavior otherwise follows that specified for 180 TLS version 1.2. 182 3.3. Raw Public Keys 184 [RFC7250] specifies the use of raw public keys for both server and 185 client authentication in TLS 1.2. It points out that in cases where 186 raw public keys are being used, code for certificate path validation 187 is not required. However, DANE, when used in conjunction with the 188 dnssec_chain extension, provides a mechanism for securely binding a 189 raw public key to a named entity in the DNS, and when using DANE for 190 authentication a raw key may be validated using a path chaining back 191 to a DNSSEC trust root. This has the added benefit of mitigating an 192 unknown key share attack, as described in [I-D.barnes-dane-uks], 193 since it effectively augments the raw public key with the server's 194 name and provides a means to commit both the server and the client to 195 using that binding. 197 The UKS attack is possible in situations in which the association 198 between a domain name and a public key is not tightly bound, as in 199 the case in DANE in which a client either ignores the name in 200 certificate (as specified in [RFC7671] or there is no attestation of 201 trust outside of the DNS. The vulnerability arises in the following 202 situations: 204 o If the client does not verify the identity in the server's 205 certificate (as recommended in Section 5.1 of [RFC7671]), then an 206 attacker can induce the client to accept an unintended identity 207 for the server, 209 o If the client allows the use of raw public keys in TLS, then it 210 will not receive any indication of the server's identity in the 211 TLS channel, and is thus unable to check that the server's 212 identity is as intended. 214 The mechanism for conveying DNSSEC validation chains described in 215 this document results in a commitment by both parties, via the TLS 216 handshake, to a domain name which has been validated as belonging to 217 the owner name. 219 The mechanism for encoding DNSSEC authentication chains in a TLS 220 extension, as described in this document, is not limited to public 221 keys encapsulated in X.509 containers but MAY be applied to raw 222 public keys and other representations, as well. 224 3.4. DNSSEC Authentication Chain Data 226 The "extension_data" field of the "dnssec_chain" extension MUST 227 contain a DNSSEC Authentication Chain encoded in the following form: 229 opaque AuthenticationChain<0..2^16-1> 231 The AuthenticationChain structure is composed of a sequence of 232 uncompressed wire format DNS resource record sets (RRset) and 233 corresponding signatures (RRSIG) records. 235 This sequence of native DNS wire format records enables easier 236 generation of the data structure on the server and easier 237 verification of the data on client by means of existing DNS library 238 functions. However this document describes the data structure in 239 sufficient detail that implementers if they desire can write their 240 own code to do this. 242 Each RRset in the chain is composed of a sequence of wire format DNS 243 resource records. The format of the resource record is described in 244 RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be 245 presented in the canonical form and ordering as described in RFC 4034 246 [RFC4034]. 248 RR(i) = owner | type | class | TTL | RDATA length | RDATA 250 RRs within the RRset MAY be ordered canonically, by treating the 251 RDATA portion of each RR as a left-justified unsigned octet sequence 252 in which the absence of an octet sorts before a zero octet. 254 Each RRset in the sequence is followed by its associated RRsig 255 record. The RRsig record is in DNS wire format as described in RFC 256 4034 [RFC4034], Section 3.1. The signature portion of the RDATA, as 257 described in the same section, is the following: 259 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 261 where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with 262 the Signer's Name field in canonical form and the signature field 263 excluded. 265 The first RRset in the chain MUST contain the TLSA record set being 266 presented. However, if the owner name of the TLSA record set is an 267 alias (CNAME or DNAME), then it MUST be preceded by the chain of 268 alias records needed to resolve it. DNAME chains should omit 269 unsigned CNAME records that may have been synthesized in the response 270 from a DNS resolver. 272 The subsequent RRsets MUST contain the full set of DNS records needed 273 to authenticate the TLSA record set from the server's trust anchor. 274 Typically this means a set of DNSKEY and DS RRsets that cover all 275 zones from the target zone containing the TLSA record set to the 276 trust anchor zone. The TLS client should be prepared to receive this 277 set of RRsets in any order. 279 Names that are aliased via CNAME and/or DNAME records may involve 280 multiple branches of the DNS tree. In this case, the authentication 281 chain structure needs to include DS and DNSKEY record sets that cover 282 all the necessary branches. 284 If the TLSA record set was synthesized by a DNS wildcard, the chain 285 must include the signed NSEC or NSEC3 records that prove that there 286 was no explicit match of the TLSA record name and no closer wildcard 287 match. 289 The final DNSKEY RRset in the authentication chain corresponds to the 290 trust anchor (typically the DNS root). This trust anchor is also 291 preconfigured in the TLS client, but including it in the response 292 from the server permits TLS clients to use the automated trust anchor 293 rollover mechanism defined in RFC 5011 [RFC5011] to update their 294 configured trust anchor. 296 The following is an example of the records in the AuthenticationChain 297 structure for the HTTPS server at www.example.com, where there are 298 zone cuts at "com." and "example.com." (record data are omitted here 299 for brevity): 301 _443._tcp.www.example.com. TLSA 302 RRSIG(_443._tcp.www.example.com. TLSA) 303 example.com. DNSKEY 304 RRSIG(example.com. DNSKEY) 305 example.com. DS 306 RRSIG(example.com. DS) 307 com. DNSKEY 308 RRSIG(com. DNSKEY) 309 com. DS 310 RRSIG(com. DS) 311 . DNSKEY 312 RRSIG(. DNSKEY) 314 4. Construction of Serialized Authentication Chains 316 This section describes a possible procedure for the server to use to 317 build the serialized DNSSEC chain. 319 When the goal is to perform DANE authentication [RFC6698] [RFC7671] 320 of the server, the DNS record set to be serialized is a TLSA record 321 set corresponding to the server's domain name, protocol, and port 322 number. 324 The domain name of the server MUST be that included in the TLS 325 server_name extension [RFC6066] when present. If the server_name 326 extension is not present, or if the server does not recognize the 327 provided name and wishes to proceed with the handshake rather than to 328 abort the connection, the server uses the domain name associated with 329 the server IP address to which the connection has been established. 331 The TLSA record to be queried is constructed by prepending the _port 332 and _transport labels to the domain name as described in [RFC6698], 333 where "port" is the port number associated with the TLS server. The 334 transport is "tcp" for TLS servers, and "udp" for DTLS servers. The 335 port number label is the left-most label, followed by the transport, 336 followed by the base domain name. 338 The components of the authentication chain are typically built by 339 starting at the target record set and its corresponding RRSIG. Then 340 traversing the DNS tree upwards towards the trust anchor zone 341 (normally the DNS root), for each zone cut, the DNSKEY and DS RRsets 342 and their signatures are added. However, see Section 3.4 for 343 specific processing needed for aliases and wildcards. If DNS 344 responses messages contain any domain names utilizing name 345 compression [RFC1035], then they must be uncompressed. 347 Newer DNS protocol enhancements, such as the EDNS Chain Query 348 extension [RFC7901] if supported, may offer easier ways to obtain all 349 of the chain data in one transaction with an upstream DNSSEC aware 350 recursive server. 352 5. Caching and Regeneration of the Authentication Chain 354 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 355 have validity periods (specifically signature expiration times). 356 After the TLS server constructs the serialized authentication chain, 357 it SHOULD cache and reuse it in multiple TLS connection handshakes. 358 However, it MUST refresh and rebuild the chain as TTLs and signature 359 validity periods dictate. A server implementation could carefully 360 track these parameters and requery component records in the chain 361 correspondingly. Alternatively, it could be configured to rebuild 362 the entire chain at some predefined periodic interval that does not 363 exceed the DNS TTLs or signature validity periods of the component 364 records in the chain. 366 6. Verification 368 A TLS client making use of this specification, and which receives a 369 DNSSEC authentication chain extension from a server, SHOULD use this 370 information to perform DANE authentication of the server. In order 371 to do this, it uses the mechanism specified by the DNSSEC protocol 372 [RFC4035]. This mechanism is sometimes implemented in a DNSSEC 373 validation engine or library. 375 If the authentication chain is correctly verified, the client then 376 performs DANE authentication of the server according to the DANE TLS 377 protocol [RFC6698] [RFC7671]. 379 7. Trust Anchor Maintenance 381 The trust anchor may change periodically, e.g. when the operator of 382 the trust anchor zone performs a DNSSEC key rollover. TLS clients 383 using this specification MUST implement a mechanism to keep their 384 trust anchors up to date. They could use the method defined in 385 [RFC5011] to perform trust anchor updates inband in TLS, by tracking 386 the introduction of new keys seen in the trust anchor DNSKEY RRset. 387 However, alternative mechanisms external to TLS may also be utilized. 388 Some operating systems may have a system-wide service to maintain and 389 keep the root trust anchor up to date. In such cases, the TLS client 390 application could simply reference that as its trust anchor, 391 periodically checking whether it has changed. Some applications may 392 prefer to implement trust anchor updates as part of their automated 393 software updates. 395 8. Mandating use of this extension 397 A TLS server certificate MAY mandate the use of this extension by 398 means of the X.509 TLS Feature Extension described in [RFC7633]. 399 This X.509 certificate extension, when populated with the 400 dnssec_chain TLS extension identifier, indicates to the client that 401 the server must deliver the authentication chain when asked to do so. 402 (The X.509 TLS Feature Extension is the same mechanism used to 403 deliver other mandatory signals, such as OCSP "must staple" 404 assertions.) Mandating this extension for Raw Public Key 405 authentication (where there are no X.509 certificates) could employ 406 configuration mechanisms external to the TLS protocol. 408 9. Security Considerations 410 The security considerations of the normatively referenced RFCs (1035, 411 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this 412 extension. Since the server is delivering a chain of DNS records and 413 signatures to the client, it MUST rebuild the chain in accordance 414 with TTL and signature expiration of the chain components as 415 described in Section 5. TLS clients need roughly accurate time in 416 order to properly authenticate these signatures. This could be 417 achieved by running a time synchronization protocol like NTP 418 [RFC5905] or SNTP [RFC5905], which are already widely used today. 419 TLS clients MUST support a mechanism to track and rollover the trust 420 anchor key, or be able to avail themselves of a service that does 421 this, as described in Section 7. 423 10. IANA Considerations 425 This extension requires the registration of a new value in the TLS 426 ExtensionsType registry. The value requested from IANA is 53. If 427 the draft is adopted by the WG, the authors expect to make an early 428 allocation request as specified in [RFC7120]. 430 11. Acknowledgments 432 Many thanks to Adam Langley for laying the groundwork for this 433 extension. The original idea is his but our acknowledgment in no way 434 implies his endorsement. This document also benefited from 435 discussions with and review from the following people: Viktor 436 Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick 437 McManus, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico 438 Williams, and Paul Wouters. 440 12. References 442 12.1. Normative References 444 [RFC1035] Mockapetris, P., "Domain names - implementation and 445 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 446 November 1987, . 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, 450 DOI 10.17487/RFC2119, March 1997, 451 . 453 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 454 Rose, "Resource Records for the DNS Security Extensions", 455 RFC 4034, DOI 10.17487/RFC4034, March 2005, 456 . 458 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 459 Rose, "Protocol Modifications for the DNS Security 460 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 461 . 463 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 464 (TLS) Protocol Version 1.2", RFC 5246, 465 DOI 10.17487/RFC5246, August 2008, 466 . 468 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 469 Extensions: Extension Definitions", RFC 6066, 470 DOI 10.17487/RFC6066, January 2011, 471 . 473 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 474 of Named Entities (DANE) Transport Layer Security (TLS) 475 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 476 2012, . 478 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) 479 Feature Extension", RFC 7633, DOI 10.17487/RFC7633, 480 October 2015, . 482 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 483 Authentication of Named Entities (DANE) Protocol: Updates 484 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 485 October 2015, . 487 12.2. Informative References 489 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 490 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 491 September 2007, . 493 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 494 "Network Time Protocol Version 4: Protocol and Algorithms 495 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 496 . 498 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 499 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 500 2014, . 502 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 503 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 504 Transport Layer Security (TLS) and Datagram Transport 505 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 506 June 2014, . 508 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 509 Opportunistic DNS-Based Authentication of Named Entities 510 (DANE) Transport Layer Security (TLS)", RFC 7672, 511 DOI 10.17487/RFC7672, October 2015, 512 . 514 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, 515 DOI 10.17487/RFC7901, June 2016, 516 . 518 [I-D.agl-dane-serializechain] 519 Langley, A., "Serializing DNS Records with DNSSEC 520 Authentication", draft-agl-dane-serializechain-01 (work in 521 progress), July 2011. 523 [I-D.barnes-dane-uks] 524 Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key- 525 Share Attacks on DNS-based Authentications of Named 526 Entities (DANE)", draft-barnes-dane-uks-00 (work in 527 progress), October 2016. 529 Appendix A. Updates from -01 and -02 531 o Editorial updates for style and consistency 533 o Updated discussion of UKS attack 535 Appendix B. Updates from -01 537 o Added TLS 1.3 support 539 o Added section describing applicability to raw public keys 541 o Softened language about record order 543 Appendix C. Updates from -00 545 o Edits based on comments from Rick van Rein 547 o Warning about not overloading X.509 wildcards on DNSSEC wildcards 548 (from V. Dukhovny) 550 o Added MUST include negative proof on wildcards (from V. Dukhovny) 552 o Removed "TODO" on allowing the server to deliver only one 553 signature per RRset 555 o Added additional minor edits suggested by Viktor Dukhovny 557 Appendix D. Test vectors 559 The provided test vectors will authenticate the certificate used with 560 https://example.com/, https://example.net/ and https://example.org/ 561 at the time of writing: 563 -----BEGIN CERTIFICATE----- 564 MIIF8jCCBNqgAwIBAgIQDmTF+8I2reFLFyrrQceMsDANBgkqhkiG9w0BAQsFADBw 565 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 566 d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz 567 dXJhbmNlIFNlcnZlciBDQTAeFw0xNTExMDMwMDAwMDBaFw0xODExMjgxMjAwMDBa 568 MIGlMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML 569 TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBB 570 c3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczETMBEGA1UECxMKVGVjaG5vbG9neTEY 571 MBYGA1UEAxMPd3d3LmV4YW1wbGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A 572 MIIBCgKCAQEAs0CWL2FjPiXBl61lRfvvE0KzLJmG9LWAC3bcBjgsH6NiVVo2dt6u 573 Xfzi5bTm7F3K7srfUBYkLO78mraM9qizrHoIeyofrV/n+pZZJauQsPjCPxMEJnRo 574 D8Z4KpWKX0LyDu1SputoI4nlQ/htEhtiQnuoBfNZxF7WxcxGwEsZuS1KcXIkHl5V 575 RJOreKFHTaXcB1qcZ/QRaBIv0yhxvK1yBTwWddT4cli6GfHcCe3xGMaSL328Fgs3 576 jYrvG29PueB6VJi/tbbPu6qTfwp/H1brqdjh29U52Bhb0fJkM9DWxCP/Cattcc7a 577 z8EXnCO+LK8vkhw/kAiJWPKx4RBvgy73nwIDAQABo4ICUDCCAkwwHwYDVR0jBBgw 578 FoAUUWj/kK8CB3U8zNllZGKiErhZcjswHQYDVR0OBBYEFKZPYB4fLdHn8SOgKpUW 579 5Oia6m5IMIGBBgNVHREEejB4gg93d3cuZXhhbXBsZS5vcmeCC2V4YW1wbGUuY29t 580 ggtleGFtcGxlLmVkdYILZXhhbXBsZS5uZXSCC2V4YW1wbGUub3Jngg93d3cuZXhh 581 bXBsZS5jb22CD3d3dy5leGFtcGxlLmVkdYIPd3d3LmV4YW1wbGUubmV0MA4GA1Ud 582 DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0f 583 BG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItaGEtc2Vy 584 dmVyLWc0LmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTIt 585 aGEtc2VydmVyLWc0LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgGCCsG 586 AQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAECAjCB 587 gwYIKwYBBQUHAQEEdzB1MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy 588 dC5jb20wTQYIKwYBBQUHMAKGQWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E 589 aWdpQ2VydFNIQTJIaWdoQXNzdXJhbmNlU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQC 590 MAAwDQYJKoZIhvcNAQELBQADggEBAISomhGn2L0LJn5SJHuyVZ3qMIlRCIdvqe0Q 591 6ls+C8ctRwRO3UU3x8q8OH+2ahxlQmpzdC5al4XQzJLiLjiJ2Q1p+hub8MFiMmVP 592 PZjb2tZm2ipWVuMRM+zgpRVM6nVJ9F3vFfUSHOb4/JsEIUvPY+d8/Krc+kPQwLvy 593 ieqRbcuFjmqfyPmUv1U9QoI4TQikpw7TZU0zYZANP4C/gj4Ry48/znmUaRvy2kvI 594 l7gRQ21qJTK5suoiYoYNo3J9T+pXPGU7Lydz/HwW+w0DpArtAaukI8aNX4ohFUKS 595 wDSiIIWIWJiJGbEeIO0TIFwEVWTOnbNl/faPXpk5IRXicapqiII= 596 -----END CERTIFICATE----- 598 For brevity and reproducability all DNS zones involved with the test 599 vectors are signed using a single key with algorithm 13: ECDSA Curve 600 P-256 with SHA-256. 602 The test vectors are DNSSEC valid at June 1 2017, with the following 603 root trust anchor: 605 . IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634 606 641bb568746f2ffc4d4 ) 608 D.1. _443._tcp.www.example.com 610 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 611 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 612 ada ) 613 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 614 20170616000000 20170526000000 1870 example.com. 615 GRsT6bcn3fokM5JMvHF0liq63N/kUX+CrZQZIr4GlFnMr/uoS4P1zOBwc0sft 616 Kd8NsZJAikRr4CpaXITYQMx1w== ) 617 example.com. 3600 IN DNSKEY ( 257 3 13 618 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 619 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 620 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 621 20170616000000 20170526000000 1870 example.com. 622 sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r 623 8q6DBlCdlRQvzD90UKZDIAqbA== ) 624 example.com. 900 IN DS ( 1870 13 2 625 e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81 626 e16 ) 627 example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000 628 20170529000000 18931 com. 629 rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3 630 5XxvbOdLIJAcxhRS1c2VITfMA== ) 631 com. 900 IN DNSKEY ( 257 3 13 632 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 633 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 634 com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000 635 20170529000000 18931 com. 636 wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk 637 c6Nx3HLmhidf6dmt/Hi0ePBsQ== ) 638 com. 86400 IN DS ( 18931 13 2 639 20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52 640 115 ) 641 com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 642 20170530000000 47005 . 643 jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+ 644 jGGQccnLkQnUf7zednetSWalg== ) 645 . 86400 IN DNSKEY ( 257 3 13 646 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 647 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 648 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000 649 20170530000000 47005 . 650 tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK 651 8y3m+LZSLDSBHEocXIiRHWdFg== ) 653 A hex dump of the wire format data of this content is: 655 0000: 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 07 65 656 0010: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 01 00 657 0020: 00 0e 10 00 23 03 01 01 c6 6b ef 6a 5c 1a 3e 78 658 0030: b8 20 16 e1 3f 31 4f 3c c5 fa 25 b1 e5 2a ab 9a 659 0040: db 9e c5 98 9b 16 5a da 04 5f 34 34 33 04 5f 74 660 0050: 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 661 0060: 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 34 0d 662 0070: 05 00 00 0e 10 59 43 1f 80 59 27 70 00 07 4e 07 663 0080: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 7b be 85 af 664 0090: 63 08 fd be 6e eb 68 df 85 c2 58 e6 41 37 2f 68 665 00a0: 34 4f 4f ce 91 9c 4c b0 54 bb e5 31 cd 57 0c 57 666 00b0: cf 10 ce 33 13 29 7a b4 81 d9 10 d0 cf f3 32 c8 667 00c0: 24 e8 06 12 59 8c 58 c5 15 6e ae e1 07 65 78 61 668 00d0: 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00 00 0e 669 00e0: 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d 9c fe 670 00f0: a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25 12 d8 671 0100: 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51 ce b9 672 0110: 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be 5b 2e 673 0120: 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c 65 03 674 0130: 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 30 675 0140: 0d 02 00 00 0e 10 59 43 1f 80 59 27 70 00 07 4e 676 0150: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 db ce bb 677 0160: 5f 1c 4b f0 4e de 1e 36 f0 00 75 ae 79 f1 4e 7b 678 0170: 42 3b ff dc c0 04 b8 3c 5f 3a e7 ac a7 0c 47 0a 679 0180: a5 3d 70 95 28 d5 c9 65 5c 6f 7c ad 25 1e d2 77 680 0190: 00 2c 0a 9f f7 e9 19 a6 04 e9 cb 09 60 07 65 78 681 01a0: 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01 00 00 682 01b0: 03 84 00 24 07 4e 0d 02 e9 b5 33 a0 49 79 8e 90 683 01c0: 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac 3c d3 684 01d0: 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70 6c 65 685 01e0: 03 63 6f 6d 00 00 2e 00 01 00 00 03 84 00 57 00 686 01f0: 2b 0d 02 00 00 03 84 59 34 9f 00 59 2b 64 80 49 687 0200: f3 03 63 6f 6d 00 18 f3 6d 66 92 89 48 73 26 3a 688 0210: cd 1e 35 38 a3 97 07 1b ed de d6 14 db 16 f0 f5 689 0220: 62 27 20 c5 eb fa 66 ac a4 a7 8e 93 33 ca 62 42 690 0230: 91 7a 51 b5 15 3a 83 14 3a 80 a5 f2 b6 80 00 e5 691 0240: 6b 92 ba 37 ec 2d 03 63 6f 6d 00 00 30 00 01 00 692 0250: 00 03 84 00 44 01 01 03 0d 45 b9 1c 3b ef 7a 5d 693 0260: 99 a7 a7 c8 d8 22 e3 38 96 bc 80 a7 77 a0 42 34 694 0270: a6 05 a4 a8 88 0e c7 ef a4 e6 d1 12 c7 3c d3 d4 695 0280: c6 55 64 fa 74 34 7c 87 37 23 cc 5f 64 33 70 f1 696 0290: 66 b4 3d ed ff 83 64 00 ff 03 63 6f 6d 00 00 2e 697 02a0: 00 01 00 00 03 84 00 57 00 30 0d 01 00 00 03 84 698 02b0: 59 34 9f 00 59 2b 64 80 49 f3 03 63 6f 6d 00 8d 699 02c0: 21 46 95 a5 17 ab 10 0a 49 dd 25 d3 6b 7d 88 ab 700 02d0: 2b 18 c9 53 da f2 76 fd a5 82 b8 ea 14 cb 7c 25 701 02e0: 4a 36 4a f0 48 9b e6 a3 0d aa 5b 98 15 8e 64 12 702 02f0: bb 1b 6e 45 3f 03 00 88 3d 48 b7 0f 78 53 2b 03 703 0300: 63 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 49 f3 704 0310: 0d 02 20 f7 a9 db 42 d0 e2 04 2f bb b9 f9 ea 01 705 0320: 59 41 20 2f 9e ab b9 44 87 e6 58 c1 88 e7 bc b5 706 0330: 21 15 03 63 6f 6d 00 00 2e 00 01 00 01 51 80 00 707 0340: 53 00 2b 0d 01 00 01 51 80 59 3d d9 80 59 2c b6 708 0350: 00 b7 9d 00 33 56 6b d8 e2 80 50 7a e6 cf 68 27 709 0360: bb 22 5c a7 aa 41 f1 36 94 1c ae 94 9c 3f da 98 710 0370: c5 0f 56 b8 26 c7 57 44 05 a3 a5 11 ef d9 77 b3 711 0380: 49 a9 50 8d 99 76 98 78 8e 4b 30 a8 70 51 63 09 712 0390: a2 b6 14 05 00 00 30 00 01 00 01 51 80 00 44 01 713 03a0: 01 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 714 03b0: ad 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 715 03c0: 42 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 716 03d0: bd 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 717 03e0: 63 ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30 718 03f0: 0d 00 00 01 51 80 59 3d d9 80 59 2c b6 00 b7 9d 719 0400: 00 2b 43 e5 99 de 8d bd e6 e1 f0 05 2d 16 a1 7a 720 0410: 79 15 42 da 47 da 2f 63 0e 46 ab 7d e3 7e 9b 8a 721 0420: 7d 25 e2 3f 18 bf 85 4c 17 b7 d5 3c 06 c8 18 bb 722 0430: bd 98 44 11 72 e3 18 bc 9d 99 88 e5 00 91 58 c8 723 0440: 47 725 D.2. _25._tcp.example.com wildcard 726 _25._tcp.example.com. 3600 IN TLSA ( 3 1 1 727 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 728 ada ) 729 _25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600 730 20170616000000 20170526000000 1870 example.com. 731 dVxm88Spko03MB4pLo+zijMup2nr1Ii65yPqB/cAR/1Zg41iXer7I2sGh9KfT 732 ExLJC6dUMDVFUfm+1rwb+ax8Q== ) 733 *._tcp.example.com. 3600 IN NSEC ( 734 _443._tcp.www.example.com. RRSIG NSEC TLSA ) 735 *._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 736 20170616000000 20170526000000 1870 example.com. 737 1lNaYYQ+FAG8YBVEx/026OGhVw5DjAyqBGrrLN9D12IZuLHtTQ4C9QPORP4na 738 GWNPgASvLyNR8MoN0oXV7tbnQ== ) 739 example.com. 3600 IN DNSKEY ( 257 3 13 740 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 741 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 742 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 743 20170616000000 20170526000000 1870 example.com. 744 sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r 745 8q6DBlCdlRQvzD90UKZDIAqbA== ) 746 example.com. 900 IN DS ( 1870 13 2 747 e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81 748 e16 ) 749 example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000 750 20170529000000 18931 com. 751 rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3 752 5XxvbOdLIJAcxhRS1c2VITfMA== ) 753 com. 900 IN DNSKEY ( 257 3 13 754 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 755 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 756 com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000 757 20170529000000 18931 com. 758 wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk 759 c6Nx3HLmhidf6dmt/Hi0ePBsQ== ) 760 com. 86400 IN DS ( 18931 13 2 761 20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52 762 115 ) 763 com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 764 20170530000000 47005 . 765 jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+ 766 jGGQccnLkQnUf7zednetSWalg== ) 767 . 86400 IN DNSKEY ( 257 3 13 768 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 769 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 770 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000 771 20170530000000 47005 . 772 tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK 773 8y3m+LZSLDSBHEocXIiRHWdFg== ) 775 D.3. _443._tcp.www.example.org CNAME 776 _443._tcp.www.example.org. 3600 IN CNAME ( 777 dane311.example.org. ) 778 _443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600 779 20170616000000 20170526000000 44384 example.org. 780 DN+UMxh5TWL1u6Mc6ScWMU5R9C+qqIOSH4hqQmiPWhvSg0lFd71g43UqtdmBT 781 VRUbhk/f9WC8Fy5D0gE5lUcyA== ) 782 dane311.example.org. 3600 IN TLSA ( 3 1 1 783 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 784 ada ) 785 dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 786 20170616000000 20170526000000 44384 example.org. 787 HJx59dAMQgvJSYBYtixzfodup5KRUzJ1SlRUrFJkGZz6PkpfuFdtpZwPN1vw9 788 SyvXq7WqRD46aaCMwR4ApUJ+w== ) 789 example.org. 3600 IN DNSKEY ( 257 3 13 790 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr 791 Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384 792 example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 793 20170616000000 20170526000000 44384 example.org. 794 MPTpfbVvPBXmh2Z4fgjy2GMgcJ8RYpXeOBOBidJDglLh4XQAiFOT6YpGRR5ig 795 tQGINd6gKVYdRSsEtXe1K8zxg== ) 796 example.org. 900 IN DS ( 44384 13 2 797 ec307e2efc8f0117ed96ab48a513c8003e1d9121f1ff11a08b4cdd348d090 798 aa6 ) 799 example.org. 900 IN RRSIG ( DS 13 2 900 20170615000000 800 20170525000000 12651 org. 801 MA3pxiap702Hvc81diwZDcRzLrkKssVzzTqCiJJoZFeNq40GuCOVGgEc+w6aq 802 SVgkgFJrhJISei/kvIZTx8ftw== ) 803 org. 900 IN DNSKEY ( 257 3 13 804 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ 805 HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651 806 org. 900 IN RRSIG ( DNSKEY 13 1 900 20170615000000 807 20170525000000 12651 org. 808 o4L9nBQo8KXF0a7D5268U+Bq8SuW/aePtyuSfvQvP79nN/mzh9P11CsT/opmW 809 kg0u6pqaG9KE1T37jloes8J8w== ) 810 org. 86400 IN DS ( 12651 13 2 811 3979a51f98bbf219fcaf4a4176e766dfa8f9db5c24a75743eb1e704b97a9f 812 abc ) 813 org. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 814 20170530000000 47005 . 815 Mi1c7QrpHnl1MSLJTrq/WM0V0DQKwFPGaMFmHHwm8Yb/b934CUHMXU0dR+cLT 816 hakZNz37edtwPxKKOzZQ6pYUw== ) 817 . 86400 IN DNSKEY ( 257 3 13 818 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 819 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 820 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000 821 20170530000000 47005 . 822 tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK 823 8y3m+LZSLDSBHEocXIiRHWdFg== ) 825 D.4. _443._tcp.www.example.net DNAME 827 example.net. 3600 IN DNAME example.com. 828 example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20170616000000 829 20170526000000 48085 example.net. 830 sTl9oxvpd7KxOZ9e5suevha7Fr+zPc3a0pWEUfjFE5v9Umu5js/vcp1i6hdqy 831 tQ2WXEQDsHeEjw9stupvMJkkg== ) 832 _443._tcp.www.example.net. 3600 IN CNAME ( 833 _443._tcp.www.example.com. ) 834 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 835 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 836 ada ) 837 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 838 20170616000000 20170526000000 1870 example.com. 839 GRsT6bcn3fokM5JMvHF0liq63N/kUX+CrZQZIr4GlFnMr/uoS4P1zOBwc0sft 840 Kd8NsZJAikRr4CpaXITYQMx1w== ) 841 example.net. 3600 IN DNSKEY ( 257 3 13 842 X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d 843 9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085 844 example.net. 3600 IN RRSIG ( DNSKEY 13 2 3600 845 20170616000000 20170526000000 48085 example.net. 846 8jSs5O3AypurKs8JFoAYj30qlmQ9QS29IBoqbyv2ggxtdDZoKWZE0kOuQcRxx 847 q1pP707qRjp98THQSTVh+C0iQ== ) 848 example.net. 900 IN DS ( 48085 13 2 849 7c1998ce683df60e2fa41460c453f88f463dac8cd5d074277b4a7c0450292 850 1be ) 851 example.net. 900 IN RRSIG ( DS 13 2 900 20170615000000 852 20170525000000 485 net. 853 xqN9gHO5HXB+GH2x3DvjpMl6f+CdsVvON2K7G0FDVIL5iFMNLPqCAITlFofWF 854 Ty6VXFKPoy9TZresE/JCL/PFA== ) 855 net. 900 IN DNSKEY ( 257 3 13 856 LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5 857 oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485 858 net. 900 IN RRSIG ( DNSKEY 13 1 900 20170615000000 859 20170525000000 485 net. 860 jEI8WucG9EzJ1Euv0Pq3aNFhoYbvQeLUs19r9YImkWi8QlmH76ZJuLTCGHTDh 861 /Il5cZWukKc3ScptxVA57uRyQ== ) 862 net. 86400 IN DS ( 485 13 2 863 ab25a2941aa7f1eb8688bb783b25587515a0cd8c247769b23adb13ca234d1 864 c05 ) 865 net. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 866 20170530000000 47005 . 867 ZR/UTP2OrYwJQhsCAWsKoIs9OSiUDdBFXzFqYSrV41G1oQsKVSi/NU1tT1UZW 868 CENddWt90XLXZAlSYnv6s8Ceg== ) 869 . 86400 IN DNSKEY ( 257 3 13 870 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 871 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 872 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000 873 20170530000000 47005 . 874 tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK 875 8y3m+LZSLDSBHEocXIiRHWdFg== ) 876 example.com. 3600 IN DNSKEY ( 257 3 13 877 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 878 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 879 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 880 20170616000000 20170526000000 1870 example.com. 881 sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r 882 8q6DBlCdlRQvzD90UKZDIAqbA== ) 883 example.com. 900 IN DS ( 1870 13 2 884 e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81 885 e16 ) 886 example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000 887 20170529000000 18931 com. 888 rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3 889 5XxvbOdLIJAcxhRS1c2VITfMA== ) 890 com. 900 IN DNSKEY ( 257 3 13 891 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 892 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 893 com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000 894 20170529000000 18931 com. 895 wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk 896 c6Nx3HLmhidf6dmt/Hi0ePBsQ== ) 897 com. 86400 IN DS ( 18931 13 2 898 20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52 899 115 ) 900 com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 901 20170530000000 47005 . 902 jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+ 903 jGGQccnLkQnUf7zednetSWalg== ) 905 Authors' Addresses 907 Melinda Shore 908 Fastly 910 EMail: mshore@fastly.com 912 Richard Barnes 913 Mozilla 915 EMail: rlb@ipv.sx 916 Shumon Huque 917 Salesforce 919 EMail: shuque@gmail.com 921 Willem Toorop 922 NLNet Labs 924 EMail: willem@nlnetlabs.nl