idnits 2.17.1 draft-shore-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 (October 19, 2015) is 3083 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) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: April 21, 2016 Mozilla 6 S. Huque 7 Verisign Labs 8 W. Toorop 9 NLNet Labs 10 October 19, 2015 12 A DANE Record and DNSSEC Authentication Chain Extension for TLS 13 draft-shore-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 April 21, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. DNSSEC Authentication Chain Data . . . . . . . . . . . . 4 64 4. Construction of Serialized Authentication Chains . . . . . . 7 65 5. Caching and Regeneration of the Authentication Chain . . . . 8 66 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 8 68 8. Mandating use of this extension . . . . . . . . . . . . . . . 8 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 12.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Appendix A. Pseudocode example . . . . . . . . . . . . . . . . . 11 76 Appendix B. Test vector . . . . . . . . . . . . . . . . . . . . 11 78 1. Requirements Notation 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 This draft describes a new TLS [RFC5246] extension for transport of a 87 DNS record set serialized with the DNSSEC signatures [RFC4034] needed 88 to authenticate that record set. The intent of this proposal is to 89 allow TLS clients to perform DANE authentication [RFC6698] of a TLS 90 server certificate without performing perform additional DNS record 91 lookups and incurring the associated latency penalty. It also 92 provides the ability to avoid potential problems with TLS clients 93 being unable to look up DANE records because of an interfering or 94 broken middlebox on the path between the endpoint and a DNS server. 95 And lastly, it allows a TLS client to validate DANE records itself 96 without needing access to a validating DNS resolver to which it has a 97 secure connection. It will typically not be used for general DNSSEC 98 validation of endpoint names, but is more appropriate for validation 99 of DANE TLSA records. 101 This mechanism is useful for TLS applications that need to address 102 the problems described above, typically web browsers or VoIP and XMPP 103 services. It may not be relevant for many other applications. For 104 example, SMTP MTAs are usually located in data centers, may tolerate 105 extra DNS lookup latency, are on servers where it is easier to 106 provision a validating resolver, or are less likely to experience 107 traffic interference from misconfigured middleboxes. Furthermore, 108 SMTP MTAs usually employ Opportunistic Security [RFC7435], in which 109 the presence of the DNS TLSA records is used to determine whether to 110 enforce an authenticated TLS connection. Hence DANE authentication 111 of SMTP MTAs [RFC7672] will typically not use this mechanism. 113 The extension described here allows a TLS client to request in the 114 client hello message that the DNS authentication chain be returned in 115 the (extended) server hello message. If the server is configured for 116 DANE authentication, then it performs the appropriate DNS queries, 117 builds the authentication chain, and returns it to the client. The 118 server will usually use a previously cached authentication chain, but 119 it will need to rebuild it periodically as described in Section 5. 120 The client then authenticates the chain using a pre-configured trust 121 anchor. 123 This specification is based on Adam Langley's original proposal for 124 serializing DNSSEC authentication chains and delivering them in an 125 X.509 certificate extension [AGL]. It modifies the approach by using 126 wire format DNS records in the serialized data (assuming that the 127 data will be prepared and consumed by a DNS-specific library), and by 128 using a TLS extension to deliver the data. 130 3. DNSSEC Authentication Chain Extension 132 3.1. Protocol 134 A client MAY include an extension of type "dnssec_chain" in the 135 (extended) ClientHello. The "extension_data" field of this extension 136 MUST be empty. 138 Servers receiving a "dnssec_chain" extension in the client hello, and 139 which are capable of being authenticated via DANE, SHOULD return a 140 serialized authentication chain in the extended ServerHello message, 141 using the format described below. If a server is unable to return a 142 authentication chain, or does not wish to return a authentication 143 chain, it does not include a dnssec_chain extension. As with all TLS 144 extensions, if the server does not support this extension it will not 145 return any authentication chain. 147 3.2. DNSSEC Authentication Chain Data 149 The "extension_data" field of the "dnssec_chain" extension MUST 150 contain a DNSSEC Authentication Chain encoded in the following form: 152 opaque AuthenticationChain<0..2^16-1>; 154 The AuthenticationChain structure is composed of a sequence of 155 uncompressed wire format DNS resource record sets (RRset) and 156 corresponding signatures (RRsig) records. The record sets and 157 signatures are presented in validation order, starting at the target 158 DANE record, followed by the DNSKEY and DS record sets for each 159 intervening DNS zone up to a trust anchor chosen by the server, 160 typically the DNS root. 162 This sequence of native DNS wire format records enables easier 163 generation of the data structure on the server and easier 164 verification of the data on client by means of existing DNS library 165 functions. However this document describes the data structure in 166 sufficient detail that implementers if they desire can write their 167 own code to do this. 169 [TODO: mention that to reduce the size of the chain, the server can 170 deliver exactly one RRsig per RRset, namely the one used to validate 171 the chain as it is built.] 173 Each RRset in the chain is composed of a sequence of wire format DNS 174 resource records. The format of the resource record is described in 175 RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be 176 presented in the canonical form and ordering as described in RFC 4034 177 [RFC4034]. 179 RR(i) = owner | type | class | TTL | RDATA length | RDATA 181 RRs within the RRset are ordered canonically, by treating the RDATA 182 portion of each RR as a left-justified unsigned octet sequence in 183 which the absence of an octet sorts before a zero octet. 185 The RRsig record is in DNS wire format as described in RFC 4034 186 [RFC4034], Section 3.1. The signature portion of the RDATA, as 187 described in the same section, is the following: 189 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 191 where, RRSIG_RDATA is the wire format of the RRSIG RDATA fields with 192 the Signer's Name field in canonical form and the signature field 193 excluded. 195 The first RRset in the chain MUST contain the DANE records being 196 presented. The subsequent RRsets MUST be a sequence of DNSKEY and DS 197 RRsets, starting with a DNSKEY RRset. Each RRset MUST authenticate 198 the preceding RRset: 200 A DNSKEY RRset must include the DNSKEY RR containing the public 201 key used to verify the previous RRset. 203 For a DS RRset, the set of key hashes MUST overlap with the 204 preceding set of DNSKEY records. 206 In addition, a DNSKEY RRset followed by a DS RRset MUST be self- 207 signed, in the sense that its RRSIG MUST verify under one of the keys 208 in the DNSKEY RRSET. 210 The final DNSKEY RRset in the authentication chain, containing the 211 trust anchor may be omitted. If omitted, the client MUST verify that 212 the key tag and owner name in the final RRSIG record correspond to a 213 trust anchor. There may however be reason to include the trust 214 anchor RRset and signature if clients are expected to use RFC5011 215 compliant key rollover functions inband via the chain data. In that 216 case, they will need to periodically inspect flags (revocation and 217 secure entry point flags) on the trust anchor DNSKEY RRset. 219 For example, for an HTTPS server at www.example.com, where there are 220 zone cuts at "com." and "example.com.", the AuthenticationChain 221 structure would comprise the following RRsets and signatures (the 222 data field of the records are omitted here for brevity): 224 _443._tcp.www.example.com. TLSA 225 RRSIG(_443._tcp.www.example.com. TLSA) 226 example.com. DNSKEY 227 RRSIG(example.com. DNSKEY) 228 example.com. DS 229 RRSIG(example.com. DS) 230 com. DNSKEY 231 RRSIG(com. DNSKEY) 232 com. DS 233 RRSIG(com. DS) 234 . DNSKEY 235 RRSIG(. DNSKEY) 237 Names that are aliased via CNAME and/or DNAME records may involve 238 multiple branches of the DNS tree. In this case the authentication 239 chain structure will be composed of a sequence of these multiple 240 intersecting branches. DNAME chains should omit unsigned CNAME 241 records that may have been synthesized in the response from a DNS 242 resolver. Wildcard DANE records will need to include the wildcard 243 name as well as a negative proof (i.e. NSEC or NSEC3 records) that no 244 closer name exists. 246 A CNAME example: 248 _443._tcp.www.example.com. IN CNAME ca.example.net. 249 ca.example.net. IN TLSA 2 0 1 ... 251 Here the authentication chain structure is composed of two 252 consecutive chains, one for _443._tcp.www.example.com/CNAME 253 and one for ca.example.net/TLSA. The second chain can omit 254 the record sets at the end that overlap with the first. 256 TLS DNSSEC chain components: 258 _443._tcp.www.example.com. CNAME 259 RRSIG(_443._tcp.www.example.com. CNAME) 260 example.com. DNSKEY 261 RRSIG(example.com. DNSKEY) 262 example.com. DS 263 RRSIG(example.com. DS) 264 com. DNSKEY 265 RRSIG(com. DNSKEY) 266 com. DS 267 RRSIG(com. DS) 268 . DNSKEY 269 RRSIG(. DNSKEY) 271 ca.example.net. TLSA 272 RRSIG(ca.example.net. TLSA) 273 example.net. DNSKEY 274 RRSIG(example.net. DNSKEY) 275 example.net. DS 276 RRSIG(example.net. DS) 277 net. DNSKEY 278 RRSIG(net. DNSKEY) 279 net. DS 280 RRSIG(net. DS) 282 4. Construction of Serialized Authentication Chains 284 This section describes a possible procedure for the server to use to 285 build the serialized DNSSEC chain. 287 When the goal is to perform DANE authentication [RFC6698] of the 288 server's X.509 certificate, the DNS record set to be serialized is a 289 TLSA record set corresponding to the server's domain name. 291 The domain name of the server MUST be that included in the TLS Server 292 Name Indication extension [RFC6066] when present. If the Server Name 293 Indication extension is not present, or if the server does not 294 recognize the provided name and wishes to proceed with the handshake 295 rather than to abort the connection, the server uses the domain name 296 associated with the server IP address to which the connection has 297 been established. 299 The TLSA record to be queried is constructed by prepending the _port 300 and _transport labels to the domain name as described in [RFC6698], 301 where "port" is the port number associated with the TLS server. The 302 transport is "tcp" for TLS servers, and "udp" for DTLS servers. The 303 port number label is the left-most label, followed by the transport, 304 followed by the base domain name. 306 The components of the authentication chain are built by starting at 307 the target record set and its corresponding RRSIG. Then traversing 308 the DNS tree upwards towards the trust anchor zone (normally the DNS 309 root), for each zone cut, the DNSKEY and DS RRsets and their 310 signatures are added. If DNS responses messages contain any domain 311 names utilizing name compression [RFC1035], then they must be 312 uncompressed. 314 In the future, proposed DNS protocol enhancements, such as the EDNS 315 Chain Query extension [CHAINQUERY] may offer easy ways to obtain all 316 of the chain data in one transaction with an upstream DNSSEC aware 317 recursive server. 319 5. Caching and Regeneration of the Authentication Chain 321 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 322 have validity periods (specifically signature expiration times). 323 After the TLS server constructs the serialized authentication chain, 324 it SHOULD cache and reuse it in multiple TLS connection handshakes. 325 However, it MUST refresh and rebuild the chain as TTLs and signature 326 validity periods dictate. A server implementation could carefully 327 track these parameters and requery component records in the chain 328 correspondingly. Alternatively, it could be configured to rebuild 329 the entire chain at some predefined periodic interval that does not 330 exceed the DNS TTLs or signature validity periods of the component 331 records in the chain. 333 6. Verification 335 A TLS client making use of this specification, and which receives a 336 DNSSEC authentication chain extension from a server, SHOULD use this 337 information to perform DANE authentication of the server certificate. 338 In order to do this, it uses the mechanism specified by the DNSSEC 339 protocol [RFC4035]. This mechanism is sometimes implemented in a 340 DNSSEC validation engine or library. 342 If the authentication chain is correctly verified, the client then 343 performs DANE authentication of the server according to the DANE TLS 344 protocol [RFC6698], and the additional protocol requirements outlined 345 in [RFC7671]. 347 7. Trust Anchor Maintenance 349 The trust anchor may change periodically, e.g. when the operator of 350 the trust anchor zone performs a DNSSEC key rollover. Managed key 351 rollovers typically use a process that can be tracked by verifiers 352 allowing them to automatically update their trust anchors, as 353 described in [RFC5011]. TLS clients using this specification are 354 also expected to use such a mechanism to keep their trust anchors 355 updated. Some operating systems may have a system-wide service to 356 maintain and keep the root trust anchor up to date. In such cases, 357 the TLS client application could simply reference that as its trust 358 anchor, periodically checking whether it has changed. 360 8. Mandating use of this extension 362 A TLS server certificate MAY mandate the use of this extension by 363 means of the X.509 TLS Feature Extension described in [RFC7633]. 364 This X.509 certificate extension, when populated with the 365 dnssec_chain TLS extension identifier, indicates to the client that 366 the server must deliver the authentication chain when asked to do so. 368 (The X.509 TLS Feature Extension is the same mechanism used to 369 deliver other mandatory signals, such as OCSP "must staple" 370 assertions.) 372 9. Security Considerations 374 The security considerations of the normatively referenced RFCs (1035, 375 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this 376 extension. Since the server is delivering a chain of DNS records and 377 signatures to the client, it MUST rebuild the chain in accordance 378 with TTL and signature expiration of the chain components as 379 described in Section 5. TLS clients need roughly accurate time in 380 order to properly authenticate these signatures. This could be 381 achieved by running a time synchronization protocol like NTP 382 [RFC5905] or SNTP [RFC4330], which are already widely used today. 383 TLS clients MUST support a mechanism to track and rollover the trust 384 anchor key, or be able to avail themselves of a service that does 385 this, as described in Section 7. 387 10. IANA Considerations 389 This extension requires the registration of a new value in the TLS 390 ExtensionsType registry. The value requested from IANA is 53. If 391 the draft is adopted by the WG, the authors expect to make an early 392 allocation request as specified in [RFC7120]. 394 11. Acknowledgments 396 Many thanks to Adam Langley for laying the groundwork for this 397 extension. The original idea is his but our acknowledgment in no way 398 implies his endorsement. This document also benefited from 399 discussions with and review from the following people: Viktor 400 Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick 401 McManus, Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul 402 Wouters. 404 12. References 406 12.1. Normative References 408 [RFC1035] Mockapetris, P., "Domain names - implementation and 409 specification", STD 13, RFC 1035, November 1987. 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 415 Rose, "Resource Records for the DNS Security Extensions", 416 RFC 4034, March 2005. 418 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 419 Rose, "Protocol Modifications for the DNS Security 420 Extensions", RFC 4035, March 2005. 422 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 423 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 425 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 426 Extension Definitions", RFC 6066, January 2011. 428 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 429 of Named Entities (DANE) Transport Layer Security (TLS) 430 Protocol: TLSA", RFC 6698, August 2012. 432 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) 433 Feature Extension", RFC 7633, DOI 10.17487/RFC7633, 434 October 2015, . 436 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 437 Authentication of Named Entities (DANE) Protocol: Updates 438 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 439 October 2015, . 441 12.2. Informative References 443 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 444 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 446 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 447 Trust Anchors", STD 74, RFC 5011, September 2007. 449 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 450 Time Protocol Version 4: Protocol and Algorithms 451 Specification", RFC 5905, June 2010. 453 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 454 Points", BCP 100, RFC 7120, January 2014. 456 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 457 Most of the Time", RFC 7435, December 2014. 459 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 460 Opportunistic DNS-Based Authentication of Named Entities 461 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 462 10.17487/RFC7672, October 2015, 463 . 465 [AGL] Langley, A., "Serializing DNS Records with DNSSEC 466 Authentication", , . 469 [CHAINQUERY] 470 Wouters, P., "Chain Query Requests in DNS", , . 473 Appendix A. Pseudocode example 475 [code goes here] 477 Appendix B. Test vector 479 [data go here] 481 Authors' Addresses 483 Melinda Shore 484 No Mountain Software 486 EMail: melinda.shore@nomountain.net 488 Richard Barnes 489 Mozilla 491 EMail: rlb@ipv.sx 493 Shumon Huque 494 Verisign Labs 496 EMail: shuque@verisign.com 498 Willem Toorop 499 NLNet Labs 501 EMail: willem@nlnetlabs.nl