idnits 2.17.1 draft-ietf-dane-rawkeys-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 (July 3, 2014) is 3582 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: 'RFC 5280' is mentioned on line 73, but not defined == Unused Reference: 'RFC4033' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 264, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Gilmore 3 DANE Working Group Electronic Frontier Foundation 4 Intended status: Proposed Standard July 3, 2014 5 Expires: December 31, 2014 6 Updates: 6698 (if approved) 8 Authenticating Raw Public Keys with DANE TLSA 9 draft-ietf-dane-rawkeys-00 11 Abstract 13 This document standardizes how the Domain Name System can 14 authenticate Raw Public Keys. Transport Level Security now has the 15 option to use Raw Public Keys, but they require some form of external 16 authentication. The document updates RFC 6698 to allow the Domain 17 Name System to standardize the authentication of more types of keying 18 material. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1 Background and Introduction 58 The Internet uses many kinds of encryption, and many kinds of keying 59 material. These keys are authenticated in an attempt to prove that 60 the public keys used in communication are the correct keys needed to 61 interact with a particular server or client across the Internet. 63 The Domain Name System (DNS) [RFC1034, RFC1035] provides a globally 64 distributed database for brief information about names used in the 65 Internet. The DNS Security Extensions (DNSSEC) [RFC4033, RFC4034, 66 RFC4035] provide authentication for this database, proving whether 67 the information in the DNS was truly published by the owner of the 68 associated domain name. 70 Transport Level Security (TLS) [RFC5246] and Datagram TLS (DTLS) 71 [RFC6347] define a protocol that protects an Internet datastream or a 72 series of datagrams from eavesdropping and modification. They 73 initially used certificates in PKIX [RFC 5280] formats to store their 74 keying material, and authenticated them via a series of trust anchors 75 embedded in client applications. 77 Domain name system Authentication of Named Entities (DANE) provides a 78 way to store application level public keys in the DNS and 79 authenticate them using DNSSEC. The DANE TLS Authentication (TLSA) 80 resource record [RFC6698] initially provided authentication for the 81 PKIX certificates used in TLS and DTLS. 83 1.1 Summary of Changes 85 This document extends TLSA records to be able to authenticate more 86 kinds of keying material than PKIX certificates. Protocols can then 87 use their keying material with DANE by standardizing new forms of 88 TLSA records. 90 As a first example of such a new form, this document extends DANE to 91 provide authentication for Raw Public Keys. Raw Public Keys are used 92 in place of PKIX certificates in an extension to TLS and DTLS 93 [RFC7250]. Client applications using Raw Public Keys with TLS or 94 DTLS can use DNSSEC to prove whether those public keys were truly 95 published by the owner of the domain name whose server they are 96 accessing. 98 1.2 Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2 Extending TLSA records to support non-PKIX keying material 106 This document relaxes the restriction that TLSA records can only 107 authenticate PKIX certificates (RFC 6698, section 1.3). The DANE 108 protocol and TLSA records can now apply to encryption keying material 109 in general. This protocol and record type continue to apply to PKIX 110 [RFC5280] certificates, but new standards are free to define non-PKIX 111 keying material formats. 113 Wherever the term "certificate" is used in RFC 6698 to refer to 114 fields in the TLSA record, this document extends it to refer more 115 generally to "keying material". Thus the "certificate usage" field 116 can be thought of as a "keying material usage" field, the 117 "certificate association data" can now be used as "keying material 118 association data", etc. 120 In addition, this document relaxes the requirement that certificate 121 usage value 3 can only be used for PKIX format certificates (RFC 122 6698, section 2.1.1). Certificate usage 3 can now be used with any 123 standardized keying material format. Certificate usages 0, 1 and 2 124 remain restricted to apply only to PKIX-formatted certificates in DER 125 encoding [X.690]. 127 3 Supporting Raw Public Keys in TLSA records 129 This document extends the DANE TLSA record definition to allow TLSA 130 records to describe raw public keys as well as PKIX certificates. 131 This extension does not define any new field values; it merely 132 defines how existing fields are processed when being used with raw 133 public keys, such as those provided by TLS and DTLS servers. 135 There are two different ways to use raw public keys in TLSA records. 136 One is to store the public key itself, so that it can be accessed 137 directly from the DNS. The second is to store a hash of the public 138 key, so that a public key obtained in some other way can be 139 authenticated via the DNS. These cases are distinguished by the 140 matching type field in the TLSA record. 142 When a raw public key is to be stored in a TLSA record, the record 143 MUST specify a certificate usage / keying material usage of 3 144 (domain-provided), a selector of 1 (SubjectPublicKeyInfo), and a 145 matching type of 0. The SubjectPublicKeyInfo structure that holds 146 the public key is placed in the certificate association / keying 147 material association data field. 149 This SubjectPublicKeyInfo structure MUST be encoded in DER encoding 150 [X.660] of Abstract Syntax Notation One (ASN.1) [X.208]. It is 151 identical to the SubjectPublicKeyInfo structure that is described in 152 RFC 3279 [RFC3279], which is a used as a component of PKIX 153 certificates. It is identical to the SubjectPublicKeyInfo structure 154 that is used in TLSA records that use a selector value of 1 and a 155 matching type of 0 to match PKIX certificates. It contains an 156 algorithm identifier, any optional parameters needed with that 157 algorithm identifier, and the public key itself. 159 When a raw public key (that was obtained in some other way, such as 160 in a TLS or DTLS transaction) is to be merely matched by a TLSA 161 record, matching type 0 MAY be used, or matching types other than 0 162 MAY also be used, by placing the hash value of the 163 SubjectPublicKeyInfo structure into the certificate association / 164 keying material association data. 166 This document extends the meaning of the certificate usage / keying 167 material usage value of 3 (from RFC 6699 section 2.1.1) by defining 168 how the TLSA record is used by a client communicating with a TLS or 169 DTLS server that uses raw public keys. This extension adds to, 170 rather than replacing, the definition of certificate usage 3 with TLS 171 or DTLS servers that use PKIX certificates. 173 3 -- Keying material usage 3 is also used to specify a raw public 174 key that MUST match the raw public key presented by the server in 175 TLS or DTLS. When the server provides a raw public key, there is 176 no PKIX certificate and no PKIX validation is done. The server's 177 raw public key MUST match the raw public key provided in the TLSA 178 record. This keying material usage is sometimes referred to as 179 "domain-issued" because it allows a domain administrator to 180 directly certify a domain's public keys. 182 4 Security Considerations 184 The encoding used in the TLSA resource record for Raw Public Keys is 185 identical to the encoding used to match the public key of a PKIX 186 certificate. This allows a single TLSA record to match both a PKIX 187 certificate used in traditional TLS or DTLS, and to also match a Raw 188 Public Key provided in extended TLS or DTLS. This offers TLS or DTLS 189 servers an easy way to interoperate with both traditional and 190 extended clients. They can use the same public and private key when 191 communicating with either extended or traditional clients. 193 Since TLSA records use a protocol type and port number as a prefix on 194 the domain name, services that use Raw Public Keys on various ports 195 accessed through the same domain name are free to use different 196 keying material. Using diverse keying material for different 197 services can improve the robustness of the services after a key 198 compromise. For example, email service on port 25 can continue with 199 full security, even after the private key protecting HTTPS service on 200 port 443 has been compromised. This is a tighter binding between 201 public keys and services than that provided by PKIX certificates, 202 which do not distinguish port numbers. When PKIX certificates are 203 authenticated with TLSA usages 0, 1, or 2, a PKIX certificate that 204 was originally used with HTTPS could be used for a man-in-the-middle 205 attack on email service as well, after its corresponding private key 206 has been compromised. This cross-port attack does not work when the 207 domain name uses TLSA usage 3 to authenticate different Raw Public 208 Keys (or PKIX certificates) for the different services on different 209 ports. 211 In the TLS and DTLS protocol, certificate types are often negotiated 212 before the relevant TLSA records are available to the client. Server 213 operators who anticipate using TLSA records to authenticate the 214 server should always ensure that if their server offers support for 215 Raw Public Keys, then their server's domain name(s) SHOULD contain 216 TLSA records that match the public key that the server offers. 217 Failure to publish such TLSA records would otherwise lead to an 218 authentication failure in clients that opt to use Raw Public Keys, 219 even if TLSA records exist that authenticate PKIX certificates with 220 usages 0, 1, or 2. This is not an issue when Raw Public Keys are 221 used with out-of-band non-DANE authentication. 223 When using Raw Public Keys and TLSA records, the security of the 224 domain name system records directly affects the security of the 225 communications protected by TLS or DTLS. If the domain's DNS records 226 are compromised, or the DNS records that delegate name service to 227 this domain are compromised, communications can be blocked, 228 redirected, intercepted, or modified. The DANE TLSA Security 229 Considerations section [RFC6698] provides further details. 231 5 IANA Considerations 233 In the IANA "TLSA Certificate Usages" registry created by Section 7.2 234 of RFC 6698, the value "3" ("Domain-issued certificate") should have 235 its short description changed to "Domain-issued keying material", and 236 should have this document added as a reference document. 238 6 References 240 6.1 Normative References 242 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 243 STD 13, RFC 1034, November 1987. 245 [RFC1035] Mockapetris, P., "Domain names - implementation and 246 specification", STD 13, RFC 1035, November 1987. 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 [RFC3279] Polk, T., Housley, R., Bassham, L, "Algorithms and 252 Identifiers for the Internet X.509 Public Key 253 Infrastructure Certificate and Certificate Revocation List 254 (CRL) Profile", RFC 3279, April 2002. 256 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 257 Rose, "DNS Security Introduction and Requirements", RFC 258 4033, March 2005. 260 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 261 Rose, "Resource Records for the DNS Security Extensions", 262 RFC 4034, March 2005. 264 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 265 Rose, "Protocol Modifications for the DNS Security 266 Extensions", RFC 4035, March 2005. 268 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 269 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 271 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 272 Security Version 1.2", RFC 6347, January 2012. 274 [RFC6698] Hoffman, P., Schylter, J., "The DNS-Based Authentication 275 of Named Entities (DANE) Transport Layer Security (TLS) 276 Protocol: TLSA", RFC 6698, August 2012. 278 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., 279 Kivinen, T., "Using Raw Public Keys in Transport Layer 280 Security (TLS) and Datagram Transport Layer Security 281 (DTLS)", RFC 7250, May 2014 283 [X.208] CCITT Recommendation X.208: Specification of Abstract Syntax 284 Notation One (ASN.1), 1988. 286 [X.690] "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, 287 Information technology - ASN.1 encoding rules: 288 Specification of Basic Encoding Rules (BER), Canonical 289 Encoding Rules (CER) and Distinguished Encoding Rules 290 (DER)", July 2002. 292 6.2 Informative References 294 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 295 Housley, R., and W. Polk, "Internet X.509 Public Key 296 Infrastructure Certificate and Certificate Revocation List 297 (CRL) Profile", RFC 5280, May 2008. 299 Authors' Addresses 301 John Gilmore 302 Electronic Frontier Foundation 303 815 Eddy Street 304 San Francisco, CA 94117 305 United States 307 EMail: gnu@ietf.toad.com