idnits 2.17.1 draft-ietf-tls-dnssec-chain-extension-03.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 -- The document date (March 27, 2017) is 2586 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 (~~), 1 warning (==), 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: September 28, 2017 Mozilla 6 S. Huque 7 Salesforce 8 W. Toorop 9 NLNet Labs 10 March 27, 2017 12 A DANE Record and DNSSEC Authentication Chain Extension for TLS 13 draft-ietf-tls-dnssec-chain-extension-03 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 certificate without needing to perform additional DNS record lookups. 22 It will typically not be used for general DNSSEC validation of TLS 23 endpoint 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 September 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 3 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 . . . . . . 8 67 5. Caching and Regeneration of the Authentication Chain . . . . 9 68 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 10 70 8. Mandating use of this extension . . . . . . . . . . . . . . . 10 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 12.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 14 78 Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 14 79 Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 14 80 Appendix D. Test vector . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Requirements Notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Introduction 91 This draft describes a new TLS [RFC5246] extension for transport of a 92 DNS record set serialized with the DNSSEC signatures [RFC4034] needed 93 to authenticate that record set. The intent of this proposal is to 94 allow TLS clients to perform DANE authentication [RFC6698] of a TLS 95 server certificate without performing additional DNS record lookups 96 and incurring the associated latency penalty. It also provides the 97 ability to avoid potential problems with TLS clients being unable to 98 look up DANE records because of an interfering or broken middlebox on 99 the path between the client and a DNS server. And lastly, it allows 100 a TLS client to validate DANE records itself without necessarily 101 needing access to a validating DNS resolver to which it has a secure 102 connection. It will typically not be used for general DNSSEC 103 validation of endpoint names, but is more appropriate for validation 104 of DANE TLSA records. 106 This mechanism is useful for TLS applications that need to address 107 the problems described above, typically web browsers or VoIP and XMPP 108 applications. It may not be relevant for many other applications. 109 For example, SMTP MTAs are usually located in data centers, may 110 tolerate extra DNS lookup latency, are on servers where it is easier 111 to provision a validating resolver, or are less likely to experience 112 traffic interference from misconfigured middleboxes. Furthermore, 113 SMTP MTAs usually employ Opportunistic Security [RFC7435], in which 114 the presence of the DNS TLSA records is used to determine whether to 115 enforce an authenticated TLS connection. Hence DANE authentication 116 of SMTP MTAs [RFC7672] will typically not use this mechanism. 118 The extension described here allows a TLS client to request in the 119 ClientHello message that the DNS authentication chain be returned in 120 the (extended) ServerHello message. If the server is configured for 121 DANE authentication, then it performs the appropriate DNS queries, 122 builds the authentication chain, and returns it to the client. The 123 server will usually use a previously cached authentication chain, but 124 it will need to rebuild it periodically as described in Section 5. 125 The client then authenticates the chain using a pre-configured trust 126 anchor. 128 This specification is based on Adam Langley's original proposal for 129 serializing DNSSEC authentication chains and delivering them in an 130 X.509 certificate extension [I-D.agl-dane-serializechain]. It 131 modifies the approach by using wire format DNS records in the 132 serialized data (assuming that the data will be prepared and consumed 133 by a DNS-specific library), and by using a TLS extension to deliver 134 the data. 136 As described in the DANE specification [RFC6698], this procuedure 137 applies to the DANE authentication of X.509 certificates. Other 138 credentials may be supported, as needed, in the future. 140 3. DNSSEC Authentication Chain Extension 141 3.1. Protocol, TLS 1.2 143 A client MAY include an extension of type "dnssec_chain" in the 144 (extended) ClientHello. The "extension_data" field of this extension 145 MUST be empty. 147 Servers receiving a "dnssec_chain" extension in the ClientHello, and 148 which are capable of being authenticated via DANE, MAY return a 149 serialized authentication chain in the extended ServerHello message, 150 using the format described below. If a server is unable to return an 151 authentication chain, or does not wish to return an authentication 152 chain, it does not include a dnssec_chain extension. As with all TLS 153 extensions, if the server does not support this extension it will not 154 return any authentication chain. 156 A client must not be able to force a server to perform lookups on 157 arbitrary domain names using this mechanism. Therefore, a server 158 MUST NOT construct chains for domain names other than its own. 160 3.2. Protocol, TLS 1.3 162 A client MAY include an extension of type "dnssec_chain" in the 163 ClientHello. The "extension_data" field of this extension MUST be 164 empty. 166 Servers receiving a "dnssec_chain" extension in the ClientHello, and 167 which are capable of being authenticated via DANE, SHOULD return a 168 serialized authentication chain in the Certificate message associated 169 with the end entity certificate being validated, using the format 170 described below. The authentication chain will be an extension to 171 the certificate_list to which the certificate being authenticated 172 belongs. 174 The extension protocol behavior otherwise follows that specified for 175 TLS version 1.2. 177 3.3. Raw Public Keys 179 [RFC7250] specifies the use of raw public keys for both server and 180 client authentication in TLS 1.2. It points out that in cases where 181 raw public keys are being used, code for certificate path validation 182 is not required. However, DANE, when used in conjunction with the 183 dnssec_chain extension, provides a mechanism for securely binding a 184 raw public key to a named entity in the DNS, and when using DANE for 185 authentication a raw key may be validated using a path chaining back 186 to a DNSSEC trust root. This has the added benefit of mitigating an 187 unknown key share attack, as described in [I-D.barnes-dane-uks], 188 since it effectively augments the raw public key with the server's 189 name and provides a means to commit both the server and the client to 190 using that binding. 192 The UKS attack is possible in situations in which the association 193 between a domain name and a public key is not tightly bound, as in 194 the case in DANE in which a client either ignores the name in 195 certificate (as specified in [RFC7671] or there is no attestation of 196 trust outside of the DNS. The vulnerability arises in the following 197 situations: 199 o If the client does not verify the identity in the server's 200 certificate (as recommended in Section 5.1 of [RFC7671]), then an 201 attacker can induce the client to accept an unintended identity 202 for the server, 204 o If the client allows the use of raw public keys in TLS, then it 205 will not receive any indication of the server's identity in the 206 TLS channel, and is thus unable to check that the server's 207 identity is as intended. 209 The mechanism for conveying DNSSEC validation chains described in 210 this document results in a commitment by both parties, via the TLS 211 handshake, to a domain name which has been validated as belonging to 212 the owner name. 214 The mechanism for encoding DNSSEC authentication chains in a TLS 215 extension, as described in this document, is not limited to public 216 keys encapsulated in X.509 containers but MAY be applied to raw 217 public keys and other representations, as well. 219 3.4. DNSSEC Authentication Chain Data 221 The "extension_data" field of the "dnssec_chain" extension MUST 222 contain a DNSSEC Authentication Chain encoded in the following form: 224 opaque AuthenticationChain<0..2^16-1> 226 The AuthenticationChain structure is composed of a sequence of 227 uncompressed wire format DNS resource record sets (RRset) and 228 corresponding signatures (RRsig) records. The record sets and 229 signatures are presented in the order returned by the DNS server 230 queried by the TLS server, although they MAY be returned in 231 validation order, starting at the target DANE record, followed by the 232 DNSKEY and DS record sets for each intervening DNS zone up to a trust 233 anchor chosen by the server, typically the DNS root. 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 The RRsig record is in DNS wire format as described in RFC 4034 255 [RFC4034], Section 3.1. The signature portion of the RDATA, as 256 described in the same section, is the following: 258 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 260 where, RRSIG_RDATA is the wire format of the RRSIG RDATA fields with 261 the Signer's Name field in canonical form and the signature field 262 excluded. 264 The first RRset in the chain MUST contain the DANE records being 265 presented. The subsequent RRsets MUST be a sequence of DNSKEY and DS 266 RRsets, starting with a DNSKEY RRset. Each RRset MUST authenticate 267 the preceding RRset: 269 o A DNSKEY RRset must include the DNSKEY RR containing the public 270 key used to verify the previous RRset. 272 o For a DS RRset, the set of key hashes MUST overlap with the 273 preceding set of DNSKEY records. 275 In addition, a DNSKEY RRset followed by a DS RRset MUST be self- 276 signed, in the sense that its RRSIG MUST verify under one of the keys 277 in the DNSKEY RRSET. 279 The final DNSKEY RRset in the authentication chain, containing the 280 trust anchor may be omitted. If omitted, the client MUST verify that 281 the key tag and owner name in the final RRSIG record correspond to a 282 trust anchor. There may however be reason to include the trust 283 anchor RRset and signature if clients are expected to use RFC5011 284 compliant key rollover functions inband via the chain data. In that 285 case, they will need to periodically inspect flags (revocation and 286 secure entry point flags) on the trust anchor DNSKEY RRset. 288 For example, for an HTTPS server at www.example.com, where there are 289 zone cuts at "com." and "example.com.", the AuthenticationChain 290 structure would comprise the following RRsets and signatures (the 291 data field of the records are omitted here for brevity): 293 _443._tcp.www.example.com. TLSA 294 RRSIG(_443._tcp.www.example.com. TLSA) 295 example.com. DNSKEY 296 RRSIG(example.com. DNSKEY) 297 example.com. DS 298 RRSIG(example.com. DS) 299 com. DNSKEY 300 RRSIG(com. DNSKEY) 301 com. DS 302 RRSIG(com. DS) 303 . DNSKEY 304 RRSIG(. DNSKEY) 306 Names that are aliased via CNAME and/or DNAME records may involve 307 multiple branches of the DNS tree. In this case the authentication 308 chain structure will be composed of a sequence of these multiple 309 intersecting branches. DNAME chains should omit unsigned CNAME 310 records that may have been synthesized in the response from a DNS 311 resolver. Wildcard DANE records will need to include the wildcard 312 name, and negative proof (i.e. NSEC or NSEC3 records) that no closer 313 name exists MUST be included. 315 A CNAME example: 317 _443._tcp.www.example.com. IN CNAME ca.example.net. 318 ca.example.net. IN TLSA 2 0 1 ... 320 Here the authentication chain structure is composed of two 321 consecutive chains, one for _443._tcp.www.example.com/CNAME 322 and one for ca.example.net/TLSA. The second chain can omit 323 the record sets at the end that overlap with the first. 325 TLS DNSSEC chain components: 327 _443._tcp.www.example.com. CNAME 328 RRSIG(_443._tcp.www.example.com. CNAME) 329 example.com. DNSKEY 330 RRSIG(example.com. DNSKEY) 331 example.com. DS 332 RRSIG(example.com. DS) 333 com. DNSKEY 334 RRSIG(com. DNSKEY) 335 com. DS 336 RRSIG(com. DS) 337 . DNSKEY 338 RRSIG(. DNSKEY) 340 ca.example.net. TLSA 341 RRSIG(ca.example.net. TLSA) 342 example.net. DNSKEY 343 RRSIG(example.net. DNSKEY) 344 example.net. DS 345 RRSIG(example.net. DS) 346 net. DNSKEY 347 RRSIG(net. DNSKEY) 348 net. DS 349 RRSIG(net. DS) 351 Note as well that if a user has a specific TLSA record for port 443, 352 and a different wildcard covering other ports, attackers MUST NOT be 353 able to substitute the wildcard TLSA RRset for the more specific one 354 for port 443. DNSSEC wildcards must not be confused with the X.509 355 wildcards. 357 4. Construction of Serialized Authentication Chains 359 This section describes a possible procedure for the server to use to 360 build the serialized DNSSEC chain. 362 When the goal is to perform DANE authentication [RFC6698] of the 363 server's X.509 certificate, the DNS record set to be serialized is a 364 TLSA record set corresponding to the server's domain name. 366 The domain name of the server MUST be that included in the TLS 367 server_name extension [RFC6066] when present. If the server_name 368 extension is not present, or if the server does not recognize the 369 provided name and wishes to proceed with the handshake rather than to 370 abort the connection, the server uses the domain name associated with 371 the server IP address to which the connection has been established. 373 The TLSA record to be queried is constructed by prepending the _port 374 and _transport labels to the domain name as described in [RFC6698], 375 where "port" is the port number associated with the TLS server. The 376 transport is "tcp" for TLS servers, and "udp" for DTLS servers. The 377 port number label is the left-most label, followed by the transport, 378 followed by the base domain name. 380 The components of the authentication chain are built by starting at 381 the target record set and its corresponding RRSIG. Then traversing 382 the DNS tree upwards towards the trust anchor zone (normally the DNS 383 root), for each zone cut, the DNSKEY and DS RRsets and their 384 signatures are added. If DNS responses messages contain any domain 385 names utilizing name compression [RFC1035], then they must be 386 uncompressed. 388 In the future, proposed DNS protocol enhancements, such as the EDNS 389 Chain Query extension [RFC7901] may offer easy ways to obtain all of 390 the chain data in one transaction with an upstream DNSSEC aware 391 recursive server. 393 5. Caching and Regeneration of the Authentication Chain 395 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 396 have validity periods (specifically signature expiration times). 397 After the TLS server constructs the serialized authentication chain, 398 it SHOULD cache and reuse it in multiple TLS connection handshakes. 399 However, it MUST refresh and rebuild the chain as TTLs and signature 400 validity periods dictate. A server implementation could carefully 401 track these parameters and requery component records in the chain 402 correspondingly. Alternatively, it could be configured to rebuild 403 the entire chain at some predefined periodic interval that does not 404 exceed the DNS TTLs or signature validity periods of the component 405 records in the chain. 407 6. Verification 409 A TLS client making use of this specification, and which receives a 410 DNSSEC authentication chain extension from a server, SHOULD use this 411 information to perform DANE authentication of the server certificate. 412 In order to do this, it uses the mechanism specified by the DNSSEC 413 protocol [RFC4035]. This mechanism is sometimes implemented in a 414 DNSSEC validation engine or library. 416 If the authentication chain is correctly verified, the client then 417 performs DANE authentication of the server according to the DANE TLS 418 protocol [RFC6698], and the additional protocol requirements outlined 419 in [RFC7671]. 421 7. Trust Anchor Maintenance 423 The trust anchor may change periodically, e.g. when the operator of 424 the trust anchor zone performs a DNSSEC key rollover. Managed key 425 rollovers typically use a process that can be tracked by verifiers 426 allowing them to automatically update their trust anchors, as 427 described in [RFC5011]. TLS clients using this specification are 428 also expected to use such a mechanism to keep their trust anchors 429 updated. Some operating systems may have a system-wide service to 430 maintain and keep the root trust anchor up to date. In such cases, 431 the TLS client application could simply reference that as its trust 432 anchor, periodically checking whether it has changed. 434 8. Mandating use of this extension 436 A TLS server certificate MAY mandate the use of this extension by 437 means of the X.509 TLS Feature Extension described in [RFC7633]. 438 This X.509 certificate extension, when populated with the 439 dnssec_chain TLS extension identifier, indicates to the client that 440 the server must deliver the authentication chain when asked to do so. 441 (The X.509 TLS Feature Extension is the same mechanism used to 442 deliver other mandatory signals, such as OCSP "must staple" 443 assertions.) 445 9. Security Considerations 447 The security considerations of the normatively referenced RFCs (1035, 448 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this 449 extension. Since the server is delivering a chain of DNS records and 450 signatures to the client, it MUST rebuild the chain in accordance 451 with TTL and signature expiration of the chain components as 452 described in Section 5. TLS clients need roughly accurate time in 453 order to properly authenticate these signatures. This could be 454 achieved by running a time synchronization protocol like NTP 456 [RFC5905] or SNTP [RFC5905], which are already widely used today. 457 TLS clients MUST support a mechanism to track and rollover the trust 458 anchor key, or be able to avail themselves of a service that does 459 this, as described in Section 7. 461 10. IANA Considerations 463 This extension requires the registration of a new value in the TLS 464 ExtensionsType registry. The value requested from IANA is 53. If 465 the draft is adopted by the WG, the authors expect to make an early 466 allocation request as specified in [RFC7120]. 468 11. Acknowledgments 470 Many thanks to Adam Langley for laying the groundwork for this 471 extension. The original idea is his but our acknowledgment in no way 472 implies his endorsement. This document also benefited from 473 discussions with and review from the following people: Viktor 474 Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick 475 McManus, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico 476 Williams, and Paul Wouters. 478 12. References 480 12.1. Normative References 482 [RFC1035] Mockapetris, P., "Domain names - implementation and 483 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 484 November 1987, . 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 492 Rose, "Resource Records for the DNS Security Extensions", 493 RFC 4034, DOI 10.17487/RFC4034, March 2005, 494 . 496 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 497 Rose, "Protocol Modifications for the DNS Security 498 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 499 . 501 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 502 (TLS) Protocol Version 1.2", RFC 5246, 503 DOI 10.17487/RFC5246, August 2008, 504 . 506 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 507 Extensions: Extension Definitions", RFC 6066, 508 DOI 10.17487/RFC6066, January 2011, 509 . 511 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 512 of Named Entities (DANE) Transport Layer Security (TLS) 513 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 514 2012, . 516 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) 517 Feature Extension", RFC 7633, DOI 10.17487/RFC7633, 518 October 2015, . 520 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 521 Authentication of Named Entities (DANE) Protocol: Updates 522 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 523 October 2015, . 525 12.2. Informative References 527 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 528 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 529 September 2007, . 531 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 532 "Network Time Protocol Version 4: Protocol and Algorithms 533 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 534 . 536 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 537 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 538 2014, . 540 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 541 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 542 Transport Layer Security (TLS) and Datagram Transport 543 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 544 June 2014, . 546 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 547 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 548 December 2014, . 550 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 551 Opportunistic DNS-Based Authentication of Named Entities 552 (DANE) Transport Layer Security (TLS)", RFC 7672, 553 DOI 10.17487/RFC7672, October 2015, 554 . 556 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, 557 DOI 10.17487/RFC7901, June 2016, 558 . 560 [I-D.agl-dane-serializechain] 561 Langley, A., "Serializing DNS Records with DNSSEC 562 Authentication", draft-agl-dane-serializechain-01 (work in 563 progress), July 2011. 565 [I-D.barnes-dane-uks] 566 Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key- 567 Share Attacks on DNS-based Authentications of Named 568 Entities (DANE)", draft-barnes-dane-uks-00 (work in 569 progress), October 2016. 571 Appendix A. Updates from -01 and -02 573 o Editorial updates for style and consistency 575 o Updated discussion of UKS attack 577 Appendix B. Updates from -01 579 o Added TLS 1.3 support 581 o Added section describing applicability to raw public keys 583 o Softened language about record order 585 Appendix C. Updates from -00 587 o Edits based on comments from Rick van Rein 589 o Warning about not overloading X.509 wildcards on DNSSEC wildcards 590 (from V. Dukhovny) 592 o Added MUST include negative proof on wildcards (from V. Dukhovny) 594 o Removed "TODO" on allowing the server to deliver only one 595 signature per RRset 597 o Added additional minor edits suggested by Viktor Dukhovny 599 Appendix D. Test vector 601 [data go here] 603 Authors' Addresses 605 Melinda Shore 606 Fastly 608 EMail: mshore@fastly.com 610 Richard Barnes 611 Mozilla 613 EMail: rlb@ipv.sx 614 Shumon Huque 615 Salesforce 617 EMail: shumon.huque@gmail.com 619 Willem Toorop 620 NLNet Labs 622 EMail: willem@nlnetlabs.nl