idnits 2.17.1 draft-ietf-dane-protocol-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 (January 25, 2011) is 4837 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 341, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: July 29, 2011 Kirei AB 6 January 25, 2011 8 Using Secure DNS to Associate Certificates with Domain Names For TLS 9 draft-ietf-dane-protocol-03 11 Abstract 13 TLS and DTLS use certificates for authenticating the server. Users 14 want their applications to verify that the certificate provided by 15 the TLS server is in fact associated with the domain name they 16 expect. Instead of trusting a certification authority to have made 17 this association correctly, the user might instead trust the 18 authoritative DNS server for the domain name to make that 19 association. This document describes how to use secure DNS to 20 associate the TLS server's certificate with the the intended domain 21 name. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 29, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 The first response from the server in TLS may contain a certificate. 58 In order for the TLS client to authenticate that it is talking to the 59 expected TLS server, the client must validate that this certificate 60 is associated with the domain name used by the client to get to the 61 server. Currently, the client must extract the domain name from the 62 certificate, must trust a trust anchor upon which the server's 63 certificate is rooted, and must successfully validate the 64 certificate. 66 Some people want a different way to authenticate the association of 67 the server's certificate with the intended domain name without 68 trusting the CA. Given that the DNS administrator for a domain name 69 is authorized to give identifying information about the zone, it 70 makes sense to allow that administrator to also make an authoritative 71 binding between the domain name and a certificate that might be used 72 by a host at that domain name. The easiest way to do this is to use 73 the DNS. 75 This document applies to both TLS [RFC5246] and DTLS [4347bis]. In 76 order to make the document more readable, it mostly only talks about 77 "TLS", but in all cases, it means "TLS or DTLS". This document only 78 relates to securely associating certificates for TLS and DTLS with 79 host names; other security protocols are handled in other documents. 80 For example, keys for IPsec are covered in [RFC4025] and keys for SSH 81 are covered in [RFC4255]. 83 1.1. Certificate Associations 85 In this document, a certificate association is based on a 86 cryptographic hash of a certificate (sometimes called a 87 "fingerprint") or on the certificate itself. For a fingerprint, a 88 hash is taken of the binary, DER-encoded certificate, and that hash 89 is the certificate association; the type of hash function used can be 90 chosen by the DNS administrator. When using the certificate itself 91 in the certificate association, the entire certificate in the normal 92 format is used. This document also only applies to PKIX [RFC5280] 93 certificates. 95 Certificate associations are made between a certificate or the hash 96 of a certificate and a domain name. Server software that is running 97 TLS that is found at that domain name would use a certificate that 98 has a certificate association given in the DNS, as described in this 99 document. A DNS query can return multiple certificate associations, 100 such as in the case of different server software on a single host 101 using different certificates (even if they are normally accessed with 102 different host names), or in the case that a server is changing from 103 one certificate to another. 105 1.2. Securing Certificate Associations 107 This document defines a secure method to associate the certificate 108 that is obtained from the TLS server with a domain name using DNS 109 protected by DNSSEC. Because the certificate association was 110 retrieved based on a DNS query, the domain name in the query is by 111 definition associated with the certificate. 113 DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], 114 [RFC4034], and [RFC4035]), uses cryptographic keys and digital 115 signatures to provide authentication of DNS data. Information 116 retrieved from the DNS and that is validated using DNSSEC is thereby 117 proved to be the authoritative data. The DNSSEC signature MUST be 118 validated on all responses in order to assure the proof of origin of 119 the data. 121 This document only relates to securely getting the DNS information 122 for the certificate association using DNSSEC; other secure DNS 123 mechanisms are out of scope. 125 1.3. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 A note on terminology: Some people have said that this protocol is a 132 form of "certificate exclusion". This is true, but in a very unusual 133 sense. That is, a DNS reply that contains two of the certificate 134 types defined here inherently excludes every other possible 135 certificate in the universe other than those found with a pre-image 136 attack against one of those two. The certificate type defined here 137 is better thought of as "enumeration" of a small number of 138 certificate associations, not "exclusion" of a near-infinite number 139 of other certificates. 141 Some of the terminology in this draft may not match with the 142 terminology used in RFC 5280. This will be fixed in future versions 143 of this draft, with help from the PKIX community. In specific, we 144 need to say (in a PKIX-appropriate way) that when we say "valid up 145 to" and "chains to", full RFC 5280 path processing including 146 revocation status checking is intended. 148 2. Getting TLS Certificate Associations from the DNS 150 This document defines a new DNS resource record type, "TLSA". A 151 query on a domain name for the TLSA RR can return one or more records 152 of the type TLSA. The TLSA RRType is TBD. 154 The format of the data in the resource record is a binary record with 155 three values, which MUST be in the order defined here: 157 o A one-octet value, called "certificate type", specifying the 158 provided association that will be used to match the target 159 certificate. This will be an IANA registry in order to make it 160 easier to add additional certificate types in the future. The 161 types defined in this document are: 163 1 -- Hash of an end-entity certificate 165 2 -- Full end-entity certificate in DER encoding 167 3 -- Hash of an certification authority's certificate 169 4 -- Full certification authority's certificate in DER encoding 171 o A one-octet value, called "hash type", specifying the type of hash 172 algorithm used for the certificate association. This value is 173 defined in a new IANA registry. When no hashing is used (that is, 174 in the certificate types where the full certificate is given), the 175 hash type MUST be 0. Using the same hash algorithm as is used in 176 the signature in the certificate will make it more likely that the 177 TLS client will understand this TLSA data. 179 o The "certificate for association". This is the bytes containing 180 the certificate or the hash of the associated certificate (that 181 is, the certificate or the hash of the certificate itself, not of 182 the TLS ASN.1Cert object). 184 Certificate types 1 through 4 explicitly only apply to PKIX-formatted 185 certificates. If TLS allows other formats later, or if extensions to 186 this protocol are made that accept other formats for certificates, 187 those certificates will need certificate types. 189 2.1. Making Certificate Associations 191 Items received in TLSA resource records can be treated like trust 192 anchors by the TLS client. The trust anchor MUST NOT be loaded for 193 longer than the TTL on the TSLA record. 195 The TLS client determines whether or not the certificate offered by 196 the TLS server matches the certificate association in the TLSA 197 resource record. If the certificate from the TLS server matches, the 198 TLS client accepts the certificate association. Each certificate 199 type has a different method for determining matching. 201 For types 1 and 3, the hash used in the comparison is the hash type 202 from the TLSA data. 204 Types 1 (hash of an end-entity certificate) and 2 (full end-entity 205 certificate) are matched against the first certificate offered by the 206 TLS server. With these two types, the trust anchor is used only for 207 exact matching, not for chained validation. For type 1, the 208 certificate association is valid if the hash of the first certificate 209 offered by the TLS server matches the value from the resource record. 210 For type 2, the certificate association is valid if the certificate 211 in the TLSA data matches to the first certificate offered by TLS. 213 Type 3 (hash of certification authority's certificate) can be used in 214 one of two ways. If the hash of any certificate past the first in 215 the certificate bundle from TLS matches the trust anchor from the 216 TLSA data, and the chain in the certificate bundle is valid up to 217 that TLSA trust anchor, then the certificate association is valid. 218 Alternately, if the first certificate offered chains to an existing 219 trust anchor in the TLS client's trust anchor repositor, and the hash 220 of that trust anchor matches the value from the TLSA data, then the 221 certificate association is valid. 223 Type 4 (full certification authority's certificate) is used in 224 chaining from the end-entity given in TLS. The certificate 225 association is valid if the first certificate in the certificate 226 bundle can be validly chained to the trust anchor from the TLSA data. 228 [[ Need discussion of self-signed certificates being CA certificates. 229 Need to be sure that this discussion uses correct PKIX terminology 230 and is carefully explained. ]] 232 2.2. Presentation Format 234 The RDATA of the presentation format of the TLSA resource record 235 consists of two numbers (certificate and hash type) followed by the 236 bytes containing the certificate or the hash of the associated 237 certificate itself, presented in hex. An example of a SHA-256 hash 238 (type 2) of an end-entity certificate (type 1) would be: 240 www.example.com. IN TLSA ( 241 1 2 5c1502a6549c423be0a0aa9d9a16904de5ef0f5c98 242 c735fcca79f09230aa7141 ) 244 An example of an unhashed (type 0) CA certificate (type 4) would be: 246 www.example.com. IN TLSA ( 247 4 0 308202c5308201ada00302010202090... ) 249 Because the length of hashes and certificates can be quite long, 250 presentation format explicitly allows line breaks and white space in 251 the hex values; those characters are removed when converting to the 252 wire format. 254 2.3. Wire Format 256 The wire format is: 258 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Cert type | Hash type | / 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 263 / / 264 / Certificate for association / 265 / / 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 The wire format for the RDATA in the first example given above would 269 be: 271 www.example.com. IN TYPE65534 \# 34 ( 01025c1502a6549c423be0a0aa 272 9d9a16904de5ef0f5c98c735fcca79f09230aa7141 ) 274 The wire format for the RDATA in the second example given above would 275 be: 277 www.example.com. IN TYPE65534 \# 715 0400308202c5308201ada003020... 279 3. Use of TLS Certificate Associations in TLS 281 In order to use one or more TLS certificate associations described in 282 this document obtained from the DNS, an application MUST assure that 283 the certificates were obtained using DNS protected by DNSSEC. TLSA 284 records must only be trusted if they were obtained from a trusted 285 source. This could be a localhost DNS resolver answer with the AD 286 bit set, an inline validating resolver library primed with the proper 287 trust anchors, or obtained from a remote nameserver to which one has 288 a secured channel of communication. 290 If a certificate association contains a hash type that is not 291 understood by the TLS client, that certificate association MUST be 292 marked as unusable. 294 An application that requests TLS certificate associations using the 295 method described in this document obtains zero or more usable 296 certificate associations. If the application receives zero usable 297 certificate associations, it processes TLS in the normal fashion. 299 If a match between one of the certificate association(s) and the 300 server's end entity certificate in TLS is found, the TLS client 301 continues the TLS handshake. If a match between the certificate 302 association(s) and the server's end entity certificate in TLS is not 303 found, the TLS client MUST abort the handshake with an 304 "access_denied" error. 306 4. IANA Considerations 308 4.1. TLSA RRtype 310 This document uses a new DNS RRType, TLSA, whose value is TBD. A 311 separate request for the RRType will be submitted to the expert 312 reviewer, and future versions of this document will have that value 313 instead of TBD. 315 4.2. TLSA Certificate Types 317 This document creates a new registry, "Certificate Types for TLSA 318 Resource Records". The registry policy is "RFC Required". The 319 initial entries in the registry are: 321 Value Short description Ref. 322 ------------------------------------------------------------- 323 0 Reserved [This] 324 1 Hash of an end-entity cert [This] 325 2 Full end-entity cert in DER encoding [This] 326 3 Hash of an CA's cert [This] 327 4 Full CA's cert in DER encoding [This] 328 5-254 Unassigned 330 Applications to the registry can request specific values that have 331 yet to be assigned. 333 4.3. TLSA Hash Types 335 This document creates a new registry, "Hash Types for TLSA Resource 336 Records". The registry policy is "Specification Required". The 337 initial entries in the registry are: 339 Value Short description Ref. 340 ----------------------------------------------------- 341 0 No hash used [This] 342 1 SHA-1 NIST FIPS 180-2 343 2 SHA-256 NIST FIPS 180-2 344 3 SHA-384 NIST FIPS 180-2 345 4-254 Unassigned 347 Applications to the registry can request specific values that have 348 yet to be assigned. 350 5. Security Considerations 352 The security of the protocols described in this document relies on 353 the security of DNSSEC as used by the client requesting A and TLSA 354 records. 356 A DNS administrator who goes rogue and changes both the A and TLSA 357 records for a domain name can cause the user to go to an unauthorized 358 server that will appear authorized, unless the client performs 359 certificate validation and rejects the certificate. That 360 administrator could probably get a certificate issued anyway, so this 361 is not an additional threat. 363 The values in the TLSA data will be normally entered in the DNS 364 through the same system used to enter A/AAAA records, and other DNS 365 information for the host name. If the authentication for changes to 366 the host information is weak, an attacker can easily change any of 367 this information. Given that the TLSA data is not easily human- 368 readable, an attacker might change those records and A/AAAA records 369 and not have the change be noticed if changes to a zone are only 370 monitored visually. 372 If the authentication mechanism for adding or changing TLSA data in a 373 zone is weaker than the authentication mechanism for changing the 374 A/AAAA records, a man-in-the-middle who can redirect traffic to their 375 site may be able to impersonate the attacked host in TLS if they can 376 use the weaker authentication mechanism. A better design for 377 authenticating DNS would be to have the same level of authentication 378 used for all DNS additions and changes for a particular host. 380 [[ Add discussion of the idea that TLSA makes things worse if an 381 intermediate CA is compromised. Need more from Stephen Farrell. ]] 383 6. Acknowledgements 385 Many of the ideas in this document have been discussed over many 386 years. More recently, the ideas have been discussed by the authors 387 and others in a more focused fashion. In particular, some of the 388 ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, 389 Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, 390 Ilari Liusvaara, and Ondrej Sury. 392 7. References 394 7.1. Normative References 396 [4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 397 Security version 1.2", draft-ietf-tls-rfc4347-bis (work in 398 progress), July 2010. 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 404 Rose, "DNS Security Introduction and Requirements", 405 RFC 4033, March 2005. 407 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 408 Rose, "Resource Records for the DNS Security Extensions", 409 RFC 4034, March 2005. 411 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 412 Rose, "Protocol Modifications for the DNS Security 413 Extensions", RFC 4035, March 2005. 415 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 416 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 418 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 419 Housley, R., and W. Polk, "Internet X.509 Public Key 420 Infrastructure Certificate and Certificate Revocation List 421 (CRL) Profile", RFC 5280, May 2008. 423 7.2. Informative References 425 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 426 Material in DNS", RFC 4025, March 2005. 428 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 429 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 430 January 2006. 432 Authors' Addresses 434 Paul Hoffman 435 VPN Consortium 437 Email: paul.hoffman@vpnc.org 439 Jakob Schlyter 440 Kirei AB 442 Email: jakob@kirei.se