idnits 2.17.1 draft-hoffman-keys-linkage-from-dns-01.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 (August 24, 2010) is 4966 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: February 25, 2011 Kirei AB 6 W. Kumari 7 A. Langley 8 Google 9 August 24, 2010 11 Using Secure DNS to Associate Certificates with Domain Names For TLS 12 draft-hoffman-keys-linkage-from-dns-01 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 February 25, 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 This section describes the TLSFP Certificate Type of the CERT RR. 119 The CERT RR [RFC4398] allows expansion by defining new certificate 120 types. The new TLSFP certificate type is defined here. A query on a 121 domain name for the CERT RR can return one or more records of the 122 type CERT, and zero or more of those CERT responses can be of type 123 TLSFP. 125 o The TLSFP certificate type is TBD. 127 o The key tag and algorithm fields are both set to zero. 129 The format of the TLSFP certificate is a binary record, which MUST be 130 in the order defined here, is: 132 o A one-octet value, called "hash type", specifying the type of hash 133 algorithm used for the certificate association. This value has 134 the same values as those of the DS RR, as defined in [RFC4034] and 135 its successors. 137 o A one-octet value, called "validation preference", specifying the 138 preferences for further validation of the certificate in TLS. A 139 certificate association that contains a validation preference 140 whose value is 1 indicates that the TLS administrator believes 141 that it is sufficient to match the certificate association with 142 the hash of certificate received in the TLS negotiation, and that 143 no further certificate validation is necessary. A certificate 144 association that contains a validation preference whose value is 0 145 indicates that the TLS administrator believes that it is not 146 sufficient to match the certificate association with the hash of 147 certificate received in the TLS negotiation, and that normal 148 certificate validation is necessary. Note that the validation 149 preference is an advisory, and it is not mandatory for a TLS 150 client to follow the advice. 152 o A variable-length set of bytes containing the hash of the 153 associated certificate. 155 For example: 157 www.example.com. IN CERT TLSFP 0 0 ( AQGa+FZd8sAeS03ca8xDigDQ 158 ePgJnQvgMe/kKyf8rzluiQ== ) 160 3. Use of TLS Certificate Associations from the DNS in TLS 162 In order to use one or more TLS certificate associations obtained 163 from the DNS, an application MUST assure that the certificates were 164 obtained using DNS protected by DNSSEC. There may be other methods 165 to securely obtain certificates in DNS, but those methods are not 166 covered by this document. 168 An application that requests TLS certificate associations using the 169 method described in the previous section obtains zero or more 170 certificate associations. If the application receives zero 171 certificate associations, it process TLS in the normal fashion. 173 If a certificate association contains a hash type that is not 174 understood by the TLS client, that certificate association MUST be 175 completely ignored. 177 If a match between the certificate association(s) and the server's 178 end entity certificate in TLS is not found, the TLS client MUST abort 179 the handshake with an "access_denied" error. 181 If the TLS server authenticates itself with a self-signed 182 certificate, it SHOULD be sure that the validation preference in the 183 CERT RR is set to 1. If the TLS server administrator believes that 184 there is information in its certificate that is relevant to the TLS 185 client other than the public key (such as a extended value (EV) 186 name), it SHOULD be sure that the validation preference in the CERT 187 RR is set to 0. 189 4. IANA Considerations 191 This document requests that IANA allocates one certificate type from 192 the CERT RR certificate type registry. The type is to be allocated 193 from the 'IETF Consensus' range. 195 Decimal type: TBD 197 Type: TLSFP 199 Meaning: TLS Certificate Associations 201 5. Security Considerations 203 [[ TBD. This section will need to describe, at least, the "attack" 204 where a DNS administrator goes rogue and changes both the A and CERT 205 records for a domain name. Also will discuss the need for secure 206 DNS. ]] 208 6. Acknowledgements 210 Many of the ideas in this document have been discussed over many 211 years. More recently, the ideas have been discussed by the authors 212 and others in a more focused fashion. In particular, some of the 213 ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, 214 Simon Josefsson, among others. 216 7. References 218 7.1. Normative References 220 [4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 221 Security version 1.2", draft-ietf-tls-rfc4347-bis (work in 222 progress), July 2010. 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 228 Rose, "DNS Security Introduction and Requirements", 229 RFC 4033, March 2005. 231 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 232 Rose, "Resource Records for the DNS Security Extensions", 233 RFC 4034, March 2005. 235 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 236 Rose, "Protocol Modifications for the DNS Security 237 Extensions", RFC 4035, March 2005. 239 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 240 System (DNS)", RFC 4398, March 2006. 242 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 243 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 245 7.2. Informative References 247 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 248 Material in DNS", RFC 4025, March 2005. 250 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 251 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 252 January 2006. 254 Appendix A. Ideas Considered But Not Necessarily Chosen 256 This appendix will list some of the ideas that have been kicked 257 around in this space and give a few paragraphs why they weren't 258 chosen for the current version this proposal. The following is a 259 placeholder for the list that will be filled out more in future 260 versions of this document: 262 o A flag that indicates that the certificate with the associated key 263 must be signed by a trusted CA. Briefly: this was not added 264 because it is up to the TLS server to decide which type of 265 certificate it wants to serve up. Serving a self-signed 266 certificate would effectively disable traditional PKIX validation, 267 whereas serving a certificate signed by a trusted CA would require 268 both validation by DNSSEC and the trusted CA. 270 o A flag that indicates that all connections to this server need to 271 be TLS secured. Briefly: this is a good idea but it is not 272 related to the key of the certificate given in TLS, and thus 273 should be indicated in a different method. 275 o Giving keys instead of hashes of keys. Briefly: TLS requires that 276 the server gives a certificate, and some systems use the metadata 277 from a CA-signed certificate for display, so there is value to 278 always looking in the certificate. 280 o Hashes of keys vs. hashes of certificates. Briefly: we have 281 changed our minds (at least once) on this. Our original thinking 282 was that there are many reasons why someone might change their 283 certificate while leaving the public key alone, and those changes 284 should not have to force them to change the DNS record because 285 they do not actually change what the TLS client cares about; thus, 286 use hashes of keys. Our new thinking is that there are 287 certificate semantics that we want to pass (namely, should the 288 client actually do the certificate validation), and attaching 289 those semantics to keys is confusing; thus, use hashes of 290 certificates. 292 o List TLS/DTLS ports or services for which the certificate is 293 associated. Briefly: we had this in an earlier version of this 294 document but got rid of it when it was pointed out that this is an 295 edge case, and most servers differentiate these services by domain 296 names such as "mail.example.com" and "www.example.com". 298 o Different ways of encoding this information in the DNS. Briefly: 299 we considered a new RR type and coming up with an encoding of the 300 TXT RR type, but didn't see any significant advantage of them over 301 using the CERT RR, and there were disadvantages. A disadvantage 302 of a new RR type is getting DNS servers and clients to recognize 303 it; a disadvantage of coming up with a new TXT format is that 304 doing so prevents wildcards. There is a lot more to discuss here, 305 but the authors are now happy with a new sub-type for the CERT RR. 307 o Having the hash be over the TLS certificate structure instead of 308 just the end-entity certificate. Briefly: the TLS certificate 309 structure currently allows a chain of PKIX certificates, and the 310 semantics of what is being associated in a chain is not clear. 311 Further, the structure might be changed in the future (such as to 312 allow a group of web-of-trust OpenPGP certificates), and the 313 semantics of what is being associated would become even less 314 clear. 316 Appendix B. Changes between -00 and -01 318 Change the association from being a hash of the key of a PKIX 319 certificate to being a hash of a certificate (PKIX or other). This, 320 of course, makes large changes throughout the document. 322 Expanded the document to cover DTLS as well. 324 Added a pointer to the keyassure mailing list. 326 Removed the proposals for two alternate formats (the TLSFP Resource 327 Record and the TXT record encoding). Added a bit to Appendix A about 328 this. 330 Got rid of the specification for ports within a single domain name. 332 Made the hash type one octet and used the DS registry instead of 333 defining our own. 335 Added "Necessarily" chosen in the title of Appendix A to show that we 336 might (continue to) change our minds after discussion. 338 Added Simon Josefsson to the acknowledgements. 340 Authors' Addresses 342 Paul Hoffman 343 VPN Consortium 345 Email: paul.hoffman@vpnc.org 347 Jakob Schlyter 348 Kirei AB 350 Email: jakob@kirei.se 352 Warren Kumari 353 Google 355 Email: warren@kumari.net 357 Adam Langley 358 Google 360 Email: agl@google.com