idnits 2.17.1 draft-hoffman-keys-linkage-from-dns-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 4, 2010) is 4952 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: April 7, 2011 Kirei AB 6 W. Kumari 7 A. Langley 8 Google 9 October 4, 2010 11 Using Secure DNS to Associate Certificates with Domain Names For TLS 12 draft-hoffman-keys-linkage-from-dns-03 14 Abstract 16 TLS and DTLS use certificates for authenticating the server. Users 17 want their applications to verify that the certificate provided by 18 the TLS server is in fact associated with the domain name they 19 expect. Instead of trusting a certificate authority to have made 20 this association correctly, the user might instead trust the 21 authoritative DNS server for the domain name to make that 22 association. This document describes how to use secure DNS to 23 associate the TLS server's certificate with the the intended domain 24 name. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 7, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 1. Introduction 60 The first response from the server in TLS may contain a certificate. 61 In order for the TLS client to authenticate that it is talking to the 62 expected TLS server, the client must validate that this certificate 63 is associated with the domain name used by the client to get to the 64 server. Currently, the client must extract the domain name from the 65 certificate, must trust the trust anchor upon which the server's 66 certificate is rooted, and must perform correct validation on the 67 certificate. 69 This document applies to both TLS [RFC5246] and DTLS [4347bis]. In 70 order to make the document more readable, it mostly only talks about 71 "TLS", but in all cases, it means "TLS or DTLS". 73 Some people want a different way to authenticate the association of 74 the server's certificate with the intended domain name without 75 trusting the CA. Given that the DNS administrator for a domain name 76 is authorized to give identifying information about the zone, it 77 makes sense to allow that administrator to also make an authoritative 78 binding between the domain name and a certificate that might be used 79 by a host at that domain name. The easiest way to do this is to use 80 the DNS. 82 In this document, a certificate association is based on a 83 cryptographic hash of a certificate (sometimes called a 84 "fingerprint"). That is, a hash is taken of the certificate, and 85 that hash is the certificate association. The type of hash function 86 used can be chosen by the DNS administrator. (Note that there may be 87 other methods to securely obtain certificate associations in DNS, but 88 those methods are not covered by this document.) 90 Certificate associations are made between a hash of a certificate and 91 a domain name. Server software that is running TLS that is found at 92 that domain name would use a certificate that has a certificate 93 association given in the DNS, as described in this document. A DNS 94 query can return multiple certificate associations, such as in the 95 case of different server software on a single host using different 96 certificates (even if they are normally accessed with different host 97 names), or in the case that a server is changing from one certificate 98 to another. 100 DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], 101 [RFC4034], and [RFC4035]), uses cryptographic keys and digital 102 signatures to provide authentication of DNS data. Information 103 retrieved from the DNS and that is validated using DNSSEC is thereby 104 proved to be the authoritative data. 106 This document defines a secure method to associate the certificate 107 that is obtained from the TLS server with a domain name using DNS 108 protected by DNSSEC. Because the certificate association was 109 retrieved based on a DNS query, the domain name in the query is by 110 definition associated with the certificate. 112 This document only relates to securely getting the DNS information 113 for the certificate association using DNSSEC; other secure DNS 114 mechanisms are out of scope. The DNSSEC signature MUST be validated 115 on all responses in order to assure the proof of origin of the data. 117 This document only relates to securely associating certificates for 118 TLS and DTLS with host names; other security protocols are handled in 119 other documents. For example, keys for IPsec are covered in 120 [RFC4025] and keys for SSH are covered in [RFC4255]. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 This document is being discussed on the "keyassure" mailing list; see 127 . 129 2. Getting TLS Certificate Associations from the DNS with the CERT RR 131 The CERT RR [RFC4398] allows expansion by defining new certificate 132 types. This document describes two new Certificate Types, TLSFP and 133 TLSRQ. A query on a domain name for the CERT RR can return one or 134 more records of the type CERT, and zero or more of those CERT 135 responses can be of type TLSFP and TLSRQ. 137 2.1. The TLSFP Certificate Type 139 This section describes the TLSFP certificate type of the CERT RR. 140 The TLSFP certificate type is TBD1. The key tag and algorithm fields 141 are both set to zero. 143 The format of the TLSFP certificate is a binary record, which MUST be 144 in the order defined here, is: 146 o A one-octet value, called "hash type", specifying the type of hash 147 algorithm used for the certificate association. This value has 148 the same values as those of the TLS hash, as defined in the IANA 149 registry titled "TLS HashAlgorithm Registry" 150 (). For example, 151 the value for the SHA-1 hash function is "2". 153 o A one-octet value, called "certificate type", specifying the TLS 154 certificate type of the target certificate. This value has the 155 same values as those of the TLS certificate types, as defined in 156 the IANA registry titled "TLS Certificate Types" 157 (). For 158 example, the value for PKIX certificates is "0". 160 o A variable-length set of bytes containing the hash of the 161 associated certificate (that is, of the certificate itself, not 162 the TLS ASN.1Cert object). 164 An example of a fingerprint for a single certificate: 166 www.example.com. IN CERT 167 TLSFP 0 0 AgDne3GdTpxjwLCgMzvgpBiOSQthjg== 169 An example of a fingerprint of a certificate that is found by its 170 hash value: 172 e77b719d4e9c63c0b0a0333be0a4188e490b618e.www.example.com. IN CERT 173 TLSFP 0 0 AgDne3GdTpxjwLCgMzvgpBiOSQthjg== 175 A note on terminology: Some people have said that TLSFP is a form of 176 "certificate exclusion". This is true, but in a very unusual sense. 177 That is, a DNS reply that contains one TLSFP certificate type 178 inherently excludes every other possible certificate in the universe 179 other than those found with a pre-image attack. The TLSFP 180 certificate type is better thought of as "enumeration" of a small 181 number of certificate associations, not "exclusion" of a near- 182 infinite number of other certificates. 184 2.2. The TLSRQ Certificate Type 186 This section describes the TLSRQ certificate type of the CERT RR. If 187 a domain has many certificates associated with it, the number of 188 TLSFP CERT RRs may become impractical. In this case, a TLSRQ 189 certificate type may be used. 191 The semantics of the TLSRQ certificate type are that the requesting 192 party should send another query for the CERT RR that is formed by 193 prepending a label to the host name that is the hex of the SHA-1 hash 194 value taken over the certificate (not the TLS ASN.1Cert object). If 195 that certificate is a valid certificate that would have been returned 196 in a TLSFP certificate type, requesting it with this encoded hash 197 prepended to the host name will yield a TLSFP certificate type. 198 There is no security problem with using SHA-1 even if the SHA-1 hash 199 function continues to weaken because the hash is simply used to 200 differentiate the various certificates used by the server. 202 Note that the TLSRQ certificate type can only be used if the 203 requesting party knows the hash of the certificate that is being used 204 by the TLS server. This usually means that the request will be sent 205 by the application acting as the TLS client after it has received the 206 TLS server's Certificate message that contains the server's 207 certificate. Such a request can slow down the TLS handshake 208 processing, but is required in the case where different hosts with 209 different certificates respond on the same domain name. 211 The typical scenario would look like the following: 213 1. The application client that is about to use TLS sends a CERT 214 query for www.example.com. 216 2. The name server responds with a CERT record that has a TLSRQ 217 certificate type. 219 3. The application client starts the TLS handshake, and receives a 220 Certificate message from the server. 222 4. The application client takes the SHA-1 hash of the certificate, 223 encodes that value as hex. For this example, assume that encoded 224 value is "e77b719d4e9c63c0b0a0333be0a4188e490b618e". 226 5. The application client sends a CERT query for 227 e77b719d4e9c63c0b0a0333be0a4188e490b618e.www.example.com. It 228 receives a response with a TLSFP certificate type. 230 6. The application uses the information in the TLSFP certificate 231 type and associates it with www.example.com. 233 The TLSRQ certificate type has a certificate body with a single octet 234 of 0. The TLSFP certificate type is TBD2. 236 For example: 238 www.example.com. IN CERT TLSRQ 0 0 AA= 240 3. Use of TLS Certificate Associations in TLS 242 In order to use one or more TLS certificate associations described in 243 this document obtained from the DNS, an application MUST assure that 244 the certificates were obtained using DNS protected by DNSSEC. 246 If a certificate association contains a hash type that is not 247 understood by the TLS client, that certificate association MUST be 248 completely ignored. 250 An application that requests TLS certificate associations using the 251 method described in this document obtains zero or more usable 252 certificate associations. If the application receives zero usable 253 certificate associations, it process TLS in the normal fashion. 255 If a match between one of the certificate association(s) and the 256 server's end entity certificate in TLS is found, the TLS client 257 continues the TLS handshake. If a match between the certificate 258 association(s) and the server's end entity certificate in TLS is not 259 found, the TLS client MUST abort the handshake with an 260 "access_denied" error. 262 3.1. Certificate Validation by TLS Clients When Using Certificate 263 Associations 265 TLS client policy is deliberately not prescribed by this 266 specification. A client MAY choose to trust a DNSSEC-secured 267 certificate association, depending on its local policy. 269 3.1.1. Use of Self-Signed Certificates 271 One expected use case for this protocol is that some TLS servers will 272 begin to use self-signed certificates in association with certificate 273 associations. A TLS client that is using this protocol needs to 274 treat self-signed certificates as special, and thus SHOULD NOT 275 attempt certificate validation on them. (An exception to this rule 276 would be clients that keep self-signed end entity certificates in its 277 trust anchor store.) 279 3.1.2. Ignorning Host Names in Certificates 281 All data in a self-signed certificate other than the key itself can 282 be ignored as untrusted unless a client validates the self-signed 283 certificate to a trust anchor that is identical to the certificate. 284 That means that the host name given in the self-signed certificate is 285 meaningless, and that the only way to associate the public key in the 286 certificate with the domain name is through the certificate 287 association made in the DNS, secured with DNSSEC. 289 If a TLS client fully trusts the association between a domain name 290 and the certificate that was provided by the DNS, then that client 291 MUST ignore the domain name that is given in the certificate. That 292 is, the certificate might contain a domain name that is different 293 than the one that was used to get the TLSFP record, but if the client 294 is trusting the TLSFP record, it doesn't matter what domain name is 295 used in the certificate. An expected use case for this protocol is 296 to allow someone who controls the private key on a certificate to use 297 that certificate for multiple TLS servers. These servers might be on 298 a single computer that has many domain names (such as a computer that 299 is both a web host and a mail host, and is known by both 300 "www.example.com" and "smtp.example.com"), or they might be on 301 different computers (such as multiple computers that all respond IP 302 addresses reachable as "www.example.com"). 304 3.1.3. Use of Local Trust Anchors 306 Another expected use case for this protocol is that some TLS servers 307 will use certificates that chain to a trust anchor that might not be 308 one that is trusted by the TLS client, such as a local certificate 309 authority (CA) that is administered by the organization that runs the 310 TLS server. Because of this, a TLS client that is using this 311 protocol that performs certificate validation on server certificates 312 MAY have a method to communicate with the user that differentiates 313 between validation failures that occur on certificates that have had 314 secure certificate associations and those that have not. If it does 315 not have such a method of communication, the failure to validate 316 SHOULD cause the same error as for any other certificate validation. 318 3.1.4. Use of Additional Certificate Data 320 Some TLS clients extract data from the certificate other than the key 321 to show to the user; for example, most modern web browsers have the 322 ability to show an extended validation (EV) name that is embedded in 323 a certificate. Because this data comes from a trusted third party 324 and not the TLS server itself, TLS clients that extract additional 325 information from TLS server certificates MUST validate those 326 certificates in the normal fashion. 328 4. IANA Considerations 330 This document requests that IANA allocates two certificate types from 331 the CERT RR certificate type registry 332 (). The types are to 333 be allocated from the 'IETF Consensus' range. 335 Decimal type: TBD1 336 Type: TLSFP 337 Meaning: TLS certificate associations 339 Decimal type: TBD2 340 Type: TLSRQ 341 Meaning: Client should request TLS certificate associations 342 retrieved using hashes 344 5. Security Considerations 346 The security of the protocols described in this document relies on 347 the security of DNSSEC as used by the client requesting A and CERT 348 records. 350 A DNS administrator who goes rogue and changes both the A and CERT 351 records for a domain name can cause the user to go to an unauthorized 352 server that will appear authorized, unless the client performs 353 certificate validation and rejects the certificate. 355 The SHA-1 hash used in the queries after the TLSRQ certificate type 356 is only used to differentiate certificates. If there is a collision 357 between the SHA-1 hashes of two certificates used by the servers that 358 are at the host name, there is no problem because both of those 359 certificates will have the same association to the domain name. 361 The values of the TLSFP and TLSRQ records will be normally entered in 362 the DNS through the same system used to enter A/AAAA records, and 363 other DNS information for the host name. If the authentication for 364 changes to the host information is weak, an attacker can easily 365 change any of this information. Given that the TLSFP and TLSRQ 366 records are not easily human-readable, an attacker might change those 367 records and A/AAAA records and not have the change be noticed if 368 changes to a zone are only monitored visually. 370 If the authentication mechanism for adding or changing TLSFP and 371 TLSRQ records in a zone is weaker than the authentication mechanism 372 for changing the A/AAAA records, an man-in-the-middle who can 373 redirect traffic to their site may be able to impersonate the 374 attacked host in TLS if they can use the weaker authentication 375 mechanism. A better design for authenticating DNS would be to have 376 the same level of authentication used for all DNS additions and 377 changes for a particular host. 379 6. Acknowledgements 381 Many of the ideas in this document have been discussed over many 382 years. More recently, the ideas have been discussed by the authors 383 and others in a more focused fashion. In particular, some of the 384 ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, 385 Simon Josefsson, Phill Hallam-Baker, Ilari Liusvaara, among others. 387 7. References 389 7.1. Normative References 391 [4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 392 Security version 1.2", draft-ietf-tls-rfc4347-bis (work in 393 progress), July 2010. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 399 Rose, "DNS Security Introduction and Requirements", 400 RFC 4033, March 2005. 402 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 403 Rose, "Resource Records for the DNS Security Extensions", 404 RFC 4034, March 2005. 406 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 407 Rose, "Protocol Modifications for the DNS Security 408 Extensions", RFC 4035, March 2005. 410 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 411 System (DNS)", RFC 4398, March 2006. 413 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 414 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 416 7.2. Informative References 418 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 419 Material in DNS", RFC 4025, March 2005. 421 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 422 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 423 January 2006. 425 Appendix A. Ideas Considered But Not Necessarily Chosen 427 This appendix will list some of the ideas that have been kicked 428 around in this space and give a few paragraphs why they weren't 429 chosen for the current version this proposal. The following is a 430 placeholder for the list that will be filled out more in future 431 versions of this document: 433 o A flag that indicates that the certificate with the associated key 434 must be signed by a trusted CA. Briefly: this was not added 435 because it is up to the TLS server to decide which type of 436 certificate it wants to serve up. Serving a self-signed 437 certificate would effectively disable traditional certificate 438 validation, whereas serving a certificate signed by a trusted CA 439 would require both validation by DNSSEC and the trusted CA. 441 o A flag that indicates that all connections to this server need to 442 be TLS secured. Briefly: this is a good idea but it is not 443 related to the key of the certificate given in TLS, and thus 444 should be indicated in a different method. 446 o Giving keys instead of hashes of keys. Briefly: TLS requires that 447 the server gives a certificate, and some systems use the metadata 448 from a CA-signed certificate for display, so there is value to 449 always looking in the certificate. 451 o Hashes of keys vs. hashes of certificates. Briefly: we have 452 changed our minds (at least once) on this. Our original thinking 453 was that there are many reasons why someone might change their 454 certificate while leaving the public key alone, and those changes 455 should not have to force them to change the DNS record because 456 they do not actually change what the TLS client cares about; thus, 457 use hashes of keys. Our new thinking is that there are 458 certificate semantics that we want to pass (namely, should the 459 client actually do the certificate validation), and attaching 460 those semantics to keys is confusing; thus, use hashes of 461 certificates. 463 o List TLS/DTLS ports or services for which the certificate is 464 associated. Briefly: we had this in an earlier version of this 465 document but got rid of it when it was pointed out that this is an 466 edge case, and most servers differentiate these services by domain 467 names such as "mail.example.com" and "www.example.com". 469 o Different ways of encoding this information in the DNS. Briefly: 470 we considered a new RR type and coming up with an encoding of the 471 TXT RR type, but didn't see any significant advantage of them over 472 using the CERT RR, and there were disadvantages. A disadvantage 473 of a new RR type is getting DNS servers and clients to recognize 474 it; a disadvantage of coming up with a new TXT format is that 475 doing so prevents wildcards. There is a lot more to discuss here, 476 but the authors are now happy with a new sub-type for the CERT RR. 478 o Having the hash be over the TLS certificate structure instead of 479 just the end-entity certificate. Briefly: the TLS certificate 480 structure currently allows a chain of PKIX certificates, and the 481 semantics of what is being associated in a chain is not clear. 482 Further, the structure might be changed in the future (such as to 483 allow a group of web-of-trust OpenPGP certificates), and the 484 semantics of what is being associated would become even less 485 clear. 487 o Having an "always uses TLS" flag in the TLSFP record. Briefly: 488 the policy of always using TLS should be carried elsewhere because 489 it does not line up exactly with TLSFP. Having this flag in the 490 TLSFP record can lead to silly states if a site has multiple TLSFP 491 records that have the flag set differently. It is completely 492 unclear what such a flag will mean for SMTP, which uses a STARTTLS 493 mechanism built into the unprotected protocol. If the TLSFP 494 record does not apply to a specific service, then all services on 495 that hose that could use TLS must do so or not do so together. 496 Note, however, that we believe that an "always uses TLS" statement 497 should be available in the DNS. 499 Appendix B. Changes between -00 and -01 501 Change the association from being a hash of the key of a PKIX 502 certificate to being a hash of a certificate (PKIX or other). This, 503 of course, makes large changes throughout the document. 505 Expanded the document to cover DTLS as well. 507 Added a pointer to the keyassure mailing list. 509 Removed the proposals for two alternate formats (the TLSFP Resource 510 Record and the TXT record encoding). Added a bit to Appendix A about 511 this. 513 Got rid of the specification for ports within a single domain name. 515 Made the hash type one octet and used the DS registry instead of 516 defining our own. 518 Added "Necessarily" chosen in the title of Appendix A to show that we 519 might (continue to) change our minds after discussion. 521 Added Simon Josefsson to the acknowledgements. 523 Appendix C. Changes between -01 and -02 525 Added the TLSRQ certificate type and its semantics. 527 Pointed to the IANA registry for DS hash types. 529 Added Phill Hallam-Baker to the acknowledgements. 531 Appendix D. Changes between -02 and -03 533 In 1, added "In this document" to clarify that there may be other 534 types of certificate associations described elsewhere. Also moved 535 the sentence from 3 to 1 to help make that point earlier. 537 Added a paragraph to 1 to emphasize that multiple TLSFP records can 538 be returned for cases where different server software on one host 539 uses different certificates. 541 In 2.1, got rid of "validation preference". 543 In 2.1, changed the values for the hash type from being from the IANA 544 registry for DNS to the IANA registry for TLS. This caused a change 545 in the examples from "0" to "2". 547 In 2.1, added a one-octet value for "certificate type". 549 At the end of 2.1, added a paragraph about the term "exclusion". 551 Clarified section 3 to make it clear that the certificate 552 associations being described are only the ones from this document. 553 Also clarified the semantics of finding a match. 555 Removed the last paragraph of 3 (about validation preference) and 556 created 3.1 to talk about validation. 558 In 5, added "unless the client performs certificate validation and 559 rejects the certificate" to the second paragraph. 561 In 5, added a new paragraph about monitoring zone changes visually, 562 and added a new paragraph about separate authentication mechanisms 563 for the TLS-specific records. 565 Added Ilari Liusvaara to acknowledgments. 567 In Appendix A, added a paragraph about why we do not have a "always 568 uses TLS" flag in this protocol. 570 Authors' Addresses 572 Paul Hoffman 573 VPN Consortium 575 Email: paul.hoffman@vpnc.org 577 Jakob Schlyter 578 Kirei AB 580 Email: jakob@kirei.se 582 Warren Kumari 583 Google 585 Email: warren@kumari.net 587 Adam Langley 588 Google 590 Email: agl@google.com