idnits 2.17.1 draft-shore-tls-dnssec-chain-extension-00.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 (June 26, 2015) is 3227 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: December 28, 2015 Mozilla 6 S. Huque 7 Verisign Labs 8 June 26, 2015 10 A DANE Record and DNSSEC Authentication Chain Extension for TLS 11 draft-shore-tls-dnssec-chain-extension-00 13 Abstract 15 This draft describes a new TLS extension for transport of a DNS 16 record serialized with the DNSSEC signatures needed to authenticate 17 that record. The intent of this proposal is to allow TLS clients to 18 perform DANE authentication of a TLS server certificate without 19 needing to perform additional DNS record lookups. It will typically 20 not be used for general DNSSEC validation of TLS endpoint names. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 28, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 3 59 3.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. DNSSEC Authentication Chain Data . . . . . . . . . . . . 4 61 4. Construction of Serialized Authentication Chains . . . . . . 5 62 5. Caching and Regeneration of the Authentication Chain . . . . 6 63 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 68 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 8 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 12.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Appendix A. Pseudocode example . . . . . . . . . . . . . . . . . 10 73 Appendix B. Test vector . . . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Requirements Notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Introduction 84 This draft describes a new TLS [RFC5246] extension for transport of a 85 DNS record serialized with the DNSSEC signatures [RFC4034] needed to 86 authenticate that record. The intent of this proposal is to allow 87 TLS clients to perform DANE authentication [RFC6698] of a TLS server 88 certificate without performing perform additional DNS record lookups 89 and incurring the associated latency penalty. It also provides the 90 ability to avoid potential problems with TLS clients being unable to 91 look up DANE records because of an interfering or broken middlebox on 92 the path between the endpoint and a DNS server. And lastly, it 93 allows a TLS client to validate DANE records itself without needing 94 access to a validating DNS resolver to which it has a secure 95 connection. It will typically not be used for general DNSSEC 96 validation of endpoint names, but is more appropriate for validation 97 of DANE records such as TLSA, SMIMEA, etc. 99 This mechanism is useful for TLS applications that need to address 100 the problems described above, typically web browsers or VoIP and XMPP 101 services. It may not be relevant for many other applications. For 102 example, SMTP MTAs are usually located in data centers, may tolerate 103 extra DNS lookup latency, are on servers where it is easier to 104 provision a validating resolver, and are less likely to experience 105 traffic interference from misconfigured middleboxes. Hence DANE 106 authentication of SMTP MTAs [DANESMTP] is not likely to gain much 107 advantage from this mechanism. 109 The extension described here allows a TLS client to request in the 110 client hello message that the DNS validation chain be returned in the 111 (extended) server hello message. If the server is configured for 112 DANE authentication, then it performs the appropriate DNS queries, 113 builds the validation chain, and returns it to the client. The 114 server will usually use a previously cached authentication chain, but 115 it will need to rebuild it periodically as described in Section 5. 116 The client then authenticates the chain using a pre-configured trust 117 anchor. 119 This specification is based on Adam Langley's original proposal for 120 serializing DNSSEC authentication chains [AGL] and it incorporates 121 his ideas and some of his text. It modifies his approach by using 122 DNS wire formats and assumes that in implementation, the serialized 123 DNSSEC object will be prepared by a DNS-specific module and the 124 validation actions on serialized DNSSEC will also be carried out by a 125 DNS-specific module. An appendix (empty in the 00 version) provides 126 a Python code example of interfacing with a DNS-specific module. 128 3. DNSSEC Authentication Chain Extension 130 3.1. Protocol 132 A client MAY include an extension of type "dnssec_chain" in the 133 (extended) ClientHello. The "extension_data" field of this extension 134 MUST be empty. 136 Servers receiving a "dnssec_chain" extension in the client hello 137 SHOULD return a serialized authentication chain in the extended 138 ServerHello message, using the format described below. If a server 139 is unable to return a authentication chain, or does not wish to 140 return a authentication chain, it does not include a dnssec_chain 141 extension. As with all TLS extensions, if the server does not 142 support this extension it will not return any authentication chain. 144 3.2. DNSSEC Authentication Chain Data 146 The "extension_data" field of the "dnssec_chain" extension represents 147 a sequence of DNS resource record sets, which provide a chain from 148 the DANE record being provided to a trust anchor chosen by the 149 server. The "extension_data" field MUST contain a DNSSEC 150 Authentication Chain encoded in the following form: 152 struct { 153 opaque rrset<0..2^16-1>; 154 opaque rrsig<0..2^16-1>; 155 } RRset 157 RRset AuthenticationChain<0..2^16-1>; 159 Each RRset in the authentication chain encodes an RRset along with a 160 signature on that RRset. The "rrsig" field contains the RDATA for 161 the RRSIG record, defined in Section 3.1 of RFC 4034 [RFC4034]. The 162 "rrset" field contains the covered resource records, in the format 163 defined in Section 3.1.8.1 of RFC 4034 [RFC4034]: 165 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 167 RR(i) = owner | type | class | TTL | RDATA length | RDATA 169 The first RRset in the chain MUST contain the DANE records being 170 presented. The subsequent RRsets MUST be an sequence of DNSKEY and 171 DS RRsets, starting with a DNSKEY RRset. Each RRset MUST 172 authenticate the preceding RRset: 174 For a DNSKEY RRset, one of the covered DNSKEY RRs MUST be the 175 public key used to verify the previous RRset. 177 For a DS RRset, the set of key hashes MUST overlap with the 178 preceding set of DNSKEY records. 180 In addition, a DNSKEY RRset followed by a DS RRset MUST be self- 181 signed, in the sense that its RRSIG MUST verify under one of the keys 182 in the DNSKEY RRSET. 184 The final RRset in the authentication chain, representing the trust 185 anchor, SHOULD be omitted. In this case, the client MUST verify that 186 the key tag and owner name in the final RRSIG record correspond to a 187 trust anchor. 189 For example, for an HTTPS server at www.example.com, where there are 190 zone cuts at "com." and "example.com.", we might get the following 191 RRsets: 193 . DNSKEY 194 com. DS 195 com. DNSKEY 196 example.com. DS 197 example.com. DNSKEY 198 _443._tcp.www.example.com. TLSA 200 Obviously, an authentication chain will be most compact and easiest 201 to verify if each RRset has a single record, i.e., if there is a 202 single DNSKEY RR and a single DS RR at each step. In addition, as 203 suggested above, keeping zone cuts to a minimum also reduces the 204 length of the authentication chain. 206 4. Construction of Serialized Authentication Chains 208 This section describes a possible procedure for the server to use to 209 build the serialized DNSSEC chain. 211 When the goal is to perform DANE authentication [RFC6698] of the 212 server's X.509 certificate, the DNS record to be serialized is a TLSA 213 record corresponding to the server's domain name. 215 The domain name of the server MUST be that included in the TLS Server 216 Name Indication extension [RFC6066] when present. If the Server Name 217 Indication extension is not present, or if the server does not 218 recognize the provided name and wishes to proceed with the handshake 219 rather than aborting the connection, the server uses the domain name 220 associated with the server IP address that the TLS connection arrives 221 on. 223 The TLSA record to be queried is constructed by prepending the _port 224 and _transport labels to the domain name as described in [RFC6698], 225 where port is the port number associated with the TLS server. The 226 transport is "tcp" for TLS servers, and "udp" for DTLS servers. 228 The components of the authentication chain are built by starting at 229 the trust anchor DNSKEY (usually expected to be the DNS root trust 230 anchor) and its corresponding RRSIG signature record, and then for 231 each intervening zone cut, adding the DS record and DNSKEY RRsets and 232 their RRSIGs, and finally the target TLSA record and RRSIG. (As 233 required above, however, the serialized authentication chain will 234 present the RRsets in the opposite order.) 235 If the server acts as its own full iterative DNS resolver, it can 236 just build the chain as it performs normal iterative resolution of 237 the target record. If the server uses a recursive resolver, it 238 employs a slightly modified lookup algorithm, starting at the trust 239 anchor, prepending additional labels, and looking for NS, DS, and 240 DNSKEY records, until it reaches the target name. 242 In order to meet the formatting requirements above, the server must 243 perform some pre-processing on the resource records it receives. It 244 must first compute the uncompressed representation of the RRs, 245 removing DNS name compression [RFC1035] if present. It then extracts 246 the relevant fields from the resource records and assembles them into 247 an RRset. 249 5. Caching and Regeneration of the Authentication Chain 251 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 252 have validity periods (specifically signature expiration times). 253 After the TLS server constructs the serialized authentication chain, 254 it can cache and reuse it in multiple TLS connection handshakes. 255 However, it should keep track of the TTLs and signature validity 256 periods and requery the records and rebuild the authentication chain 257 as needed. A server implementation could carefully track these 258 parameters and requery the chain correspondingly. Alternatively, it 259 could be configured to rebuild the chain at some predefined periodic 260 intervals. 262 6. Verification 264 A TLS client making use of this specification, and which receives a 265 DNSSEC authentication chain extension from a server, SHOULD use this 266 information to perform DANE authentication of the server certificate. 267 In order to do this, it uses the mechanism specified by the DNSSEC 268 protocol [RFC4035]. This mechanism is sometimes implemented in a 269 DNSSEC validation engine or library. 271 If the record is correctly authenticated, the client then performs 272 DANE authentication according to the DANE TLS protocol [RFC6698]. 274 7. Trust Anchor Maintenance 276 The trust anchor may change periodically, e.g. due to a key rollover 277 event by the operator of the initial zone. Managed key rollovers 278 typically use a process that can be tracked by verifiers allowing 279 them to automatically update their trust anchors, as described in 280 [RFC5011]. TLS clients using this specification are also expected to 281 use such a mechanism to keep their trust anchors updated. Some 282 operating systems may have a system-wide service to maintain and keep 283 up-to-date the root trust anchor. It may be possible for the TLS 284 client application to simply reference that as its trust anchor, 285 periodically checking whether it has changed. 287 8. Security Considerations 289 The security considerations of the normatively referenced RFCs (1035, 290 4034, 4035, 5246, 6066, 6698) all pertain to this extension. As 291 mentioned above, there are particular security pitfalls in creating 292 and using this serialization because it has very different temporal 293 qualities from the usual certificate that would be validated. So the 294 requirements in Section 6 (Section 5) for not caching and for 295 maintaining very good clock synchronization on the client are quite 296 important for avoiding risks of replay or of use of revoked 297 certificates. Other residual risks of this specification include 298 locating the validation function in the server rather than in the 299 client. This might seem reasonable on the face of it, but because 300 the DNSSEC serialization is sent in the clear in the client hello, it 301 could be tampered with and the certificate fingerprint or full 302 certificate (depending on the mode) should not be used without 303 performing the DNSSEC validation (in the DNS-specific module. 305 DNSSEC signatures have validity periods defined by an inception and 306 expiration time. TLS clients need roughly accurate time in order to 307 properly authenticate these signatures. This could be achieved by 308 running a time synchronization protocol like NTP [RFC5905] or SNTP 309 [RFC4330], which are already widely used today. 311 9. IANA Considerations 313 This extension requires the registration of a new value in the TLS 314 ExtensionsType registry. The value requested from IANA is 53. If 315 the draft is adopted by the WG, the authors expect to make an early 316 allocation request as specified in [RFC7120]. 318 10. Acknowledgments 320 Many thanks to Adam Langley for laying the groundwork for this 321 extension. The original idea is his but our acknowledgment in no way 322 implies his endorsement. This document also benefited from 323 discussions with and review from the following people: Allison 324 Mankin, Duane Wessels, Willem Toorop, Jeff Hodges, and Gowri 325 Visweswaran. 327 11. Test Vectors 329 [TO BE ADDED LATER. THE ORIGINAL CONTENT WAS OBSOLETE.] 331 12. References 333 12.1. Normative References 335 [RFC1035] Mockapetris, P., "Domain names - implementation and 336 specification", STD 13, RFC 1035, November 1987. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 342 Rose, "Resource Records for the DNS Security Extensions", 343 RFC 4034, March 2005. 345 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 346 Rose, "Protocol Modifications for the DNS Security 347 Extensions", RFC 4035, March 2005. 349 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 350 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 352 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 353 Extension Definitions", RFC 6066, January 2011. 355 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 356 of Named Entities (DANE) Transport Layer Security (TLS) 357 Protocol: TLSA", RFC 6698, August 2012. 359 12.2. Informative References 361 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 362 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 364 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 365 Trust Anchors", STD 74, RFC 5011, September 2007. 367 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 368 Time Protocol Version 4: Protocol and Algorithms 369 Specification", RFC 5905, June 2010. 371 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 372 Points", BCP 100, RFC 7120, January 2014. 374 [AGL] Langley, A., "Serializing DNS Records with DNSSEC 375 Authentication", . 378 [DANESMTP] 379 Dukhovni, V. and W. Hardaker, "SMTP Security via 380 opportunistic DANE TLS", . 383 Appendix A. Pseudocode example 385 [code goes here] 387 Appendix B. Test vector 389 [data go here] 391 Authors' Addresses 393 Melinda Shore 394 No Mountain Software 396 EMail: melinda.shore@nomountain.net 398 Richard Barnes 399 Mozilla 401 EMail: rlb@ipv.sx 403 Shumon Huque 404 Verisign Labs 406 EMail: shuque@verisign.com