idnits 2.17.1 draft-ietf-dane-protocol-12.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 4 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 (September 27, 2011) is 4566 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 531, 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: March 30, 2012 Kirei AB 6 September 27, 2011 8 Using Secure DNS to Associate Certificates with Domain Names For TLS 9 draft-ietf-dane-protocol-12 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 March 30, 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 Usage Field . . . . . . . . . . . . . 5 62 2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 6 63 2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 6 64 2.1.4. The Certificate for Association Field . . . . . . . . 6 65 2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 6 66 2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 7 67 3. Domain Names for TLS Certificate Associations . . . . . . . . 7 68 4. Semantics and Features of TLSA Certificate Usages . . . . . . 8 69 4.1. Pass PKIX Validation and Chain Through CA . . . . . . . . 8 70 4.2. Pass PKIX Validation and Match End Entity Certificate . . 8 71 4.3. Pass PKIX Validation and Use Trust Anchor . . . . . . . . 8 72 4.4. Use of TLS Certificate Associations in TLS . . . . . . . . 8 73 5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 9 74 6. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 11 79 7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Appendix A. Operational Considerations for Deploying TLSA 86 Records . . . . . . . . . . . . . . . . . . . . . . . 14 87 A.1. Provisioning TLSA Records with Aliases . . . . . . . . . . 14 88 A.1.1. Provisioning TLSA Records with CNAME Records . . . . . 15 89 A.1.2. Provisioning TLSA Records with DNAME Records . . . . . 16 90 A.1.3. Provisioning TLSA Records with Wildcards . . . . . . . 16 91 A.2. Provisioning Using NS Records . . . . . . . . . . . . . . 17 92 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 17 93 A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 17 94 Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 The first response from the server in TLS may contain a certificate. 100 In order for the TLS client to authenticate that it is talking to the 101 expected TLS server, the client must validate that this certificate 102 is associated with the domain name used by the client to get to the 103 server. Currently, the client must extract the domain name from the 104 certificate, must trust a trust anchor upon which the server's 105 certificate is rooted, and must successfully validate the 106 certificate. 108 Some people want a different way to authenticate the association of 109 the server's certificate with the intended domain name without 110 trusting an external certificate authority (CA). Given that the DNS 111 administrator for a domain name is authorized to give identifying 112 information about the zone, it makes sense to allow that 113 administrator to also make an authoritative binding between the 114 domain name and a certificate that might be used by a host at that 115 domain name. The easiest way to do this is to use the DNS. 117 There are many use cases for such functionality. [DANEUSECASES] 118 lists the ones that the protocol in this document is meant to apply 119 to. [DANEUSECASES] also lists many requirements, most of which the 120 protocol in this document is believed to meet. Section 5 covers the 121 applicability of this document to the use cases in detail. 123 This document applies to both TLS [RFC5246] and DTLS [RFC4347bis]. 124 In order to make the document more readable, it mostly only talks 125 about "TLS", but in all cases, it means "TLS or DTLS". This document 126 only relates to securely associating certificates for TLS and DTLS 127 with host names; other security protocols and other forms of 128 identification of TLS servers (such as IP addresses) are handled in 129 other documents. For example, keys for IPsec are covered in 130 [RFC4025] and keys for SSH are covered in [RFC4255]. 132 1.1. Certificate Associations 134 In this document, a certificate association is based on a 135 cryptographic hash of a certificate (sometimes called a 136 "fingerprint"), a public key, or on the certificate itself. For a 137 fingerprint, a hash is taken of the binary, DER-encoded certificate 138 or public key, and that hash is the certificate association; the type 139 of hash function used can be chosen by the DNS administrator. When 140 using the certificate itself in the certificate association, the 141 entire certificate in the normal format is used. This document only 142 applies to PKIX [RFC5280] certificates, not certificates of other 143 formats. It also applies to public keys that are extracted from PKIX 144 certificates, not just full certificates. 146 Certificate associations are made between a certificate or public key 147 and a domain name. Server software that is running TLS that is found 148 at that domain name would use a certificate that has a certificate 149 association given in the DNS, as described in this document. A DNS 150 query can return multiple certificate associations, such as in the 151 case of different server software on a single host using different 152 certificates, or in the case that a server is changing from one 153 certificate to another. 155 1.2. Securing Certificate Associations 157 This document defines a secure method to associate the certificate 158 that is obtained from the TLS server with a domain name using DNS; 159 the DNS information may need to be be protected by DNSSEC. Because 160 the certificate association was retrieved based on a DNS query, the 161 domain name in the query is by definition associated with the 162 certificate. 164 DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], 165 [RFC4034], and [RFC4035]), uses cryptographic keys and digital 166 signatures to provide authentication of DNS data. Information 167 retrieved from the DNS and that is validated using DNSSEC is thereby 168 proved to be the authoritative data. The DNSSEC signature MUST be 169 validated on all responses that use DNSSEC in order to assure the 170 proof of origin of the data. This document does not specify how 171 DNSSEC validation occurs because there are many different proposals 172 for how a client might get validated DNSSEC results. 174 This document only relates to securely getting the DNS information 175 for the certificate association using DNSSEC; other secure DNS 176 mechanisms are out of scope. 178 1.3. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 This document also makes use of standard PKIX, DNSSEC, and TLS 185 terminology. See [RFC5280], [RFC4033], and [RFC5246] respectively, 186 for these terms. In addition, terms related to TLS-protected 187 application services and DNS names are taken from [RFC6125]. 189 2. The TLSA Resource Record 191 The TLSA DNS resource record (RR) is used to associate a certificate 192 with the domain name where the record is found. The semantics of how 193 the TLSA RR is interpreted are given later in this document. 195 The type value for the TLSA RR type is TBD. 197 The TLSA RR is class independent. 199 The TLSA RR has no special TTL requirements. 201 2.1. TLSA RDATA Wire Format 203 The RDATA for a TLSA RR consists of a one octet usage type field, a 204 one octet selector field, o one octet matching type field and the 205 certificate for association field. 207 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Usage | Selector | Matching Type | / 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 212 / / 213 / Certificate for Association / 214 / / 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 2.1.1. The Certificate Usage Field 219 A one-octet value, called "certificate usage" or just "usage", 220 specifying the provided association that will be used to match the 221 target certificate. This will be an IANA registry in order to make 222 it easier to add additional certificate usages in the future. The 223 usages defined in this document are: 225 0 -- Certificate MUST pass PKIX validation and MUST chain through 226 a CA certificate matching the TLSA record 228 1 -- Certificate MUST pass PKIX validation and MUST match the TLSA 229 record 231 2 -- Certificate MUST pass PKIX validation, with any certificate 232 matching the TLSA record considered to be a trust anchor for this 233 validation 235 The three certificate usages defined in this document explicitly only 236 apply to PKIX-formatted certificates. If TLS allows other formats 237 later, or if extensions to this protocol are made that accept other 238 formats for certificates, those certificates will need their own 239 certificate types. 241 2.1.2. The Selector Field 243 A one-octet value, called "selector", specifying what will be 244 matched. This value is defined in a new IANA registry. The 245 selectors defined in this document are: 247 0 -- Full certificate 249 1 -- SubjectPublicKeyInfo 251 2.1.3. The Matching Type Field 253 A one-octet value, called "matching type", specifying how the 254 certificate association is presented. This value is defined in a new 255 IANA registry. The types defined in this document are: 257 0 -- Exact match on selected content 259 1 -- SHA-256 hash of selected content 261 2 -- SHA-512 hash of selected content 263 Using the same hash algorithm as is used in the signature in the 264 certificate will make it more likely that the TLS client will 265 understand this TLSA data. 267 2.1.4. The Certificate for Association Field 269 The "certificate for association". This is the bytes containing the 270 full certificate, SubjectPublicKeyInfo or the hash of the associated 271 certificate or SubjectPublicKeyInfo. This is the certificate or the 272 hash of the certificate itself, not of the TLS ASN.1 Certificate 273 object. 275 2.2. TLSA RR Presentation Format 277 The presentation format of the RDATA portion is as follows: 279 o The certificate usage field MUST be represented as an unsigned 280 decimal integer. 282 o The selector field MUST be represented as an unsigned decimal 283 integer. 285 o The matching type field MUST be represented as an unsigned decimal 286 integer. 288 o The certificate for association field MUST be represented as a 289 string of hexadecimal characters. Whitespace is allowed within 290 the string of hexadecimal characters. 292 2.3. TLSA RR Examples 294 An example of a hashed (SHA-256) association of a PKIX CA 295 certificate: 297 _443._tcp.www.example.com. IN TLSA ( 298 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 299 7983a1d16e8a410e4561cb106618e971 ) 301 An example of a hashed (SHA-512) subject public key association of a 302 PKIX end entity certificate: 304 _443._tcp.www.example.com. IN TLSA 305 1 1 2 92003ba34942dc74152e2f2c408d29ec 306 a5a520e7f2e06bb944f4dca346baf63c 307 1b177615d466f6c4b71c216a50292bd5 308 8c9ebdd2f74e38fe51ffd48c43326cbc ) 310 An example of a full certificate association of a PKIX trust anchor: 312 _443._tcp.www.example.com. IN TLSA 313 2 0 0 30820307308201efa003020102020... ) 315 3. Domain Names for TLS Certificate Associations 317 TLSA resource records are stored at a prefixed DNS domain name. The 318 prefix is prepared in the following manner: 320 1. The decimal representation of the port number on which a TLS- 321 based service is assumed to exist is prepended with an underscore 322 character ("_") to become the left-most label in the prepared 323 domain name. This number has no leading zeros. 325 2. The protocol name of the transport on which a TLS-based service 326 is assumed to exist is prepended with an underscore character 327 ("_") to become the second left-most label in the prepared domain 328 name. The transport names defined for this protocol are "tcp", 329 "udp" and "sctp". 331 3. The domain name is appended to the result of step 2 to complete 332 the prepared domain name. 334 For example, to request a TLSA resource record for an HTTP server 335 running TLS on port 443 at "www.example.com", you would use 336 "_443._tcp.www.example.com" in the request. To request a TLSA 337 resource record for an SMTP server running the STARTTLS protocol on 338 port 25 at "mail.example.com", you would use 339 "_25._tcp.mail.example.com". 341 4. Semantics and Features of TLSA Certificate Usages 343 The three certificate usages have very different semantics, but also 344 have features common to all three types. 346 4.1. Pass PKIX Validation and Chain Through CA 348 Certificate usage 0 is used to specify a CA certificate, or the 349 public key of such a certificate, that the must be found in any of 350 the PKIX validation chains for the end entity certificate given by 351 the server in TLS. This usage is sometimes referred to as "CA 352 constraint" because it limits which CA can be used to issue 353 certificates for a given host name. 355 4.2. Pass PKIX Validation and Match End Entity Certificate 357 Certificate usage 1 is used to specify an end entity certificate, or 358 the public key of such a certificate, that must be matched with the 359 end entity certificate given by the server in TLS. This usage is 360 sometimes referred to as "service certificate constraints" because it 361 limits which end entity certificate may be used by a given host name. 363 4.3. Pass PKIX Validation and Use Trust Anchor 365 Certificate usage 2 is used to specify a certificate, or the public 366 key of such a certificate, that must be used as a trust anchor when 367 validating the end entity certificate given by the server in TLS. 368 This usage is sometimes referred to as "domain-issued certificate" 369 because it allows for a domain name administrator to issue 370 certificates for a domain without involving a third-party CA. 372 4.4. Use of TLS Certificate Associations in TLS 374 Section 2.1 of this document defines the mandatory matching rules for 375 the data from the TLS certificate associations and the certificates 376 received from the TLS server. 378 The TLS session that is to be set up MUST be for the specific port 379 number and transport name that was given in the TLSA query. The 380 matching or chaining MUST be done within the life of the TTL on the 381 TLSA record. 383 Some specifications for applications that run under TLS, such as 384 [RFC2818] for HTTP, require the server's certificate to have a domain 385 name that matches the host name expected by the client. Some 386 specifications such at [RFC6125] detail how to match the identify 387 given in a PKIX certificate with those expected by the user. 389 In order to use one or more TLS certificate associations described in 390 this document obtained from the DNS, an application MUST assure that 391 the certificates were obtained using DNS protected by DNSSEC. TLSA 392 records must only be trusted if they were obtained from a trusted 393 source. This could be a localhost DNS resolver answer with the AD 394 bit set, an inline validating resolver library primed with the proper 395 trust anchors, or obtained from a remote name server to which one has 396 a secured channel of communication. 398 If a certificate association contains a certificate usage, selector, 399 or matching type that is not understood by the TLS client, that 400 certificate association MUST be marked as unusable. If the 401 comparison data for a certificate is malformed, the certificate 402 association MUST be marked as unusable. 404 An application that complies with this document first requests TLSA 405 records in order to make certificate associations. If that 406 application receives zero usable certificate associations, it 407 processes TLS in the normal fashion; otherwise, that application 408 attempts to match each certificate association with the TLS server's 409 end entity certificate. If such a match is found, that application 410 continues the TLS handshake and ignores any remaining certificate 411 associations; otherwise, that application MUST abort the TLS 412 handshake with an "access_denied" error. 414 5. TLSA and DANE Use Cases and Requirements 416 The different types of certificates for association defined in TLSA 417 are matched with various sections of [DANEUSECASES]. The three use 418 cases from section 3 of [DANEUSECASES] are covered in this protocol 419 as follows: 421 3.1 CA Constraints -- Implemented using certificate usage 0. 423 3.2 Certificate Constraints -- Implemented using certificate usage 424 1. 426 3.3 Domain-Issued Certificates -- Implemented using certificate 427 usage 2. 429 The requirements from section 4 of [DANEUSECASES] are covered in this 430 protocol as follows (note that some of these might be excessively 431 glib): 433 Multiple Ports -- Covered in the TLSA request syntax. 435 No Downgrade -- Covered by DNSSEC itself. 437 Encapsulation -- Covered in the TLSA response semantics. 439 Predictability -- Covered by this spec. 441 Opportunistic Security -- Covered in the TLSA request syntax. 443 Combination -- Covered in the TLSA response semantics. 445 Roll-over -- Covered by the TTLs on the TLSA records. 447 Simple Key Management -- Implemented using the SubjectPublicKeyInfo 448 selector. 450 Minimal Dependencies -- Covered in the TLSA response semantics. 452 Minimal Options -- Covered in the TLSA response semantics. 454 Wild Cards -- Covered in a limited manner in the TLSA request 455 syntax; see Appendix A. 457 Redirection -- Covered in the TLSA request syntax; see Appendix A. 459 6. Mandatory-to-Implement Algorithms 461 DNS systems conforming to this specification MUST be able to create 462 TLSA records containing certificate usages 0, 1 and 2. DNS systems 463 conforming to this specification MUST be able to create TLSA records 464 with selectors 0 (full certificate) and 1 (SubjectPublicKeyInfo). 465 DNS systems conforming to this specification MUST be able to create 466 TLSA records using matching type 0 (no hash used) and matching type 1 467 (SHA-256), and SHOULD be able to create TLSA records using matching 468 type 2 (SHA-512). 470 TLS clients conforming to this specification MUST be able to 471 correctly interpret TLSA records with certificate usages 0, 1 and 2. 472 TLS clients conforming to this specification MUST be able to compare 473 a certificate for association with a certificate from TLS using 474 selectors type 0 and 1, and matching type 0 (no hash used) and 475 matching type 1 (SHA-256), and SHOULD be able to make such 476 comparisons with matching type 2 (SHA-512). 478 At the time this is written, it is expected that there will be a new 479 family of hash algorithms called SHA-3 within the next few years. It 480 is expected that some of the SHA-3 algorithms will be mandatory 481 and/or recommended for TLSA records after the algorithms are fully 482 defined. At that time, this specification will be updated. 484 7. IANA Considerations 486 7.1. TLSA RRtype 488 This document uses a new DNS RR type, TLSA, whose value is TBD. A 489 separate request for the RR type will be submitted to the expert 490 reviewer, and future versions of this document will have that value 491 instead of TBD. 493 7.2. TLSA Usages 495 This document creates a new registry, "Certificate Usages for TLSA 496 Resource Records". The registry policy is "RFC Required". The 497 initial entries in the registry are: 499 Value Short description Reference 500 ---------------------------------------------------------- 501 0 Pass PKIX and chain through CA [This] 502 1 Pass PKIX and match EE [This] 503 2 Pass PKIX and trusted via certificate [This] 504 4-254 Unassigned 505 255 Private use 507 Applications to the registry can request specific values that have 508 yet to be assigned. 510 7.3. TLSA Selectors 512 This document creates a new registry, "Selectors for TLSA Resource 513 Records". The registry policy is "Specification Required". The 514 initial entries in the registry are: 516 Value Short description Reference 517 ---------------------------------------------------------- 518 0 Full Certificate [This] 519 1 SubjectPublickeyInfo [This] 520 2-254 Unassigned 521 255 Private use 523 7.4. TLSA Matching Types 525 This document creates a new registry, "Matching Types for TLSA 526 Resource Records". The registry policy is "Specification Required". 527 The initial entries in the registry are: 529 Value Short description Reference 530 --------------------------------------------- 531 0 No hash used [This] 532 1 SHA-256 NIST FIPS 180-3 533 2 SHA-512 NIST FIPS 180-3 534 3-254 Unassigned 535 255 Private use 537 Applications to the registry can request specific values that have 538 yet to be assigned. 540 8. Security Considerations 542 The security of the protocols described in this document relies on 543 the security of DNSSEC as used by the client requesting A/AAAA and 544 TLSA records. 546 A DNS administrator who goes rogue and changes both the A/AAAA and 547 TLSA records for a domain name can cause the user to go to an 548 unauthorized server that will appear authorized, unless the client 549 performs certificate validation and rejects the certificate. That 550 administrator could probably get a certificate issued anyway, so this 551 is not an additional threat. 553 If the authentication mechanism for adding or changing TLSA data in a 554 zone is weaker than the authentication mechanism for changing the 555 A/AAAA records, a man-in-the-middle who can redirect traffic to their 556 site may be able to impersonate the attacked host in TLS if they can 557 use the weaker authentication mechanism. A better design for 558 authenticating DNS would be to have the same level of authentication 559 used for all DNS additions and changes for a particular host. 561 SSL proxies can sometimes act as a man-in-the-middle for TLS clients. 562 In these scenarios, the clients add a new trust anchor whose private 563 key is kept on the SSL proxy; the proxy intercepts TLS requests, 564 creates a new TLS session with the intended host, and sets up a TLS 565 session with the client using a certificate that chains to the trust 566 anchor installed in the client by the proxy. In such environments, 567 the TLSA protocol will prevent the SSL proxy from functioning as 568 expected because the TLS client will get a certificate association 569 from the DNS that will not match the certificate that the SSL proxy 570 uses with the client. The client, seeing the proxy's new certificate 571 for the supposed destination will not set up a TLS session. Thus, 572 such proxies might choose to aggressively block TLSA requests and/or 573 responses. 575 Client treatment of any information included in the trust anchor is a 576 matter of local policy. This specification does not mandate that 577 such information be inspected or validated by the domain name 578 administrator. 580 9. Acknowledgements 582 Many of the ideas in this document have been discussed over many 583 years. More recently, the ideas have been discussed by the authors 584 and others in a more focused fashion. In particular, some of the 585 ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, 586 Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben 587 Laurie, Ilari Liusvaara, Scott Schmit, Ondrej Sury, Richard Barnes, 588 and Jim Schaad. 590 This document has also been greatly helped by many active 591 participants of the DANE Working Group. 593 10. References 595 10.1. Normative References 597 [DANEUSECASES] 598 Barnes, R., "Use Cases and Requirements for DNS-based 599 Authentication of Named Entities (DANE)", 600 draft-ietf-dane-use-cases (work in progress), 2011. 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, March 1997. 605 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 606 Rose, "DNS Security Introduction and Requirements", 607 RFC 4033, March 2005. 609 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 610 Rose, "Resource Records for the DNS Security Extensions", 611 RFC 4034, March 2005. 613 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 614 Rose, "Protocol Modifications for the DNS Security 615 Extensions", RFC 4035, March 2005. 617 [RFC4347bis] 618 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 619 Security version 1.2", draft-ietf-tls-rfc4347-bis (work in 620 progress), July 2010. 622 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 623 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 625 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 626 Housley, R., and W. Polk, "Internet X.509 Public Key 627 Infrastructure Certificate and Certificate Revocation List 628 (CRL) Profile", RFC 5280, May 2008. 630 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 631 Verification of Domain-Based Application Service Identity 632 within Internet Public Key Infrastructure Using X.509 633 (PKIX) Certificates in the Context of Transport Layer 634 Security (TLS)", RFC 6125, March 2011. 636 10.2. Informative References 638 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 639 specifying the location of services (DNS SRV)", RFC 2782, 640 February 2000. 642 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 644 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 645 Material in DNS", RFC 4025, March 2005. 647 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 648 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 649 January 2006. 651 Appendix A. Operational Considerations for Deploying TLSA Records 653 A.1. Provisioning TLSA Records with Aliases 655 The TLSA resource record is not special in the DNS; it acts exactly 656 like any other RRtype where the queried name has one or more labels 657 prefixed to the base name, such as the SRV RRtype [RFC2782]. This 658 affects the way that the TLSA resource record is used when aliasing 659 in the DNS. 661 Note that the IETF sometimes adds new types of aliasing in the DNS. 662 If that happens in the future, those aliases might affect TLSA 663 records, hopefully in a good way. 665 A.1.1. Provisioning TLSA Records with CNAME Records 667 Using CNAME to alias in DNS only aliases from the exact name given, 668 not any zones below the given name. For example, assume that a zone 669 file has only the following: 671 sub1.example.com. IN CNAME sub2.example.com. 673 In this case, a request for the A record at "bottom.sub1.example.com" 674 would not return any records because the CNAME given only aliases the 675 name given. Assume, instead, the zone file has the following: 677 sub3.example.com. IN CNAME sub4.example.com. 678 bottom.sub3.example.com. IN CNAME bottom.sub4.example.com. 680 In this case, a request for the A record at bottom.sub3.example.com 681 would in fact return whatever value for the A record exists at 682 bottom.sub4.example.com. 684 Application implementations and full-service resolvers request DNS 685 records using libraries that automatically follow CNAME (and DNAME) 686 aliasing. This allows hosts to put TLSA records in their own zones 687 or to use CNAME to do redirection. 689 If the owner of the original domain wants a TLSA record for the same, 690 they simply enter it under the defined prefix: 692 ; No TLSA record in target domain 693 ; 694 sub5.example.com. IN CNAME sub6.example.com. 695 _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... 696 sub6.example.com. IN A 10.0.0.0 698 If the owner of the orginal domain wants to have the target domain 699 host the TLSA record, the original domain uses a CNAME record: 701 ; TLSA record for original domain has CNAME to target domain 702 ; 703 sub5.example.com. IN CNAME sub6.example.com. 704 _443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com. 705 sub6.example.com. IN A 10.0.0.0 706 _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4... 708 Note that it is acceptable for both the original domain and the 709 target domain to have TLSA records, but the two records are 710 unrelated. Consider the following: 712 ; TLSA record in both the original and target domain 713 ; 714 sub5.example.com. IN CNAME sub6.example.com. 715 _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... 716 sub6.example.com. IN A 10.0.0.0 717 _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... 719 In this example, someone looking for the TLSA record for 720 sub5.example.com would always get the record whose value starts 721 "308202c5308201ab"; the TLSA record whose value starts 722 "ac49d9ba4570ac49" would only be sought by someone who is looking for 723 the TLSA record for sub6.example.com, and never for sub5.example.com. 725 Note that these methods use the normal method for DNS aliasing using 726 CNAME: the DNS client requests the record type that they actually 727 want. 729 A.1.2. Provisioning TLSA Records with DNAME Records 731 Using DNAME records allows a zone owner to alias an entire subtree of 732 names below the name that has the DNAME. This allows the wholesale 733 aliasing of prefixed records such as those used by TLSA, SRV, and so 734 on without aliasing the name itself. However, because DNAME can only 735 be used for subtrees of a base name, it is rarely used to alias 736 individual hosts that might also be running TLS. 738 ; TLSA record in target domain, visible in original domain via DNAME 739 ; 740 sub5.example.com. IN CNAME sub6.example.com. 741 _tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com. 742 sub6.example.com. IN A 10.0.0.0 743 _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4... 745 A.1.3. Provisioning TLSA Records with Wildcards 747 Wildcards are generally not terribly useful for RRtypes that require 748 prefixing because you can only wildcard at a layer below the host 749 name. For example, if you want to have the same TLSA record for 750 every TCP port for www.example.com, you might have 752 *._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b... 754 This is possibly useful in some scenarios where the same service is 755 offered on many ports. 757 A.2. Provisioning Using NS Records 759 [[ This was proposed, and questioned, and not yet followed through 760 on. ]] 762 A.3. Securing the Last Hop 764 [[ Need to add text here about the various ways that a client who is 765 pulling in TLSA records can be sure that they are protected by 766 DNSSEC. ]] 768 A.4. Handling Certificate Rollover 770 [[ Need to add text here about how to handle a change in certificate. 771 It would cover using two TLSA records at the same time, the TTL on 772 the RRset, and coordinating that with the use of the certificates in 773 the TLS server. ]] 775 Appendix B. Pseudocode for Using TLSA 777 [[ IMPORTANT NOTE FOR THE DANE WG: Please review this new appendix 778 carefully. If you find differences between what is here and what is 779 in the rest of the draft, by all means please send it to the WG 780 mailing list. The ensuing discussion will hopefully help everyone. 781 ]] 783 This appendix describes the interactions given earlier in this 784 specification in pseudocode format. This appendix is non-normative. 785 If the steps below disagree with the text earlier in the document, 786 the steps earlier in the document should be considered correct and 787 this text incorrect. 789 TLS connect using [transport] to [hostname] on [port] and 790 receiving end entity cert C for the TLS server: 792 look up TLSA for _[port]._[transport].[hostname] 794 if (no secure TLSA record(s) received) { 795 fall back to non-TLSA cert validation 796 } 798 // unusable records include unknown certUsage, unknown selectorType, 799 // unknown matchingType, and erroneous RDATA 800 strip unusable records 801 if (no usable TLSA record(s) received) { 802 fall back to non-TLSA cert validation 803 } 804 // implement the selector function 805 function Select(S, X) = { 806 if (S == 0) { 807 return X 808 } 809 if (S == 1) { 810 return X.SubjectPublicKey 811 } 812 return undef 813 } 815 // implement the matching function 816 function Match(M, X, Y) { 817 if (M == 0) { 818 return (X == Y) 819 } 820 if (M == 1) { 821 return (SHA-256(X) == Y) 822 } 823 if (M == 2) { 824 return (SHA-512(X) == Y) 825 } 826 return undef 827 } 829 // A TLS client might have multiple trust anchors that it might use 830 // when validating the TLS server's end entity certificate. Also, 831 // there can be multiple PKIX validation chains for the 832 // certificates given by the server in TLS. Thus, there are 833 // possibly many chains that might need to be tested during 834 // PKIX validation. 836 for each TLSA record R { 838 // pass PKIX validation and chain through CA cert from TLSA 839 if (R.certUsage == 0) { 840 for each PKIX validation chain H { 841 if (C passes PKIX validation in H) { 842 for each D in H { 843 if (D is a CA certificate) and 844 Match(matchingType, Select(selectorType, D), R) { 845 accept the TLS connection 846 } 847 } 848 } 849 } 851 // pass PKIX validation and match EE cert from TLSA 852 if (R.certUsage == 1) { 853 for each PKIX validation chain H { 854 if (C passes PKIX validation in H) { 855 if (Match(matchingType, Select(selectorType, C), R)) { 856 accept the TLS connection 857 } 858 } 859 } 860 } 862 // pass PKIX validation using TLSA record as trust anchor 863 if (R.certUsage == 2) { 864 for each PKIX validation chain H that has R as the trust anchor { 865 if (C passes PKIX validation in H) { 866 accept the TLS connection 867 } 868 } 869 } 871 } 873 abort TLS handshake with "access_denied" error. 875 Authors' Addresses 877 Paul Hoffman 878 VPN Consortium 880 Email: paul.hoffman@vpnc.org 882 Jakob Schlyter 883 Kirei AB 885 Email: jakob@kirei.se