idnits 2.17.1 draft-hoffman-keys-linkage-from-dns-02.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 (September 15, 2010) is 4971 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: March 19, 2011 Kirei AB 6 W. Kumari 7 A. Langley 8 Google 9 September 15, 2010 11 Using Secure DNS to Associate Certificates with Domain Names For TLS 12 draft-hoffman-keys-linkage-from-dns-02 14 Abstract 16 TLS and DTLS uses 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 March 19, 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 one 65 of many places in the certificate, must trust the trust anchor upon 66 which the server's certificate is rooted, and must perform correct 67 validation on the 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 A certificate association is a cryptographic hash of a certificate 83 (sometimes called a "fingerprint"). That is, a hash is taken of the 84 certificate, and that hash is the certificate association. The type 85 of hash function used can be chosen by the DNS administrator. 87 DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], 88 [RFC4034], and [RFC4035]), uses cryptographic keys and digital 89 signatures to provide authentication of DNS data. Information 90 retrieved from the DNS and that is validated using DNSSEC is thereby 91 proved to be the authoritative data. 93 This document defines a secure method to associate the certificate 94 that is obtained from the TLS server with a domain name using DNS 95 protected by DNSSEC. Because the certificate association was 96 retrieved based on a DNS query, the domain name in the query is by 97 definition associated with the certificate. 99 This document only relates to securely getting the DNS information 100 for the certificate association using DNSSEC; other secure DNS 101 mechanisms are out of scope. The DNSSEC signature MUST be validated 102 on all responses in order to assure the proof of origin of the data. 104 This document only relates to securely associating certificates for 105 TLS and DTLS; other security protocols are handled in other 106 documents. For example, keys for IPsec are covered in [RFC4025] and 107 keys for SSH are covered in [RFC4255]. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 This document is being discussed on the "keyassure" mailing list; see 114 . 116 2. Getting TLS Certificate Associations from the DNS with the CERT RR 118 The CERT RR [RFC4398] allows expansion by defining new certificate 119 types. This document describes two new Certificate Types, TLSFP and 120 TLSRQ. A query on a domain name for the CERT RR can return one or 121 more records of the type CERT, and zero or more of those CERT 122 responses can be of type TLSFP and TLSRQ. 124 2.1. The TLSFP Certificate Type 126 This section describes the TLSFP certificate type of the CERT RR. 127 The TLSFP certificate type is TBD1. The key tag and algorithm fields 128 are both set to zero. 130 The format of the TLSFP certificate is a binary record, which MUST be 131 in the order defined here, is: 133 o A one-octet value, called "hash type", specifying the type of hash 134 algorithm used for the certificate association. This value has 135 the same values as those of the DS RR, as defined in the IANA 136 registry titled "Delegation Signer (DS) Resource Record (RR) Type 137 Digest Algorithms" 138 (). 140 o A one-octet value, called "validation preference", specifying the 141 preferences for further validation of the certificate in TLS. A 142 certificate association that contains a validation preference 143 whose value is 1 indicates that the TLS administrator believes 144 that it is sufficient to match the certificate association with 145 the hash of certificate received in the TLS negotiation, and that 146 no further certificate validation is necessary. A certificate 147 association that contains a validation preference whose value is 0 148 indicates that the TLS administrator believes that it is not 149 sufficient to match the certificate association with the hash of 150 certificate received in the TLS negotiation, and that normal 151 certificate validation is necessary. Note that the validation 152 preference is an advisory, and it is not mandatory for a TLS 153 client to follow the advice. 155 o A variable-length set of bytes containing the hash of the 156 associated certificate (that is, of the certificate itself, not 157 the TLS ASN.1Cert object). 159 An example of a fingerprint for a single certificate: 161 www.example.com. IN CERT 162 TLSFP 0 0 AQDne3GdTpxjwLCgMzvgpBiOSQthjg== 164 An example of a fingerprint of a certificate that is found by its 165 hash value: 167 e77b719d4e9c63c0b0a0333be0a4188e490b618e.www.example.com. IN CERT 168 TLSFP 0 0 AQDne3GdTpxjwLCgMzvgpBiOSQthjg== 170 2.2. The TLSRQ Certificate Type 172 This section describes the TLSRQ certificate type of the CERT RR. If 173 a domain has many certificates associated with it, the number of 174 TLSFP CERT RRs may become impractical. In this case, a TLSRQ 175 certificate type may be used. 177 The semantics of the TLSRQ certificate type are that the requesting 178 party should send another query for the CERT RR that is formed by 179 prepending a label to the host name that is the hex of the SHA-1 hash 180 value taken over the certificate (not the TLS ASN.1Cert object). If 181 that certificate is a valid certificate that would have been returned 182 in a TLSFP certificate type, requesting it with this encoded hash 183 prepended to the host name will yield a TLSFP certificate type. 184 There is no security problem with using SHA-1 even if the SHA-1 hash 185 function continues to weaken because the hash is simply used to 186 differentiate the various certificates used by the server. 188 Note that the TLSRQ certificate type can only be used if the 189 requesting party knows the hash of the certificate that is being used 190 by the TLS server. This usually means that the request will be sent 191 by the application acting as the TLS client after it has received the 192 TLS server's Certificate message that contains the server's 193 certificate. Such a request can slow down the TLS handshake 194 processing, but is required in the case where different hosts with 195 different certificates respond on the same domain name. 197 The typical scenario would look like the following: 199 1. The application client that is about to use TLS sends a CERT 200 query for www.example.com. 202 2. The name server responds with a CERT record that has a TLSRQ 203 certificate type. 205 3. The application client starts the TLS handshake, and receives a 206 Certificate message from the server. 208 4. The application client takes the SHA-1 hash of the certificate, 209 encodes that value as hex. For this example, assume that encoded 210 value is "e77b719d4e9c63c0b0a0333be0a4188e490b618e". 212 5. The application client sends a CERT query for 213 e77b719d4e9c63c0b0a0333be0a4188e490b618e.www.example.com. It 214 receives a response with a TLSFP certificate type. 216 6. The application uses the information in the TLSFP certificate 217 type and associates it with www.example.com. 219 The TLSRQ certificate type has a certificate body with a single octet 220 of 0. The TLSFP certificate type is TBD2. 222 For example: 224 www.example.com. IN CERT TLSRQ 0 0 AA= 226 3. Use of TLS Certificate Associations from the DNS in TLS 228 In order to use one or more TLS certificate associations obtained 229 from the DNS, an application MUST assure that the certificates were 230 obtained using DNS protected by DNSSEC. There may be other methods 231 to securely obtain certificates in DNS, but those methods are not 232 covered by this document. 234 If a certificate association contains a hash type that is not 235 understood by the TLS client, that certificate association MUST be 236 completely ignored. 238 An application that requests TLS certificate associations using the 239 method described in the previous section obtains zero or more usable 240 certificate associations. If the application receives zero usable 241 certificate associations, it process TLS in the normal fashion. 243 If a match between the certificate association(s) and the server's 244 end entity certificate in TLS is not found, the TLS client MUST abort 245 the handshake with an "access_denied" error. 247 If the TLS server authenticates itself with a self-signed 248 certificate, it SHOULD be sure that the validation preference in the 249 CERT RR is set to 1. If the TLS server administrator believes that 250 there is information in its certificate that is relevant to the TLS 251 client other than the public key (such as a extended value (EV) 252 name), it SHOULD be sure that the validation preference in the CERT 253 RR is set to 0. 255 4. IANA Considerations 257 This document requests that IANA allocates two certificate types from 258 the CERT RR certificate type registry 259 (). The types are to 260 be allocated from the 'IETF Consensus' range. 262 Decimal type: TBD1 263 Type: TLSFP 264 Meaning: TLS certificate associations 266 Decimal type: TBD2 267 Type: TLSRQ 268 Meaning: Client should request TLS certificate associations 269 retrieved using hashes 271 5. Security Considerations 273 The security of the protocols described in this document relies on 274 the security of DNSSEC as used by the client requesting A and CERT 275 records. 277 A DNS administrator who goes rogue and changes both the A and CERT 278 records for a domain name can cause the user to go to an unauthorized 279 server that will appear authorized. 281 The SHA-1 hash used in the queries after the TLSRQ certificate type 282 is only used to differentiate certificates. If there is a collision 283 between the SHA-1 hashes of two certificates used by the servers that 284 are at the host name, there is no problem because both of those 285 certificates will have the same association to the domain name. 287 6. Acknowledgements 289 Many of the ideas in this document have been discussed over many 290 years. More recently, the ideas have been discussed by the authors 291 and others in a more focused fashion. In particular, some of the 292 ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, 293 Simon Josefsson, Phill Hallam-Baker, among others. 295 7. References 297 7.1. Normative References 299 [4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 300 Security version 1.2", draft-ietf-tls-rfc4347-bis (work in 301 progress), July 2010. 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 307 Rose, "DNS Security Introduction and Requirements", 308 RFC 4033, March 2005. 310 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 311 Rose, "Resource Records for the DNS Security Extensions", 312 RFC 4034, March 2005. 314 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 315 Rose, "Protocol Modifications for the DNS Security 316 Extensions", RFC 4035, March 2005. 318 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 319 System (DNS)", RFC 4398, March 2006. 321 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 322 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 324 7.2. Informative References 326 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 327 Material in DNS", RFC 4025, March 2005. 329 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 330 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 331 January 2006. 333 Appendix A. Ideas Considered But Not Necessarily Chosen 335 This appendix will list some of the ideas that have been kicked 336 around in this space and give a few paragraphs why they weren't 337 chosen for the current version this proposal. The following is a 338 placeholder for the list that will be filled out more in future 339 versions of this document: 341 o A flag that indicates that the certificate with the associated key 342 must be signed by a trusted CA. Briefly: this was not added 343 because it is up to the TLS server to decide which type of 344 certificate it wants to serve up. Serving a self-signed 345 certificate would effectively disable traditional PKIX validation, 346 whereas serving a certificate signed by a trusted CA would require 347 both validation by DNSSEC and the trusted CA. 349 o A flag that indicates that all connections to this server need to 350 be TLS secured. Briefly: this is a good idea but it is not 351 related to the key of the certificate given in TLS, and thus 352 should be indicated in a different method. 354 o Giving keys instead of hashes of keys. Briefly: TLS requires that 355 the server gives a certificate, and some systems use the metadata 356 from a CA-signed certificate for display, so there is value to 357 always looking in the certificate. 359 o Hashes of keys vs. hashes of certificates. Briefly: we have 360 changed our minds (at least once) on this. Our original thinking 361 was that there are many reasons why someone might change their 362 certificate while leaving the public key alone, and those changes 363 should not have to force them to change the DNS record because 364 they do not actually change what the TLS client cares about; thus, 365 use hashes of keys. Our new thinking is that there are 366 certificate semantics that we want to pass (namely, should the 367 client actually do the certificate validation), and attaching 368 those semantics to keys is confusing; thus, use hashes of 369 certificates. 371 o List TLS/DTLS ports or services for which the certificate is 372 associated. Briefly: we had this in an earlier version of this 373 document but got rid of it when it was pointed out that this is an 374 edge case, and most servers differentiate these services by domain 375 names such as "mail.example.com" and "www.example.com". 377 o Different ways of encoding this information in the DNS. Briefly: 378 we considered a new RR type and coming up with an encoding of the 379 TXT RR type, but didn't see any significant advantage of them over 380 using the CERT RR, and there were disadvantages. A disadvantage 381 of a new RR type is getting DNS servers and clients to recognize 382 it; a disadvantage of coming up with a new TXT format is that 383 doing so prevents wildcards. There is a lot more to discuss here, 384 but the authors are now happy with a new sub-type for the CERT RR. 386 o Having the hash be over the TLS certificate structure instead of 387 just the end-entity certificate. Briefly: the TLS certificate 388 structure currently allows a chain of PKIX certificates, and the 389 semantics of what is being associated in a chain is not clear. 390 Further, the structure might be changed in the future (such as to 391 allow a group of web-of-trust OpenPGP certificates), and the 392 semantics of what is being associated would become even less 393 clear. 395 Appendix B. Changes between -00 and -01 397 Change the association from being a hash of the key of a PKIX 398 certificate to being a hash of a certificate (PKIX or other). This, 399 of course, makes large changes throughout the document. 401 Expanded the document to cover DTLS as well. 403 Added a pointer to the keyassure mailing list. 405 Removed the proposals for two alternate formats (the TLSFP Resource 406 Record and the TXT record encoding). Added a bit to Appendix A about 407 this. 409 Got rid of the specification for ports within a single domain name. 411 Made the hash type one octet and used the DS registry instead of 412 defining our own. 414 Added "Necessarily" chosen in the title of Appendix A to show that we 415 might (continue to) change our minds after discussion. 417 Added Simon Josefsson to the acknowledgements. 419 Appendix C. Changes between -01 and -02 421 Added the TLSRQ certificate type and its semantics. 423 Pointed to the IANA registry for DS hash types. 425 Added Phill Hallam-Baker to the acknowledgements. 427 Authors' Addresses 429 Paul Hoffman 430 VPN Consortium 432 Email: paul.hoffman@vpnc.org 434 Jakob Schlyter 435 Kirei AB 437 Email: jakob@kirei.se 439 Warren Kumari 440 Google 442 Email: warren@kumari.net 444 Adam Langley 445 Google 447 Email: agl@google.com