idnits 2.17.1 draft-ietf-tls-dnssec-chain-extension-02.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 (January 11, 2017) is 2667 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 No Mountain Software 4 Intended status: Standards Track R. Barnes 5 Expires: July 15, 2017 Mozilla 6 S. Huque 7 Verisign Labs 8 W. Toorop 9 NLNet Labs 10 January 11, 2017 12 A DANE Record and DNSSEC Authentication Chain Extension for TLS 13 draft-ietf-tls-dnssec-chain-extension-02 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 July 15, 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 . . . . 8 68 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9 70 8. Mandating use of this extension . . . . . . . . . . . . . . . 9 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 13 78 Appendix B. Updates from -00 . . . . . . . . . . . . . . . . . . 13 79 Appendix C. Test vector . . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Requirements Notation 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 This draft describes a new TLS [RFC5246] extension for transport of a 91 DNS record set serialized with the DNSSEC signatures [RFC4034] needed 92 to authenticate that record set. The intent of this proposal is to 93 allow TLS clients to perform DANE authentication [RFC6698] of a TLS 94 server certificate without performing additional DNS record lookups 95 and incurring the associated latency penalty. It also provides the 96 ability to avoid potential problems with TLS clients being unable to 97 look up DANE records because of an interfering or broken middlebox on 98 the path between the client and a DNS server. And lastly, it allows 99 a TLS client to validate DANE records itself without necessarily 100 needing access to a validating DNS resolver to which it has a secure 101 connection. It will typically not be used for general DNSSEC 102 validation of endpoint names, but is more appropriate for validation 103 of DANE TLSA records. 105 This mechanism is useful for TLS applications that need to address 106 the problems described above, typically web browsers or VoIP and XMPP 107 applications. It may not be relevant for many other applications. 108 For example, SMTP MTAs are usually located in data centers, may 109 tolerate extra DNS lookup latency, are on servers where it is easier 110 to provision a validating resolver, or are less likely to experience 111 traffic interference from misconfigured middleboxes. Furthermore, 112 SMTP MTAs usually employ Opportunistic Security [RFC7435], in which 113 the presence of the DNS TLSA records is used to determine whether to 114 enforce an authenticated TLS connection. Hence DANE authentication 115 of SMTP MTAs [RFC7672] will typically not use this mechanism. 117 The extension described here allows a TLS client to request in the 118 client hello message that the DNS authentication chain be returned in 119 the (extended) server hello message. If the server is configured for 120 DANE authentication, then it performs the appropriate DNS queries, 121 builds the authentication chain, and returns it to the client. The 122 server will usually use a previously cached authentication chain, but 123 it will need to rebuild it periodically as described in Section 5. 124 The client then authenticates the chain using a pre-configured trust 125 anchor. 127 This specification is based on Adam Langley's original proposal for 128 serializing DNSSEC authentication chains and delivering them in an 129 X.509 certificate extension [I-D.agl-dane-serializechain]. It 130 modifies the approach by using wire format DNS records in the 131 serialized data (assuming that the data will be prepared and consumed 132 by a DNS-specific library), and by using a TLS extension to deliver 133 the data. 135 As described in the DANE specification [RFC6698], this procuedure 136 applies to the DANE authentication of X.509 certificates. Other 137 credentials may be supported, as needed, in the future. 139 3. DNSSEC Authentication Chain Extension 140 3.1. Protocol, TLS 1.2 142 A client MAY include an extension of type "dnssec_chain" in the 143 (extended) ClientHello. The "extension_data" field of this extension 144 MUST be empty. 146 Servers receiving a "dnssec_chain" extension in the client hello, and 147 which are capable of being authenticated via DANE, MAY return a 148 serialized authentication chain in the extended ServerHello message, 149 using the format described below. If a server is unable to return an 150 authentication chain, or does not wish to return an authentication 151 chain, it does not include a dnssec_chain extension. As with all TLS 152 extensions, if the server does not support this extension it will not 153 return any authentication chain. 155 A client must not be able to force a server to perform lookups on 156 arbitrary domain names using this mechanism. Therefore, a server 157 MUST NOT construct chains for domain names other than its own. 159 3.2. Protocol, TLS 1.3 161 A client MAY include an extension of type "dnssec_chain" in the 162 ClientHello. The "extension_data" field of this extension MUST be 163 empty. 165 Servers receiving a "dnssec_chain" extension in the client hello, and 166 which are capable of being authenticated via DANE, SHOULD return a 167 serialized authentication chain in the Certificate message, using the 168 format described below. The authentication chain will be an 169 extension to the certificate_list to which the certificate being 170 authenticated belongs. 172 The extension protocol behavior otherwise follows that specified for 173 TLS version 1.2. 175 3.3. Raw Public Keys 177 [RFC7250] specifies the use of raw public keys for both server and 178 client authentication in TLS 1.2. It points out that in cases where 179 raw public keys are being used, code for certificate path validation 180 is not required. However, DANE provides a mechanism for securely 181 binding a raw public key to a named entity in the DNS, and when using 182 DANE for authentication a raw key may be validated using a path 183 chaining back to a DNSSEC trust root. This has the added benefit of 184 mitigating an unknown key share attack, as described in 185 [I-D.barnes-dane-uks]. 187 The mechanism for encoding DNSSEC authentication chains in a TLS 188 extension, as described in this document, is not limited to public 189 keys encapsulated in PKIX or X.509 containers but MAY be applied to 190 raw public keys and other representations, as well. 192 3.4. DNSSEC Authentication Chain Data 194 The "extension_data" field of the "dnssec_chain" extension MUST 195 contain a DNSSEC Authentication Chain encoded in the following form: 197 opaque AuthenticationChain<0..2^16-1> 199 The AuthenticationChain structure is composed of a sequence of 200 uncompressed wire format DNS resource record sets (RRset) and 201 corresponding signatures (RRsig) records. The record sets and 202 signatures are presented in the order returned by the DNS server 203 queried by the TLS server, although they MAY be returned in 204 validation order, starting at the target DANE record, followed by the 205 DNSKEY and DS record sets for each intervening DNS zone up to a trust 206 anchor chosen by the server, typically the DNS root. 208 This sequence of native DNS wire format records enables easier 209 generation of the data structure on the server and easier 210 verification of the data on client by means of existing DNS library 211 functions. However this document describes the data structure in 212 sufficient detail that implementers if they desire can write their 213 own code to do this. 215 Each RRset in the chain is composed of a sequence of wire format DNS 216 resource records. The format of the resource record is described in 217 RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be 218 presented in the canonical form and ordering as described in RFC 4034 219 [RFC4034]. 221 RR(i) = owner | type | class | TTL | RDATA length | RDATA 223 RRs within the RRset MAY be ordered canonically, by treating the 224 RDATA portion of each RR as a left-justified unsigned octet sequence 225 in which the absence of an octet sorts before a zero octet. 227 The RRsig record is in DNS wire format as described in RFC 4034 228 [RFC4034], Section 3.1. The signature portion of the RDATA, as 229 described in the same section, is the following: 231 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 233 where, RRSIG_RDATA is the wire format of the RRSIG RDATA fields with 234 the Signer's Name field in canonical form and the signature field 235 excluded. 237 The first RRset in the chain MUST contain the DANE records being 238 presented. The subsequent RRsets MUST be a sequence of DNSKEY and DS 239 RRsets, starting with a DNSKEY RRset. Each RRset MUST authenticate 240 the preceding RRset: 242 o A DNSKEY RRset must include the DNSKEY RR containing the public 243 key used to verify the previous RRset. 245 o For a DS RRset, the set of key hashes MUST overlap with the 246 preceding set of DNSKEY records. 248 In addition, a DNSKEY RRset followed by a DS RRset MUST be self- 249 signed, in the sense that its RRSIG MUST verify under one of the keys 250 in the DNSKEY RRSET. 252 The final DNSKEY RRset in the authentication chain, containing the 253 trust anchor may be omitted. If omitted, the client MUST verify that 254 the key tag and owner name in the final RRSIG record correspond to a 255 trust anchor. There may however be reason to include the trust 256 anchor RRset and signature if clients are expected to use RFC5011 257 compliant key rollover functions inband via the chain data. In that 258 case, they will need to periodically inspect flags (revocation and 259 secure entry point flags) on the trust anchor DNSKEY RRset. 261 For example, for an HTTPS server at www.example.com, where there are 262 zone cuts at "com." and "example.com.", the AuthenticationChain 263 structure would comprise the following RRsets and signatures (the 264 data field of the records are omitted here for brevity): 266 _443._tcp.www.example.com. TLSA 267 RRSIG(_443._tcp.www.example.com. TLSA) 268 example.com. DNSKEY 269 RRSIG(example.com. DNSKEY) 270 example.com. DS 271 RRSIG(example.com. DS) 272 com. DNSKEY 273 RRSIG(com. DNSKEY) 274 com. DS 275 RRSIG(com. DS) 276 . DNSKEY 277 RRSIG(. DNSKEY) 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 will be composed of a sequence of these multiple 282 intersecting branches. DNAME chains should omit unsigned CNAME 283 records that may have been synthesized in the response from a DNS 284 resolver. Wildcard DANE records will need to include the wildcard 285 name, and negative proof (i.e. NSEC or NSEC3 records) that no closer 286 name exists MUST be included. 288 A CNAME example: 290 _443._tcp.www.example.com. IN CNAME ca.example.net. 291 ca.example.net. IN TLSA 2 0 1 ... 293 Here the authentication chain structure is composed of two 294 consecutive chains, one for _443._tcp.www.example.com/CNAME 295 and one for ca.example.net/TLSA. The second chain can omit 296 the record sets at the end that overlap with the first. 298 TLS DNSSEC chain components: 300 _443._tcp.www.example.com. CNAME 301 RRSIG(_443._tcp.www.example.com. CNAME) 302 example.com. DNSKEY 303 RRSIG(example.com. DNSKEY) 304 example.com. DS 305 RRSIG(example.com. DS) 306 com. DNSKEY 307 RRSIG(com. DNSKEY) 308 com. DS 309 RRSIG(com. DS) 310 . DNSKEY 311 RRSIG(. DNSKEY) 313 ca.example.net. TLSA 314 RRSIG(ca.example.net. TLSA) 315 example.net. DNSKEY 316 RRSIG(example.net. DNSKEY) 317 example.net. DS 318 RRSIG(example.net. DS) 319 net. DNSKEY 320 RRSIG(net. DNSKEY) 321 net. DS 322 RRSIG(net. DS) 324 Note as well that if a user has a specific TLSA record for port 443, 325 and a different wildcard covering other ports, attackers MUST NOT be 326 able to substitute the wildcard TLSA RRset for the more specific one 327 for port 443. DNSSEC wildcards must not be confused with the X.509 328 wildcards. 330 4. Construction of Serialized Authentication Chains 332 This section describes a possible procedure for the server to use to 333 build the serialized DNSSEC chain. 335 When the goal is to perform DANE authentication [RFC6698] of the 336 server's X.509 certificate, the DNS record set to be serialized is a 337 TLSA record set corresponding to the server's domain name. 339 The domain name of the server MUST be that included in the TLS Server 340 Name Indication extension [RFC6066] when present. If the Server Name 341 Indication extension is not present, or if the server does not 342 recognize the provided name and wishes to proceed with the handshake 343 rather than to abort the connection, the server uses the domain name 344 associated with the server IP address to which the connection has 345 been established. 347 The TLSA record to be queried is constructed by prepending the _port 348 and _transport labels to the domain name as described in [RFC6698], 349 where "port" is the port number associated with the TLS server. The 350 transport is "tcp" for TLS servers, and "udp" for DTLS servers. The 351 port number label is the left-most label, followed by the transport, 352 followed by the base domain name. 354 The components of the authentication chain are built by starting at 355 the target record set and its corresponding RRSIG. Then traversing 356 the DNS tree upwards towards the trust anchor zone (normally the DNS 357 root), for each zone cut, the DNSKEY and DS RRsets and their 358 signatures are added. If DNS responses messages contain any domain 359 names utilizing name compression [RFC1035], then they must be 360 uncompressed. 362 In the future, proposed DNS protocol enhancements, such as the EDNS 363 Chain Query extension [RFC7901] may offer easy ways to obtain all of 364 the chain data in one transaction with an upstream DNSSEC aware 365 recursive server. 367 5. Caching and Regeneration of the Authentication Chain 369 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 370 have validity periods (specifically signature expiration times). 371 After the TLS server constructs the serialized authentication chain, 372 it SHOULD cache and reuse it in multiple TLS connection handshakes. 373 However, it MUST refresh and rebuild the chain as TTLs and signature 374 validity periods dictate. A server implementation could carefully 375 track these parameters and requery component records in the chain 376 correspondingly. Alternatively, it could be configured to rebuild 377 the entire chain at some predefined periodic interval that does not 378 exceed the DNS TTLs or signature validity periods of the component 379 records in the chain. 381 6. Verification 383 A TLS client making use of this specification, and which receives a 384 DNSSEC authentication chain extension from a server, SHOULD use this 385 information to perform DANE authentication of the server certificate. 386 In order to do this, it uses the mechanism specified by the DNSSEC 387 protocol [RFC4035]. This mechanism is sometimes implemented in a 388 DNSSEC validation engine or library. 390 If the authentication chain is correctly verified, the client then 391 performs DANE authentication of the server according to the DANE TLS 392 protocol [RFC6698], and the additional protocol requirements outlined 393 in [RFC7671]. 395 7. Trust Anchor Maintenance 397 The trust anchor may change periodically, e.g. when the operator of 398 the trust anchor zone performs a DNSSEC key rollover. Managed key 399 rollovers typically use a process that can be tracked by verifiers 400 allowing them to automatically update their trust anchors, as 401 described in [RFC5011]. TLS clients using this specification are 402 also expected to use such a mechanism to keep their trust anchors 403 updated. Some operating systems may have a system-wide service to 404 maintain and keep the root trust anchor up to date. In such cases, 405 the TLS client application could simply reference that as its trust 406 anchor, periodically checking whether it has changed. 408 8. Mandating use of this extension 410 A TLS server certificate MAY mandate the use of this extension by 411 means of the X.509 TLS Feature Extension described in [RFC7633]. 412 This X.509 certificate extension, when populated with the 413 dnssec_chain TLS extension identifier, indicates to the client that 414 the server must deliver the authentication chain when asked to do so. 415 (The X.509 TLS Feature Extension is the same mechanism used to 416 deliver other mandatory signals, such as OCSP "must staple" 417 assertions.) 419 9. Security Considerations 421 The security considerations of the normatively referenced RFCs (1035, 422 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this 423 extension. Since the server is delivering a chain of DNS records and 424 signatures to the client, it MUST rebuild the chain in accordance 425 with TTL and signature expiration of the chain components as 426 described in Section 5. TLS clients need roughly accurate time in 427 order to properly authenticate these signatures. This could be 428 achieved by running a time synchronization protocol like NTP 429 [RFC5905] or SNTP [RFC5905], which are already widely used today. 430 TLS clients MUST support a mechanism to track and rollover the trust 431 anchor key, or be able to avail themselves of a service that does 432 this, as described in Section 7. 434 10. IANA Considerations 436 This extension requires the registration of a new value in the TLS 437 ExtensionsType registry. The value requested from IANA is 53. If 438 the draft is adopted by the WG, the authors expect to make an early 439 allocation request as specified in [RFC7120]. 441 11. Acknowledgments 443 Many thanks to Adam Langley for laying the groundwork for this 444 extension. The original idea is his but our acknowledgment in no way 445 implies his endorsement. This document also benefited from 446 discussions with and review from the following people: Viktor 447 Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick 448 McManus, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico 449 Williams, and Paul Wouters. 451 12. References 453 12.1. Normative References 455 [RFC1035] Mockapetris, P., "Domain names - implementation and 456 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 457 November 1987, . 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, 462 . 464 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 465 Rose, "Resource Records for the DNS Security Extensions", 466 RFC 4034, DOI 10.17487/RFC4034, March 2005, 467 . 469 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 470 Rose, "Protocol Modifications for the DNS Security 471 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 472 . 474 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 475 (TLS) Protocol Version 1.2", RFC 5246, 476 DOI 10.17487/RFC5246, August 2008, 477 . 479 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 480 Extensions: Extension Definitions", RFC 6066, 481 DOI 10.17487/RFC6066, January 2011, 482 . 484 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 485 of Named Entities (DANE) Transport Layer Security (TLS) 486 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 487 2012, . 489 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) 490 Feature Extension", RFC 7633, DOI 10.17487/RFC7633, 491 October 2015, . 493 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 494 Authentication of Named Entities (DANE) Protocol: Updates 495 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 496 October 2015, . 498 12.2. Informative References 500 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 501 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 502 September 2007, . 504 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 505 "Network Time Protocol Version 4: Protocol and Algorithms 506 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 507 . 509 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 510 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 511 2014, . 513 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 514 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 515 Transport Layer Security (TLS) and Datagram Transport 516 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 517 June 2014, . 519 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 520 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 521 December 2014, . 523 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 524 Opportunistic DNS-Based Authentication of Named Entities 525 (DANE) Transport Layer Security (TLS)", RFC 7672, 526 DOI 10.17487/RFC7672, October 2015, 527 . 529 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, 530 DOI 10.17487/RFC7901, June 2016, 531 . 533 [I-D.agl-dane-serializechain] 534 Langley, A., "Serializing DNS Records with DNSSEC 535 Authentication", draft-agl-dane-serializechain-01 (work in 536 progress), July 2011. 538 [I-D.barnes-dane-uks] 539 Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key- 540 Share Attacks on DNS-based Authentications of Named 541 Entities (DANE)", draft-barnes-dane-uks-00 (work in 542 progress), October 2016. 544 Appendix A. Updates from -01 546 o Added TLS 1.3 support 548 o Added section describing applicability to raw public keys 550 o Softened language about record order 552 Appendix B. Updates from -00 554 o Edits based on comments from Rick van Rein 556 o Warning about not overloading X.509 wildcards on DNSSEC wildcards 557 (from V. Dukhovny) 559 o Added MUST include negative proof on wildcards (from V. Dukhovny) 561 o Removed "TODO" on allowing the server to deliver only one 562 signature per RRset 564 o Added additional minor edits suggested by Viktor Dukhovny 566 Appendix C. Test vector 568 [data go here] 570 Authors' Addresses 572 Melinda Shore 573 No Mountain Software 575 EMail: melinda.shore@nomountain.net 577 Richard Barnes 578 Mozilla 580 EMail: rlb@ipv.sx 582 Shumon Huque 583 Verisign Labs 585 EMail: shuque@verisign.com 586 Willem Toorop 587 NLNet Labs 589 EMail: willem@nlnetlabs.nl