idnits 2.17.1 draft-ietf-tls-dnssec-chain-extension-01.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 (July 7, 2016) is 2849 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) == Outdated reference: A later version (-08) exists of draft-ietf-dnsop-edns-client-subnet-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: January 8, 2017 Mozilla 6 S. Huque 7 Verisign Labs 8 W. Toorop 9 NLNet Labs 10 July 7, 2016 12 A DANE Record and DNSSEC Authentication Chain Extension for TLS 13 draft-ietf-tls-dnssec-chain-extension-01 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 January 8, 2017. 42 Copyright Notice 44 Copyright (c) 2016 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 . . . . 7 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. Updates from -00 . . . . . . . . . . . . . . . . . . 12 76 Appendix B. Test vector . . . . . . . . . . . . . . . . . . . . 12 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 additional DNS record lookups 91 and incurring the associated latency penalty. It also provides the 92 ability to avoid potential problems with TLS clients being unable to 93 look up DANE records because of an interfering or broken middlebox on 94 the path between the client and a DNS server. And lastly, it allows 95 a TLS client to validate DANE records itself without necessarily 96 needing access to a validating DNS resolver to which it has a secure 97 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 applications. It may not be relevant for many other applications. 104 For example, SMTP MTAs are usually located in data centers, may 105 tolerate extra DNS lookup latency, are on servers where it is easier 106 to 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 [I-D.agl-dane-serializechain]. It 126 modifies the approach by using wire format DNS records in the 127 serialized data (assuming that the data will be prepared and consumed 128 by a DNS-specific library), and by using a TLS extension to deliver 129 the data. 131 3. DNSSEC Authentication Chain Extension 133 3.1. Protocol 135 A client MAY include an extension of type "dnssec_chain" in the 136 (extended) ClientHello. The "extension_data" field of this extension 137 MUST be empty. 139 Servers receiving a "dnssec_chain" extension in the client hello, and 140 which are capable of being authenticated via DANE, MAY return a 141 serialized authentication chain in the extended ServerHello message, 142 using the format described below. If a server is unable to return an 143 authentication chain, or does not wish to return an authentication 144 chain, it does not include a dnssec_chain extension. As with all TLS 145 extensions, if the server does not support this extension it will not 146 return any authentication chain. 148 A client must not be able to force a server to perform lookups on 149 arbitrary domain names using this mechanism. Therefore, a server 150 MUST NOT construct chains for domain names other than its own. 152 3.2. DNSSEC Authentication Chain Data 154 The "extension_data" field of the "dnssec_chain" extension MUST 155 contain a DNSSEC Authentication Chain encoded in the following form: 157 opaque AuthenticationChain<0..2^16-1> 159 The AuthenticationChain structure is composed of a sequence of 160 uncompressed wire format DNS resource record sets (RRset) and 161 corresponding signatures (RRsig) records. The record sets and 162 signatures are presented in validation order, starting at the target 163 DANE record, followed by the DNSKEY and DS record sets for each 164 intervening DNS zone up to a trust anchor chosen by the server, 165 typically the DNS root. 167 This sequence of native DNS wire format records enables easier 168 generation of the data structure on the server and easier 169 verification of the data on client by means of existing DNS library 170 functions. However this document describes the data structure in 171 sufficient detail that implementers if they desire can write their 172 own code to do this. 174 Each RRset in the chain is composed of a sequence of wire format DNS 175 resource records. The format of the resource record is described in 176 RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be 177 presented in the canonical form and ordering as described in RFC 4034 178 [RFC4034]. 180 RR(i) = owner | type | class | TTL | RDATA length | RDATA 182 RRs within the RRset are ordered canonically, by treating the RDATA 183 portion of each RR as a left-justified unsigned octet sequence in 184 which the absence of an octet sorts before a zero octet. 186 The RRsig record is in DNS wire format as described in RFC 4034 187 [RFC4034], Section 3.1. The signature portion of the RDATA, as 188 described in the same section, is the following: 190 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 192 where, RRSIG_RDATA is the wire format of the RRSIG RDATA fields with 193 the Signer's Name field in canonical form and the signature field 194 excluded. 196 The first RRset in the chain MUST contain the DANE records being 197 presented. The subsequent RRsets MUST be a sequence of DNSKEY and DS 198 RRsets, starting with a DNSKEY RRset. Each RRset MUST authenticate 199 the preceding RRset: 201 o A DNSKEY RRset must include the DNSKEY RR containing the public 202 key used to verify the previous RRset. 204 o For a DS RRset, the set of key hashes MUST overlap with the 205 preceding set of DNSKEY records. 207 In addition, a DNSKEY RRset followed by a DS RRset MUST be self- 208 signed, in the sense that its RRSIG MUST verify under one of the keys 209 in the DNSKEY RRSET. 211 The final DNSKEY RRset in the authentication chain, containing the 212 trust anchor may be omitted. If omitted, the client MUST verify that 213 the key tag and owner name in the final RRSIG record correspond to a 214 trust anchor. There may however be reason to include the trust 215 anchor RRset and signature if clients are expected to use RFC5011 216 compliant key rollover functions inband via the chain data. In that 217 case, they will need to periodically inspect flags (revocation and 218 secure entry point flags) on the trust anchor DNSKEY RRset. 220 For example, for an HTTPS server at www.example.com, where there are 221 zone cuts at "com." and "example.com.", the AuthenticationChain 222 structure would comprise the following RRsets and signatures (the 223 data field of the records are omitted here for brevity): 225 _443._tcp.www.example.com. TLSA 226 RRSIG(_443._tcp.www.example.com. TLSA) 227 example.com. DNSKEY 228 RRSIG(example.com. DNSKEY) 229 example.com. DS 230 RRSIG(example.com. DS) 231 com. DNSKEY 232 RRSIG(com. DNSKEY) 233 com. DS 234 RRSIG(com. DS) 235 . DNSKEY 236 RRSIG(. DNSKEY) 238 Names that are aliased via CNAME and/or DNAME records may involve 239 multiple branches of the DNS tree. In this case the authentication 240 chain structure will be composed of a sequence of these multiple 241 intersecting branches. DNAME chains should omit unsigned CNAME 242 records that may have been synthesized in the response from a DNS 243 resolver. Wildcard DANE records will need to include the wildcard 244 name, and negative proof (i.e. NSEC or NSEC3 records) that no closer 245 name exists MUST be included. 247 A CNAME example: 249 _443._tcp.www.example.com. IN CNAME ca.example.net. 250 ca.example.net. IN TLSA 2 0 1 ... 252 Here the authentication chain structure is composed of two 253 consecutive chains, one for _443._tcp.www.example.com/CNAME 254 and one for ca.example.net/TLSA. The second chain can omit 255 the record sets at the end that overlap with the first. 257 TLS DNSSEC chain components: 259 _443._tcp.www.example.com. CNAME 260 RRSIG(_443._tcp.www.example.com. CNAME) 261 example.com. DNSKEY 262 RRSIG(example.com. DNSKEY) 263 example.com. DS 264 RRSIG(example.com. DS) 265 com. DNSKEY 266 RRSIG(com. DNSKEY) 267 com. DS 268 RRSIG(com. DS) 269 . DNSKEY 270 RRSIG(. DNSKEY) 272 ca.example.net. TLSA 273 RRSIG(ca.example.net. TLSA) 274 example.net. DNSKEY 275 RRSIG(example.net. DNSKEY) 276 example.net. DS 277 RRSIG(example.net. DS) 278 net. DNSKEY 279 RRSIG(net. DNSKEY) 280 net. DS 281 RRSIG(net. DS) 283 Note as well that if a user has a specific TLSA record for port 443, 284 and a different wildcard covering other ports, attackers MUST NOT be 285 able to substitute the wildcard TLSA RRset for the more specific one 286 for port 443. DNSSEC wildcards must not be confused with the X.509 287 wildcards. 289 4. Construction of Serialized Authentication Chains 291 This section describes a possible procedure for the server to use to 292 build the serialized DNSSEC chain. 294 When the goal is to perform DANE authentication [RFC6698] of the 295 server's X.509 certificate, the DNS record set to be serialized is a 296 TLSA record set corresponding to the server's domain name. 298 The domain name of the server MUST be that included in the TLS Server 299 Name Indication extension [RFC6066] when present. If the Server Name 300 Indication extension is not present, or if the server does not 301 recognize the provided name and wishes to proceed with the handshake 302 rather than to abort the connection, the server uses the domain name 303 associated with the server IP address to which the connection has 304 been established. 306 The TLSA record to be queried is constructed by prepending the _port 307 and _transport labels to the domain name as described in [RFC6698], 308 where "port" is the port number associated with the TLS server. The 309 transport is "tcp" for TLS servers, and "udp" for DTLS servers. The 310 port number label is the left-most label, followed by the transport, 311 followed by the base domain name. 313 The components of the authentication chain are built by starting at 314 the target record set and its corresponding RRSIG. Then traversing 315 the DNS tree upwards towards the trust anchor zone (normally the DNS 316 root), for each zone cut, the DNSKEY and DS RRsets and their 317 signatures are added. If DNS responses messages contain any domain 318 names utilizing name compression [RFC1035], then they must be 319 uncompressed. 321 In the future, proposed DNS protocol enhancements, such as the EDNS 322 Chain Query extension [I-D.ietf-dnsop-edns-client-subnet] may offer 323 easy ways to obtain all of the chain data in one transaction with an 324 upstream DNSSEC aware recursive server. 326 5. Caching and Regeneration of the Authentication Chain 328 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 329 have validity periods (specifically signature expiration times). 330 After the TLS server constructs the serialized authentication chain, 331 it SHOULD cache and reuse it in multiple TLS connection handshakes. 332 However, it MUST refresh and rebuild the chain as TTLs and signature 333 validity periods dictate. A server implementation could carefully 334 track these parameters and requery component records in the chain 335 correspondingly. Alternatively, it could be configured to rebuild 336 the entire chain at some predefined periodic interval that does not 337 exceed the DNS TTLs or signature validity periods of the component 338 records in the chain. 340 6. Verification 342 A TLS client making use of this specification, and which receives a 343 DNSSEC authentication chain extension from a server, SHOULD use this 344 information to perform DANE authentication of the server certificate. 345 In order to do this, it uses the mechanism specified by the DNSSEC 346 protocol [RFC4035]. This mechanism is sometimes implemented in a 347 DNSSEC validation engine or library. 349 If the authentication chain is correctly verified, the client then 350 performs DANE authentication of the server according to the DANE TLS 351 protocol [RFC6698], and the additional protocol requirements outlined 352 in [RFC7671]. 354 7. Trust Anchor Maintenance 356 The trust anchor may change periodically, e.g. when the operator of 357 the trust anchor zone performs a DNSSEC key rollover. Managed key 358 rollovers typically use a process that can be tracked by verifiers 359 allowing them to automatically update their trust anchors, as 360 described in [RFC5011]. TLS clients using this specification are 361 also expected to use such a mechanism to keep their trust anchors 362 updated. Some operating systems may have a system-wide service to 363 maintain and keep the root trust anchor up to date. In such cases, 364 the TLS client application could simply reference that as its trust 365 anchor, periodically checking whether it has changed. 367 8. Mandating use of this extension 369 A TLS server certificate MAY mandate the use of this extension by 370 means of the X.509 TLS Feature Extension described in [RFC7633]. 371 This X.509 certificate extension, when populated with the 372 dnssec_chain TLS extension identifier, indicates to the client that 373 the server must deliver the authentication chain when asked to do so. 374 (The X.509 TLS Feature Extension is the same mechanism used to 375 deliver other mandatory signals, such as OCSP "must staple" 376 assertions.) 378 9. Security Considerations 380 The security considerations of the normatively referenced RFCs (1035, 381 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this 382 extension. Since the server is delivering a chain of DNS records and 383 signatures to the client, it MUST rebuild the chain in accordance 384 with TTL and signature expiration of the chain components as 385 described in Section 5. TLS clients need roughly accurate time in 386 order to properly authenticate these signatures. This could be 387 achieved by running a time synchronization protocol like NTP 388 [RFC5905] or SNTP [RFC5905], which are already widely used today. 389 TLS clients MUST support a mechanism to track and rollover the trust 390 anchor key, or be able to avail themselves of a service that does 391 this, as described in Section 7. 393 10. IANA Considerations 395 This extension requires the registration of a new value in the TLS 396 ExtensionsType registry. The value requested from IANA is 53. If 397 the draft is adopted by the WG, the authors expect to make an early 398 allocation request as specified in [RFC7120]. 400 11. Acknowledgments 402 Many thanks to Adam Langley for laying the groundwork for this 403 extension. The original idea is his but our acknowledgment in no way 404 implies his endorsement. This document also benefited from 405 discussions with and review from the following people: Viktor 406 Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick 407 McManus, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico 408 Williams, and Paul Wouters. 410 12. References 412 12.1. Normative References 414 [RFC1035] Mockapetris, P., "Domain names - implementation and 415 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 416 November 1987, . 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 420 RFC2119, March 1997, 421 . 423 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 424 Rose, "Resource Records for the DNS Security Extensions", 425 RFC 4034, DOI 10.17487/RFC4034, March 2005, 426 . 428 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 429 Rose, "Protocol Modifications for the DNS Security 430 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 431 . 433 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 434 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 435 RFC5246, August 2008, 436 . 438 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 439 Extensions: Extension Definitions", RFC 6066, DOI 440 10.17487/RFC6066, January 2011, 441 . 443 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 444 of Named Entities (DANE) Transport Layer Security (TLS) 445 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 446 2012, . 448 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) 449 Feature Extension", RFC 7633, DOI 10.17487/RFC7633, 450 October 2015, . 452 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 453 Authentication of Named Entities (DANE) Protocol: Updates 454 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 455 October 2015, . 457 12.2. Informative References 459 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 460 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 461 September 2007, . 463 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 464 "Network Time Protocol Version 4: Protocol and Algorithms 465 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 466 . 468 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 469 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 470 2014, . 472 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 473 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 474 December 2014, . 476 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 477 Opportunistic DNS-Based Authentication of Named Entities 478 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 479 10.17487/RFC7672, October 2015, 480 . 482 [I-D.agl-dane-serializechain] 483 Langley, A., "Serializing DNS Records with DNSSEC 484 Authentication", draft-agl-dane-serializechain-01 (work in 485 progress), July 2011. 487 [I-D.ietf-dnsop-edns-client-subnet] 488 Contavalli, C., Gaast, W., tale, t., and W. Kumari, 489 "Client Subnet in DNS Queries", draft-ietf-dnsop-edns- 490 client-subnet-07 (work in progress), March 2016. 492 Appendix A. Updates from -00 494 o Edits based on comments from Rick van Rein 496 o Warning about not overloading X.509 wildcards on DNSSEC wildcards 497 (from V. Dukhovny) 499 o Added MUST include negative proof on wildcards (from V. Dukhovny) 501 o Removed "TODO" on allowing the server to deliver only one 502 signature per RRset 504 o Added additional minor edits suggested by Viktor Dukhovny 506 Appendix B. Test vector 508 [data go here] 510 Authors' Addresses 512 Melinda Shore 513 No Mountain Software 515 EMail: melinda.shore@nomountain.net 517 Richard Barnes 518 Mozilla 520 EMail: rlb@ipv.sx 522 Shumon Huque 523 Verisign Labs 525 EMail: shuque@verisign.com 527 Willem Toorop 528 NLNet Labs 530 EMail: willem@nlnetlabs.nl