idnits 2.17.1 draft-hoffman-tls-keys-from-dns-00.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 4, 2010) is 5011 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 August 4, 2010 5 Expires: February 5, 2011 7 Using Secure DNS to Retrieve Keys Used for Authenticating TLS Servers 8 draft-hoffman-tls-keys-from-dns-00 10 Abstract 12 TLS requires the use of PKIX certificates for authenticating the 13 server. Some people want to obtain the public key used in this 14 authentication using other methods. This document describes how to 15 securely retrieve a TLS server's public key from the DNS. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 5, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The first response from the server in TLS [RFC5246] contains a PKIX 52 certificate. In order for the TLS client to authenticate that it is 53 talking to the expected TLS server, the client must validate that the 54 key in this certificate is associated with the domain name used by 55 the client to get to the server. To do this, the client must extract 56 the domain name from one of many places in the PKIX certificate, must 57 trust the trust anchor upon which the server's PKIX certificate is 58 rooted, and must7 perform correct PKIX validation on the certificate. 60 Some people want a different way to authenticate the server without 61 using PKIX. In order to do this, the TLS client must have a copy of 62 the TLS server's key that was received in a trusted fashion, and a 63 trusted belief that the key is associated with the domain name used 64 to reach the TLS server. This key and association can be gotten out 65 of band, but a more scalable way to get them is by using the DNS. 67 DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], 68 [RFC4034], and [RFC4035]), uses cryptographic keys and digital 69 signatures to provide authentication of DNS data. Information 70 retrieved from the DNS and that is validated using DNSSEC is thereby 71 proved to be the authoritative data. 73 This document defines a secure method to get a key usable in TLS for 74 a particular domain name using DNS protected by DNSSEC. Because the 75 key was retrieved based on a DNS query, the domain name in the query 76 is by definition associated with the key. This document also defines 77 different ways that the key can be used in TLS. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 NOTE TO READERS: THIS DOCUMENT HAS KNOWN HOLES AND ONE GLARING 84 PROBLEM, NAMELY THAT THERE ARE TWO METHODS DEFINED WHILE ONLY ONE 85 WILL BE CHOSEN LATER. 87 2. Getting TLS Keys from the DNS 89 This section describes two equivalent methods for encoding TLS keys: 90 a new RR called "TLSKEY" and a TXT record that can be emitted when 91 the query has "_TLSKEY" as the leftmost label. Only one of these 92 methods should be selected for the final protocol. When that 93 decision is made, the method not used will be removed from this 94 document. 96 2.1. The TLSKEY Resource Record 98 The new RR TLSKEY is defined here. A query on a domain name for the 99 TLSKEY type can return one or more records of the type TLSKEY. 101 The format of the TLSKEY response is binary. In the record, all 102 integers consist of two bytes in network byte order. The record, 103 which MUST be in the order defined here, is: 105 o An integer specifying how many port numbers are listed. This 106 value MUST be at least 1. 108 o An unordered set of two-byte integers specifying the TCP/UDP ports 109 for which the key is valid. To indicate that the key is valid for 110 all ports on the host associated with the domain name, a single 111 value of 0 MUST be used. 113 o An integer specifying the type of key. 115 o A variable-length set of bytes with the key. 117 [[ This will need a proper RRTYPE definiton. That will be added 118 later if this option is chosen. ]] 120 2.2. Using a TXT Resource Record with a _TLSKEY Label Prefix 122 A request for a TXT RR whose domain is the label _TLSKEY prepended to 123 a domain name can be used to get the KEY associated with the domain 124 name. A query of this can return one or more records of the type 125 TXT. 127 The format of the TXT response is ASCII text. The record, which MUST 128 be in the order defined here, is: 130 o One or more instances of "port=" followed by an TCP/UDP port for 131 which the key is valid (expressed as an integer), followd by ";". 132 To indicate that the key is valid for all ports on the host 133 associated with the domain name, a single "port=0;" MUST be used. 135 o The type of key, specified as "type=nn;" where "nn" is an integer 136 defined below. 138 o "key=" followed by the set of bytes with the key; the bytes are 139 encoded as lower-case hexadecimal. 141 2.3. Types of Keys 143 The initial list of key types is: 145 o 0 - RSA 147 o 1 - ECDSA using the P256 curve 149 o 2 - ECDSA using the P384 curve 151 o 3 - GOST 153 [[ References are neede above. ]] 155 3. Use of TLS Keys from the DNS in TLS 157 In order to use one or more TLS keys obtained from the DNS, an 158 application MUST assure that the keys were obtained using DNS 159 protected by DNSSEC. There may be other methods to securely obtain 160 keys in DNS, but those methods are not covered by this document. 162 An application that requests TLS keys using the method described in 163 the previous section obtain zero or more keys. If the application 164 receives zero keys, it process TLS in the normal fashion. 166 The application ignores the PKIX certificate received from the server 167 and instead uses the key obtained from the DNS. That is, the client 168 does no processing on the PKIX certificate in the TLS Certificate 169 message. The application instead uses the key as the authenticator. 171 If the application receives more than one key from the DNS query, it 172 tries each key for which it understands while authenticating the TLS 173 server. 175 4. IANA Considerations 177 [[ TBD. Will include the registration for the TLSKEY RR if that is 178 the style chosen, as well as a new registry for key types. ]] 180 5. Security Considerations 182 [[ TBD. This section will need to describe, at least, the "attack" 183 where a DNS administrator goes rogue and changes both the A and 184 TLSKEY records for a domain name. ]] 186 6. Normative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 192 Rose, "DNS Security Introduction and Requirements", 193 RFC 4033, March 2005. 195 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 196 Rose, "Resource Records for the DNS Security Extensions", 197 RFC 4034, March 2005. 199 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 200 Rose, "Protocol Modifications for the DNS Security 201 Extensions", RFC 4035, March 2005. 203 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 204 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 206 Author's Address 208 Paul Hoffman 209 VPN Consortium 211 Email: paul.hoffman@vpnc.org