idnits 2.17.1 draft-ietf-dane-protocol-10.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 15, 2011) is 4630 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) == Missing Reference: 'This' is mentioned on line 523, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-dane-use-cases (ref. 'DANEUSECASES') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Standards Track J. Schlyter 5 Expires: February 16, 2012 Kirei AB 6 August 15, 2011 8 Using Secure DNS to Associate Certificates with Domain Names For TLS 9 draft-ietf-dane-protocol-10 11 Abstract 13 TLS and DTLS use PKIX certificates for authenticating the server. 14 Users want their applications to verify that the certificate provided 15 by the TLS server is in fact associated with the domain name they 16 expect. TLSA provides bindings of keys to domains that are asserted 17 not by external entities, but by the entities that operate the DNS. 18 This document describes how to use secure DNS to associate the TLS 19 server's certificate with the intended domain name. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 16, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Certificate Associations . . . . . . . . . . . . . . . . . 3 57 1.2. Securing Certificate Associations . . . . . . . . . . . . 4 58 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 4 60 2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 61 2.1.1. The Certificate Type Field . . . . . . . . . . . . . . 5 62 2.1.2. The Reference Type Field . . . . . . . . . . . . . . . 6 63 2.1.3. The Certificate for Association Field . . . . . . . . 6 64 2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 6 65 2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 6 66 3. Domain Names for TLS Certificate Associations . . . . . . . . 7 67 4. Semantics and Features of TLSA Certificate Types . . . . . . . 7 68 4.1. End Entity Certificate . . . . . . . . . . . . . . . . . . 7 69 4.2. Certification Authority Certificate . . . . . . . . . . . 8 70 4.3. Certificate Public Key . . . . . . . . . . . . . . . . . . 8 71 4.4. Use of TLS Certificate Associations in TLS . . . . . . . . 8 72 5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 9 73 6. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.2. TLSA Certificate Types . . . . . . . . . . . . . . . . . . 11 77 7.3. TLSA Hash Types . . . . . . . . . . . . . . . . . . . . . 11 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 83 Appendix A. Operational Considerations for Deploying TLSA 84 Records . . . . . . . . . . . . . . . . . . . . . . . 14 85 A.1. Provisioning TLSA Records with Aliases . . . . . . . . . . 14 86 A.1.1. Provisioning TLSA Records with CNAME Records . . . . . 14 87 A.1.2. Provisioning TLSA Records with DNAME Records . . . . . 16 88 A.1.3. Provisioning TLSA Records with Wildcards . . . . . . . 16 89 A.2. Securing the Last Hop . . . . . . . . . . . . . . . . . . 16 90 Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 The first response from the server in TLS may contain a certificate. 96 In order for the TLS client to authenticate that it is talking to the 97 expected TLS server, the client must validate that this certificate 98 is associated with the domain name used by the client to get to the 99 server. Currently, the client must extract the domain name from the 100 certificate, must trust a trust anchor upon which the server's 101 certificate is rooted, and must successfully validate the 102 certificate. 104 Some people want a different way to authenticate the association of 105 the server's certificate with the intended domain name without 106 trusting an external certificate authority (CA). Given that the DNS 107 administrator for a domain name is authorized to give identifying 108 information about the zone, it makes sense to allow that 109 administrator to also make an authoritative binding between the 110 domain name and a certificate that might be used by a host at that 111 domain name. The easiest way to do this is to use the DNS. 113 There are many use cases for such functionality. [DANEUSECASES] 114 lists the ones that the protocol in this document is meant to apply 115 to. [DANEUSECASES] also lists many requirements, most of which the 116 protocol in this document is believed to meet. Section 5 covers the 117 applicability of this document to the use cases in detail. 119 This document applies to both TLS [RFC5246] and DTLS [RFC4347bis]. 120 In order to make the document more readable, it mostly only talks 121 about "TLS", but in all cases, it means "TLS or DTLS". This document 122 only relates to securely associating certificates for TLS and DTLS 123 with host names; other security protocols and other forms of 124 identification of TLS servers (such as IP addresses) are handled in 125 other documents. For example, keys for IPsec are covered in 126 [RFC4025] and keys for SSH are covered in [RFC4255]. 128 1.1. Certificate Associations 130 In this document, a certificate association is based on a 131 cryptographic hash of a certificate (sometimes called a 132 "fingerprint"), a public key, or on the certificate itself. For a 133 fingerprint, a hash is taken of the binary, DER-encoded certificate 134 or public key, and that hash is the certificate association; the type 135 of hash function used can be chosen by the DNS administrator. When 136 using the certificate itself in the certificate association, the 137 entire certificate in the normal format is used. This document only 138 applies to PKIX [RFC5280] certificates, not certificates of other 139 formats. It also applies to public keys that are extracted from PKIX 140 certificates, not just full certificates. 142 Certificate associations are made between a certificate or public key 143 and a domain name. Server software that is running TLS that is found 144 at that domain name would use a certificate that has a certificate 145 association given in the DNS, as described in this document. A DNS 146 query can return multiple certificate associations, such as in the 147 case of different server software on a single host using different 148 certificates, or in the case that a server is changing from one 149 certificate to another. 151 1.2. Securing Certificate Associations 153 This document defines a secure method to associate the certificate 154 that is obtained from the TLS server with a domain name using DNS; 155 the DNS information may need to be be protected by DNSSEC. Because 156 the certificate association was retrieved based on a DNS query, the 157 domain name in the query is by definition associated with the 158 certificate. 160 DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], 161 [RFC4034], and [RFC4035]), uses cryptographic keys and digital 162 signatures to provide authentication of DNS data. Information 163 retrieved from the DNS and that is validated using DNSSEC is thereby 164 proved to be the authoritative data. The DNSSEC signature MUST be 165 validated on all responses that use DNSSEC in order to assure the 166 proof of origin of the data. This document does not specify how 167 DNSSEC validation occurs because there are many different proposals 168 for how a client might get validated DNSSEC results. 170 This document only relates to securely getting the DNS information 171 for the certificate association using DNSSEC; other secure DNS 172 mechanisms are out of scope. 174 1.3. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 This document also makes use of standard PKIX, DNSSEC, and TLS 181 terminology. See [RFC5280], [RFC4033], and [RFC5246] respectively, 182 for these terms. In addition, terms related to TLS-protected 183 application services and DNS names are taken from [RFC6125]. 185 2. The TLSA Resource Record 187 The TLSA DNS resource record (RR) is used to associate a certificate 188 with the domain name where the record is found. The semantics of how 189 the TLSA RR is interpreted are given later in this document. 191 The type value for the TLSA RR type is TBD. 193 The TLSA RR is class independent. 195 The TLSA RR has no special TTL requirements. 197 2.1. TLSA RDATA Wire Format 199 The RDATA for a TLSA RR consists of a one octet certificate type 200 field, a one octet reference type field and the certificate for 201 association field. 203 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Cert type | Ref type | / 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 208 / / 209 / Certificate for association / 210 / / 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 2.1.1. The Certificate Type Field 215 A one-octet value, called "certificate type", specifying the provided 216 association that will be used to match the target certificate. This 217 will be an IANA registry in order to make it easier to add additional 218 certificate types in the future. The types defined in this document 219 are: 221 1 -- A PKIX certificate that identifies an end entity 223 2 -- A PKIX certification authority's certificate 225 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo 226 structure 228 All three types are structured using the RFC 5280 formatting rules 229 and use the DER encoding. 231 The three certificate types defined in this document explicitly only 232 apply to PKIX-formatted certificates. If TLS allows other formats 233 later, or if extensions to this protocol are made that accept other 234 formats for certificates, those certificates will need their own 235 certificate types. 237 2.1.2. The Reference Type Field 239 A one-octet value, called "reference type", specifying how the 240 certificate association is presented. This value is defined in a new 241 IANA registry. The types defined in this document are: 243 0 -- Full certificate 245 1 -- SHA-256 hash of the certificate 247 2 -- SHA-512 hash of the certificate 249 Using the same hash algorithm as is used in the signature in the 250 certificate will make it more likely that the TLS client will 251 understand this TLSA data. 253 2.1.3. The Certificate for Association Field 255 The "certificate for association". This is the bytes containing the 256 full certificate, SubjectPublicKeyInfo or the hash of the associated 257 certificate or SubjectPublicKeyInfo. For certificate types 1 and 2, 258 this is the certificate or the hash of the certificate itself, not of 259 the TLS ASN.1 Cert object. 261 2.2. TLSA RR Presentation Format 263 The presentation format of the RDATA portion is as follows: 265 o The certificate type field MUST be represented as an unsigned 266 decimal integer. 268 o The reference type field MUST be represented as an unsigned 269 decimal integer. 271 o The certificate for association field MUST be represented as a 272 string of hexadecimal characters. Whitespace is allowed within 273 the string of hexadecimal characters. 275 2.3. TLSA RR Examples 277 An example of a SHA-256 hash (type 1) of an end entity certificate 278 (type 1) would be: 280 _443._tcp.www.example.com. IN TLSA ( 281 1 1 5c1502a6549c423be0a0aa9d9a16904de5ef0f5c98 282 c735fcca79f09230aa7141 ) 284 An example of an unhashed CA certificate (type 2) would be: 286 _443._tcp.www.example.com. IN TLSA ( 287 2 0 308202c5308201ada00302010202090... ) 289 3. Domain Names for TLS Certificate Associations 291 TLSA resource records are stored at a prefixed DNS domain name. The 292 prefix is prepared in the following manner: 294 1. The decimal representation of the port number on which a TLS- 295 based service is assumed to exist is prepended with an underscore 296 character ("_") to become the left-most label in the prepared 297 domain name. This number has no leading zeros. 299 2. The protocol name of the transport on which a TLS-based service 300 is assumed to exist is prepended with an underscore character 301 ("_") to become the second left-most label in the prepared domain 302 name. The transport names defined for this protocol are "tcp", 303 "udp" and "sctp". 305 3. The domain name is appended to the result of step 2 to complete 306 the prepared domain name. 308 For example, to request a TLSA resource record for an HTTP server 309 running TLS on port 443 at "www.example.com", you would use 310 "_443._tcp.www.example.com" in the request. To request a TLSA 311 resource record for an SMTP server running the STARTTLS protocol on 312 port 25 at "mail.example.com", you would use 313 "_25._tcp.mail.example.com". 315 4. Semantics and Features of TLSA Certificate Types 317 The three certificate types have very different semantics, but also 318 have features common to all three types. 320 4.1. End Entity Certificate 322 Certificate type 1 (a certificate that identifies an end entity) is 323 matched against the first certificate offered by the TLS server. The 324 certificate for association is used only for exact matching, not for 325 chained validation. With reference type 0, the certificate 326 association is valid if the certificate in the TLSA data matches to 327 the first certificate offered by TLS. With reference types other 328 than 0, the certificate association is valid if the hash of the first 329 certificate offered by the TLS server matches the value from the TLSA 330 data. 332 4.2. Certification Authority Certificate 334 Certificate type 2 (certification authority's certificate) can be 335 used in one of two ways. With reference type 0, the certificate in 336 the TLSA resource record is used in chaining from the end entity 337 given in TLS. The certificate association is valid if the first 338 certificate in the certificate bundle can be validly chained to the 339 trust anchor from the TLSA data. With reference types other than 0, 340 if the hash of any certificate past the first in the certificate 341 bundle from TLS matches the trust anchor from the TLSA data, and the 342 chain in the certificate bundle is valid up to that TLSA trust 343 anchor, then the certificate association is valid. Alternately, if 344 the first certificate offered chains to an existing trust anchor in 345 the TLS client's trust anchor repository, and the hash of that trust 346 anchor matches the value from the TLSA data, then the certificate 347 association is valid. 349 4.3. Certificate Public Key 351 Certificate type 3 (public key expressed as a PKIX 352 SubjectPublicKeyInfo structure) is used to assert that the public key 353 will appear in one of the certificates received from the server. A 354 server might choose this type for many reasons, including (but not 355 limited to): 357 o the trust anchor to which TLS server's certificate chains might 358 change without the trust anchor's public key changing 360 o the TLS server is using a self-signed certificate that is not 361 marked as a CA certificate 363 A TLS client conforming to this protocol that receives a public key 364 in a type 3 certificate for association must be able to extract the 365 SubjectPublicKeyInfo from each of the certificates presented to it by 366 the TLS server. It then does a bit-for-bit comparison between the 367 certificate for association and the SubjectPublicKeyInfos in the 368 certificates; if it does not find a match, the client aborts the TLS 369 handshake. 371 4.4. Use of TLS Certificate Associations in TLS 373 A TLS client conforming to this protocol receiving a certificate for 374 association of type 1 MUST compare it for equality, using the 375 specified reference type, with the end entity certificate received in 376 TLS. A TLS client conforming to this protocol receiving a 377 certificate for association of type 2 MUST treat it as a trust anchor 378 for that domain name. A TLS client conforming to this protocol 379 receiving a certificate for association of type 3 MUST find a 380 matching SubjectPublicKeyInfo structure in one of the certificates 381 offered by the TLS server. 383 The end entity certificate from TLS, regardless of whether it was 384 matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA 385 certificate, might have at least one identifier in the subject or 386 subjectAltName field of the matched certificates that matches the 387 expected identifier for the TLS server. Some specifications for 388 applications that run under TLS, such as [RFC2818] for HTTP, require 389 the server's certificate to have a domain name that matches the host 390 name expected by the client. Further, the TLS session that is to be 391 set up MUST be for the specific port number and transport name that 392 was given in the TLSA query. The matching or chaining MUST be done 393 within the life of the TTL on the TLSA record. 395 In order to use one or more TLS certificate associations described in 396 this document obtained from the DNS, an application MUST assure that 397 the certificates were obtained using DNS protected by DNSSEC. TLSA 398 records must only be trusted if they were obtained from a trusted 399 source. This could be a localhost DNS resolver answer with the AD 400 bit set, an inline validating resolver library primed with the proper 401 trust anchors, or obtained from a remote nameserver to which one has 402 a secured channel of communication. 404 If a certificate association contains a reference type that is not 405 understood by the TLS client, that certificate association MUST be 406 marked as unusable. 408 An application that requests TLS certificate associations using the 409 method described in this document obtains zero or more usable 410 certificate associations. If the application receives zero usable 411 certificate associations, it processes TLS in the normal fashion. 413 If a match between one of the certificate association(s) and the 414 server's end entity certificate in TLS is found, the TLS client 415 continues the TLS handshake. If no match between the usable 416 certificate association(s) and the server's end entity certificate in 417 TLS is found, the TLS client MUST abort the handshake with an 418 "access_denied" error. 420 5. TLSA and DANE Use Cases and Requirements 422 The different types of certificates for association defined in TLSA 423 are matched with various sections of [DANEUSECASES]. The three use 424 cases from section 3 of [DANEUSECASES] are covered in this protocol 425 as follows: 427 3.1 CA Constraints -- Implemented using certificate type 2. A 428 hashed association is recommended for well-known certification 429 authorities. 431 3.2 Certificate Constraints -- Implemented using certificate type 1. 433 3.3 Domain-Issued Certificates -- Implemented using certificate type 434 1 combined with any reference type, or by using certificate type 2 435 together with a full certificate association. 437 The requirements from section 4 of [DANEUSECASES] are covered in this 438 protocol as follows (note that some of these might be excessively 439 glib): 441 Multiple Ports -- Covered in the TLSA request syntax. 443 No Downgrade -- Covered by DNSSEC itself. 445 Encapsulation -- Covered in the TLSA response semantics. 447 Predictability -- Covered by this spec. 449 Opportunistic Security -- Covered in the TLSA request syntax. 451 Combination -- Covered in the TLSA response semantics. 453 Roll-over -- Covered by the TTLs on the TLSA records. 455 Simple Key Management -- Implemented using Certificate Type 3. 457 Minimal Dependencies -- Covered in the TLSA response semantics. 459 Minimal Options -- Covered in the TLSA response semantics. 461 Wild Cards -- Covered in the TLSA request syntax; see Appendix A. 463 Redirection -- Covered in the TLSA request syntax; see Appendix A. 465 6. Mandatory-to-Implement Algorithms 467 DNS systems conforming to this specification MUST be able to create 468 TLSA records containing certificate types 1 and 2. DNS systems 469 conforming to this specification MUST be able to create TLSA records 470 using reference type 0 (no hash used) and reference type 1 (SHA-256), 471 and SHOULD be able to create TLSA records using reference type 2 472 (SHA-512). 474 TLS clients conforming to this specification MUST be able to 475 correctly interpret TLSA records containing certificate types 1, 2 476 and 3. TLS clients conforming to this specification MUST be able to 477 compare a certificate for association with a certificate from TLS 478 using reference type 0 (no hash used) and reference type 1 (SHA-256), 479 and SHOULD be able to make such comparisons with reference type 2 480 (SHA-512). 482 At the time this is written, it is expected that there will be a new 483 family of hash algorithms called SHA-3 within the next few years. It 484 is expected that some of the SHA-3 algorithms will be mandatory 485 and/or recommended for TLSA records after the algorithms are fully 486 defined. At that time, this specification will be updated. 488 7. IANA Considerations 490 7.1. TLSA RRtype 492 This document uses a new DNS RR type, TLSA, whose value is TBD. A 493 separate request for the RR type will be submitted to the expert 494 reviewer, and future versions of this document will have that value 495 instead of TBD. 497 7.2. TLSA Certificate Types 499 This document creates a new registry, "Certificate Types for TLSA 500 Resource Records". The registry policy is "RFC Required". The 501 initial entries in the registry are: 503 Value Short description Reference 504 ---------------------------------------------------------- 505 0 Reserved [This] 506 1 Certificate to identify an end entity [This] 507 2 CA's certificate [This] 508 3 Public key as SubjectPublicKeyInfo [This] 509 4-254 Unassigned 510 255 Private use 512 Applications to the registry can request specific values that have 513 yet to be assigned. 515 7.3. TLSA Hash Types 517 This document creates a new registry, "Hash Types for TLSA Resource 518 Records". The registry policy is "Specification Required". The 519 initial entries in the registry are: 521 Value Short description Reference 522 --------------------------------------------- 523 0 No hash used [This] 524 1 SHA-256 NIST FIPS 180-3 525 2 SHA-512 NIST FIPS 180-3 526 3-254 Unassigned 527 255 Private use 529 Applications to the registry can request specific values that have 530 yet to be assigned. 532 8. Security Considerations 534 The security of the protocols described in this document relies on 535 the security of DNSSEC as used by the client requesting A/AAAA and 536 TLSA records. 538 A DNS administrator who goes rogue and changes both the A/AAAA and 539 TLSA records for a domain name can cause the user to go to an 540 unauthorized server that will appear authorized, unless the client 541 performs certificate validation and rejects the certificate. That 542 administrator could probably get a certificate issued anyway, so this 543 is not an additional threat. 545 If the authentication mechanism for adding or changing TLSA data in a 546 zone is weaker than the authentication mechanism for changing the 547 A/AAAA records, a man-in-the-middle who can redirect traffic to their 548 site may be able to impersonate the attacked host in TLS if they can 549 use the weaker authentication mechanism. A better design for 550 authenticating DNS would be to have the same level of authentication 551 used for all DNS additions and changes for a particular host. 553 SSL proxies can sometimes act as a man-in-the-middle for TLS clients. 554 In these scenarios, the clients add a new trust anchor whose private 555 key is kept on the SSL proxy; the proxy intercepts TLS requests, 556 creates a new TLS session with the intended host, and sets up a TLS 557 session with the client using a certificate that chains to the trust 558 anchor installed in the client by the proxy. In such environments, 559 the TLSA protocol will prevent the SSL proxy from functioning as 560 expected because the TLS client will get a certificate association 561 from the DNS that will not match the certificate that the SSL proxy 562 uses with the client. The client, seeing the proxy's new certificate 563 for the supposed destination will not set up a TLS session. Thus, 564 such proxies might choose to aggressively block TLSA requests and/or 565 responses. 567 Client treatment of any information included in the trust anchor is a 568 matter of local policy. This specification does not mandate that 569 such information be inspected or validated by the domain name 570 administrator. 572 9. Acknowledgements 574 Many of the ideas in this document have been discussed over many 575 years. More recently, the ideas have been discussed by the authors 576 and others in a more focused fashion. In particular, some of the 577 ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, 578 Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben 579 Laurie, Ilari Liusvaara, Scott Schmit, and Ondrej Sury. 581 This document has also been greatly helped by many active 582 participants of the DANE Working Group. 584 10. References 586 10.1. Normative References 588 [DANEUSECASES] 589 Barnes, R., "Use Cases and Requirements for DNS-based 590 Authentication of Named Entities (DANE)", 591 draft-ietf-dane-use-cases (work in progress), 2011. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 597 Rose, "DNS Security Introduction and Requirements", 598 RFC 4033, March 2005. 600 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 601 Rose, "Resource Records for the DNS Security Extensions", 602 RFC 4034, March 2005. 604 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 605 Rose, "Protocol Modifications for the DNS Security 606 Extensions", RFC 4035, March 2005. 608 [RFC4347bis] 609 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 610 Security version 1.2", draft-ietf-tls-rfc4347-bis (work in 611 progress), July 2010. 613 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 614 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 616 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 617 Housley, R., and W. Polk, "Internet X.509 Public Key 618 Infrastructure Certificate and Certificate Revocation List 619 (CRL) Profile", RFC 5280, May 2008. 621 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 622 Verification of Domain-Based Application Service Identity 623 within Internet Public Key Infrastructure Using X.509 624 (PKIX) Certificates in the Context of Transport Layer 625 Security (TLS)", RFC 6125, March 2011. 627 10.2. Informative References 629 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 630 specifying the location of services (DNS SRV)", RFC 2782, 631 February 2000. 633 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 635 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 636 Material in DNS", RFC 4025, March 2005. 638 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 639 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 640 January 2006. 642 Appendix A. Operational Considerations for Deploying TLSA Records 644 A.1. Provisioning TLSA Records with Aliases 646 The TLSA resource record is not special in the DNS; it acts exactly 647 like any other RRtype where the queried name has one or more labels 648 prefixed to the base name, such as the SRV RRtype [RFC2782]. This 649 affects the way that the TLSA resource record is used when aliasing 650 in the DNS. 652 Note that the IETF sometimes adds new types of aliasing in the DNS. 653 If that happens in the future, those aliases might affect TLSA 654 records, hopefully in a good way. 656 A.1.1. Provisioning TLSA Records with CNAME Records 658 Using CNAME to alias in DNS only aliases from the exact name given, 659 not any zones below the given name. For example, assume that a zone 660 file has only the following: 662 sub1.example.com. IN CNAME sub2.example.com. 664 In this case, a request for the A record at "bottom.sub1.example.com" 665 would not return any records because the CNAME given only aliases the 666 name given. Assume, instead, the zone file has the following: 668 sub3.example.com. IN CNAME sub4.example.com. 669 bottom.sub3.example.com. IN CNAME bottom.sub4.example.com. 671 In this case, a request for the A record at bottom.sub3.example.com 672 would in fact return whatever value for the A record exists at 673 bottom.sub4.example.com. 675 Application implementations and full-service resolvers request DNS 676 records using libraries that automatically follow CNAME (and DNAME) 677 aliasing. This allows hosts to put TLSA records in their own zones 678 or to use CNAME to do redirection. 680 If the owner of the original domain wants a TLSA record for the same, 681 they simply enter it under the defined prefix: 683 ; No TLSA record in target domain 684 ; 685 sub5.example.com. IN CNAME sub6.example.com. 686 _443._tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... 687 sub6.example.com. IN A 10.0.0.0 689 If the owner of the orginal domain wants to have the target domain 690 host the TLSA record, the original domain uses a CNAME record: 692 ; TLSA record for original domain has CNAME to target domain 693 ; 694 sub5.example.com. IN CNAME sub6.example.com. 695 _443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com. 696 sub6.example.com. IN A 10.0.0.0 697 _443._tcp.sub6.example.com. IN TLSA 1 1 536a570ac49d9ba4... 699 Note that it is acceptable for both the original domain and the 700 target domain to have TLSA records, but the two records are 701 unrelated. Consider the following: 703 ; TLSA record in both the original and target domain 704 ; 705 sub5.example.com. IN CNAME sub6.example.com. 706 _443._tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... 707 sub6.example.com. IN A 10.0.0.0 708 _443._tcp.sub6.example.com. IN TLSA 2 0 ac49d9ba4570ac49... 710 In this example, someone looking for the TLSA record for 711 sub5.example.com would always get the record whose value starts 712 "308202c5308201ab"; the TLSA record whose value starts 713 "ac49d9ba4570ac49" would only be sought by someone who is looking for 714 the TLSA record for sub6.example.com, and never for sub5.example.com. 716 Note that these methods use the normal method for DNS aliasing using 717 CNAME: the DNS client requests the record type that they actually 718 want. 720 A.1.2. Provisioning TLSA Records with DNAME Records 722 Using DNAME records allows a zone owner to alias an entire subtree of 723 names below the name that has the DNAME. This allows the wholesale 724 aliasing of prefixed records such as those used by TLSA, SRV, and so 725 on without aliasing the name itself. However, because DNAME can only 726 be used for subtrees of a base name, it is rarely used to alias 727 individual hosts that might also be running TLS. 729 A.1.3. Provisioning TLSA Records with Wildcards 731 Wildcards are generally not terribly useful for RRtypes that require 732 prefixing because you can only wildcard at a layer below the host 733 name. For example, if you want to have the same TLSA record for 734 every TCP port for www.example.com, you might have 736 *._tcp.www.example.com. IN TLSA 1 1 5c1502a6549c423b... 738 This is possibly useful in some scenarios where the same service is 739 offered on many ports. 741 A.2. Securing the Last Hop 743 [[ Need to add text here about the various ways that a client who is 744 pulling in TLSA records can be sure that they are protected by 745 DNSSEC. ]] 747 Appendix B. Pseudocode for Using TLSA 749 [[ IMPORTANT NOTE FOR THE DANE WG: Please review this new appendix 750 carefully. If you find differences between what is here and what is 751 in the rest of the draft, by all means please send it to the WG 752 mailing list. The ensuing discussion will hopefully help everyone. 753 ]] 755 This appendix describes the interactions given earlier in this 756 specification in pseudocode format. This appendix is non-normative. 758 If the steps below disagree with the text earlier in the document, 759 the steps earlier in the document should be considered correct and 760 this text incorrect. 762 TLS connect using [transport] to [hostname] on [port] and 763 receiving end entity cert C for the TLS server: 765 look up TLSA for _[port]._[transport].[hostname] 767 if (no secure TLSA record(s) received) { 768 fall back to "normal" cert validation 769 } 771 for each TLSA record R received { 773 // a PKIX certificate that identifies an end entity 774 if (R.certType == 1) { 775 if (R.referenceType == 0) AND (C == R.certAssoc) { 776 accept the TLS connection 777 } else if (hash(R.referenceType of C) == R.certAssoc) { 778 accept the TLS connection 779 } else { 780 continue outer loop 781 } 782 } 784 // a PKIX certification authority's certificate 785 if (R.certType == 2) { 786 if (R.referenceType == 0) { 787 if (PKIX validation with R.certAssoc as the only TA succeeds) { 788 accept the TLS connection 789 } else { 790 continue outer loop 791 } 792 } else { 793 if (PKIX validation with existing TAs succeeds) { 794 for each cert D in path except the EE cert { 795 if (hash(R.referenceType, D) == R.certAssoc) { 796 accept the TLS connection 797 } 798 } 799 } 800 continue outer loop 801 } 802 } 804 // a public key expressed as a PKIX SubjectPublicKeyInfo structure 805 if (R.certType == 3) { 806 if (R.referenceType == 0) AND (publicKey(C) == R.certAssoc) { 807 accept the TLS connection 808 } else if (hash(R.referenceType, publicKey(C)) == R.certAssoc) { 809 accept the TLS connection 810 } else { 811 continue outer loop 812 } 813 } 814 } 816 abort TLS handshake with "access_denied" error. 818 Authors' Addresses 820 Paul Hoffman 821 VPN Consortium 823 Email: paul.hoffman@vpnc.org 825 Jakob Schlyter 826 Kirei AB 828 Email: jakob@kirei.se