idnits 2.17.1 draft-hallambaker-certhash-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 == Line 194 has weird spacing: '... Type is se...' == Line 198 has weird spacing: '...gorithm cont...' == Line 200 has weird spacing: '...te data conta...' == Line 216 has weird spacing: '... Type is se...' == Line 220 has weird spacing: '...gorithm cont...' == (1 more instance...) -- The document date (September 10, 2010) is 4977 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'This' is mentioned on line 388, but not defined == Unused Reference: 'RFC4033' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC4025' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC4255' is defined on line 422, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Inc. 4 Intended status: Informational September 10, 2010 5 Expires: March 14, 2011 7 Use of DNS CERT Records for Key Assurance 8 draft-hallambaker-certhash-00 10 Abstract 12 Deployment of DNSSEC opens up the possibility of new mechanisms for 13 assuring application keys. This document extends the use of the DNS 14 CERT resource record and defines X.509v3 extensuions to support key 15 assurance mechanisms for use with TLS and other X.509 protocols and 16 provides a comprehensive assessment of the security thus achieved. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, except to format it 23 for publication as an RFC or to translate it into languages other 24 than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 14, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.2. DNS CERT Resource Record . . . . . . . . . . . . . . . 4 60 2.2. Public Key Infrastructure . . . . . . . . . . . . . . . . 4 61 2.2.1. Public Key Infrastructure X.509 . . . . . . . . . . . 4 62 2.3. Public Key Security Protocols . . . . . . . . . . . . . . 4 63 2.3.1. Transport Layer Security . . . . . . . . . . . . . . . 4 64 2.3.2. IP Security . . . . . . . . . . . . . . . . . . . . . 4 65 2.3.3. Use in Applications . . . . . . . . . . . . . . . . . 4 66 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. CERT Resource Record Parameters . . . . . . . . . . . . . 4 68 3.1.1. DPKIX . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.2. DPTR . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. X.509v3 Extension . . . . . . . . . . . . . . . . . . . . 7 71 3.3. Processing Rules . . . . . . . . . . . . . . . . . . . . . 7 72 3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.3.2. Transport layer Security . . . . . . . . . . . . . . . 7 74 3.3.3. Service Discovery (SRV, NAPTR) . . . . . . . . . . . . 7 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 4.1. Trust Chain Assurance . . . . . . . . . . . . . . . . . . 8 77 4.1.1. Root of Trust . . . . . . . . . . . . . . . . . . . . 8 78 4.1.2. Non Repudiation . . . . . . . . . . . . . . . . . . . 8 79 4.1.3. Key Revocation . . . . . . . . . . . . . . . . . . . . 8 80 4.2. DNSSEC Operations . . . . . . . . . . . . . . . . . . . . 8 81 4.2.1. Signature Time To Live . . . . . . . . . . . . . . . . 8 82 4.2.2. Zone Signing Key Compromise . . . . . . . . . . . . . 8 83 4.2.3. Key Signing Key Compromise . . . . . . . . . . . . . . 8 84 4.3. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.3.1. Suppressed DNSSEC records . . . . . . . . . . . . . . 8 86 4.3.2. Replay Attack of DNSSEC records . . . . . . . . . . . 8 87 4.3.3. Zone Hijack . . . . . . . . . . . . . . . . . . . . . 8 88 4.3.4. Disclosure of End Entity Key . . . . . . . . . . . . . 8 89 4.3.5. Disclosure of DNSSEC Key . . . . . . . . . . . . . . . 8 90 4.3.6. Malicious Domain Name Holder . . . . . . . . . . . . . 8 91 4.3.7. Protocol Substitution Attack . . . . . . . . . . . . . 9 92 4.3.8. Protocol Downgrade Attack . . . . . . . . . . . . . . 9 93 4.4. User Notification . . . . . . . . . . . . . . . . . . . . 9 94 4.4.1. Certificate Data . . . . . . . . . . . . . . . . . . . 9 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 99 7.2. Non-Normative References . . . . . . . . . . . . . . . . . 10 100 Appendix A. Appendix - Design Choices . . . . . . . . . . . . . . 11 101 A.1. Key Digest . . . . . . . . . . . . . . . . . . . . . . . . 11 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 104 1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 2. Introduction 112 The DNS CERT resource record defined in RFC 4398 [RFC4398] specifies 113 the use of the DNS for discovery of public keys associated with a 114 domain. 116 2.1. DNS 118 2.1.1. DNSSEC 120 2.1.2. DNS CERT Resource Record 122 2.2. Public Key Infrastructure 124 2.2.1. Public Key Infrastructure X.509 126 2.3. Public Key Security Protocols 128 2.3.1. Transport Layer Security 130 2.3.2. IP Security 132 2.3.3. Use in Applications 134 3. Mechanism 136 3.1. CERT Resource Record Parameters 138 Two new CERT certificate types are defined: 140 DPKIX 142 DPTR 144 The CERT resource record (RR) has the structure given below. Its RR 145 type code is 37. 147 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | type | key tag | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | algorithm | / 153 +---------------+ certificate data / 154 / / 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 157 The type field is the certificate type as defined below. 159 The key tag field used for key selection as specified in RFC 4034 160 [RFC4034] Section 5.1.1. 162 The algorithm field is the algorithm code for the digest algorithm as 163 specified in the IANA registry Delegation Signer (DS) Resource Record 164 (RR) Type Digest Algorithms. 166 3.1.1. DPKIX 168 The DPKIX certificate type asserts a binding between the DNS domain 169 in which it is published and the subject key specified in a PKIX 170 certificate identified by means of a cryptographic digest function. 172 The assertion made by means of the DPKIX certificate type is only as 173 secure as the trust chain that authenticates it. Trust chain 174 processing rules are specified in Section XXX below. 176 In particular the presence of a DPKIX record in a DNS domain that is 177 not signed using DNSSEC or other security mechanism SHOULD NOT be 178 considered to provide any additional assurance that would not be 179 provided by the certificate on its own. 181 In the case that a DPKIX record exists and contains a digest value 182 that matches the digest value of the certificate and is signed by a 183 verified signature, a relying party MAY infer an assertion on the 184 part of the domain name holder that the specified key is bound to the 185 specified certificate subject key. No other properties of the 186 certificate may be considered to have been assured excepting those 187 that limit the use of the certificate which MUST be observed as with 188 any other PKIX certificate. Such properties include the notBefore 189 and notAfter fields, the key Usage bits and all X.509v3 extensions 190 for which the critical bit is set. 192 The CERT record field values are defined for DPKIX as follows: 194 Type is set to the value (TBS IANA) 196 Key tag MUST be set to 1 198 Algorithm contains the algorithm code for the digest algorithm. 200 Certificate data contains the digest value of the certificate for 201 which a binding between the subject key and the domain name is 202 asserted 204 example.com CERT DPKIX 1 SHA256 205 KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc 207 3.1.2. DPTR 209 The DPTR certificate type allows an unlimited number of certificates 210 to be bound to a single DNS domain name overcomming the limitations 211 that the DNS protocol imposes on the number of CERT records that can 212 be bound to a single DNS domain name in a practical deployment. 214 The CERT record field values are defined for DPTR as follows: 216 Type is set to the value (TBS IANA) 218 Key tag MUST be set to 1 220 Algorithm contains the algorithm code for the digest algorithm to 221 be used to calculate Cselector prefixes. 223 Certificate data contains the DNS name to be used as the root node 224 to which the calculated selectorn prefix is prepended. 226 The PKIX certificate for which the assurance is being saught is 227 processed using the specified digest algorithm to produce a digest 228 value which is converted to base 64 according to the mechanism 229 specified in [] and has an underscore character '_' prepended to form 230 a selector label as follows: 232 selector = "_" + base64 ( digest ( certificate)) 234 The key selector label is prepended to the domain name specified to 235 form a DNS domain name on which a DNS query for a CERT resource 236 record is to be performed. 238 query_name = selector + "." + domain_name 240 The following example shows the use of the DPTR certificate type to 241 provide an assurance for the same certificate specified earlier. 243 example.com CERT DPTR 1 SHA256 "cert.example.com" 244 _KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc.cert.example.com DPKIX 245 1 SHA256 KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc 247 The DPTR certificate type can only be resolved after the certificate 248 for which the assurance is required is known. It is thus not 249 possible to pre-fetch the certificate at the same time that A or AAAA 250 record is performed as is the case when the DPKIX certificate type is 251 populated at the domain name for which the assurance is being made. 253 3.2. X.509v3 Extension 255 The X.509v3 certificate extension 'DNS-CERT' MAY be included in an 256 X.509v3 certificate to notify relying parties that a DNS key 257 assurance MAY or MUST be employed. 259 If the DNS-CERT extension is present and the critical flag bit is not 260 set, it serves as a notice to a relying party applications that they 261 MAY attempt to use the key assurance mechanism specified in this 262 document. 264 If the DNS-CERT extension critical flag bit is set, a relying party 265 application MUST support the key assurance mechanism specified in 266 this document and MUST NOT consider the certificate valid unless the 267 outcome of the verification procedure is 'verified'. 269 Since applications MUST NOT make use of X.509v3 critical extensions 270 that are not understood, use of the critical flag bit value 'set' is 271 strongly discouraged. Certificate issuers SHOULD NOT set the 272 critical flag bit on a DNS-CERT unless this is the derisred behavior 274 3.3. Processing Rules 276 3.3.1. General 278 3.3.2. Transport layer Security 280 3.3.3. Service Discovery (SRV, NAPTR) 282 4. Security Considerations 283 4.1. Trust Chain Assurance 285 4.1.1. Root of Trust 287 4.1.2. Non Repudiation 289 4.1.3. Key Revocation 291 4.2. DNSSEC Operations 293 4.2.1. Signature Time To Live 295 4.2.2. Zone Signing Key Compromise 297 4.2.3. Key Signing Key Compromise 299 4.3. Attacks 301 We have considered possible protocol attacks by identifying protocol 302 assets, the abstract risks to which such assets may be exposed and 303 how such risks may be manifest in concrete threats. 305 The assets considered are the DNSSEC private keys held by the domain 306 name holder, DNS zone in which the resorce records are presented and 307 the application public key pair. 309 The DNS is a large infrastructure and management of a specific DNS 310 zone is never within the unique control of one party. In addition to 311 considering means of preventing compromise we consider the steps 312 required to recover from a compromise. 314 4.3.1. Suppressed DNSSEC records 316 4.3.2. Replay Attack of DNSSEC records 318 4.3.3. Zone Hijack 320 4.3.4. Disclosure of End Entity Key 322 4.3.5. Disclosure of DNSSEC Key 324 4.3.6. Malicious Domain Name Holder 326 A signed CERT record only demonstrates that the party in control of 327 the authoritative DNS zerver for the specified zone has authorized 328 the use of a particular public key for authenticating communication 329 with the server. 331 A signed CERT record does not and cannot express any assertion 332 concerning the existence, trustworthiness or accountability of either 333 the key holder or the domain name holder. 335 4.3.7. Protocol Substitution Attack 337 for the purposes of establishing a secure connection, an end entity 338 certificate assured by means of a signed CERT record MUST meet all 339 the requirements that any other end entity certificate is required to 340 meed for use with that protocol. 342 If protection against a protocol substitution attack is required, the 343 signer of the end entity certificate SHOULD ensure that the 344 appropriate X.509 Key Usage, Extended Key Usage and/or extensions are 345 appropriately configured. 347 4.3.8. Protocol Downgrade Attack 349 The CERT record only provides notice that a public key is associated 350 with a DNS domain name. The mere presence of a CERT record at a DNS 351 node does not imply that its use is supported in conjunction with a 352 specific protocol. 354 Accordingly, use of CERT records does not and cannot provide 355 protection against protocol downgrade attacks. 357 4.4. User Notification 359 Relying party applciations MAY notify the user that a cryptographic 360 security protocol is in use to protect the confidentiality and 361 integrity of communication with the domain name holder. 363 Key assurance by means of the CERT mechanism only extends to the 364 properties of the key itself and the security of the connection 365 established to the Internet service provided by the key holder. Key 366 Assurance by means of the CERT mechanism does not and cannot support 367 any assertion regarding the trustworthiness of either the key holder 368 or the domain name holder. 370 A secure connection to an endpoint identified by a domain name alone 371 does not imply a secure transaction. If provided, a user 372 notification MUST NOT imply that a user is 'safe' on the basis of 373 CERT key assurance alone. 375 4.4.1. Certificate Data 377 The only data inside a 379 5. IANA Considerations 381 The IANA maintains theregistry for CERT RR: certificate types. The 382 following additional certificate types should be added to the 383 registry at the next available code point: 385 Decimal Type Meaning Reference 386 ------- ---- ------- --------- 387 9 DPKIX Digest value of X.509 as per PKIX [This] 388 10 SIHLOK Indirection Pointer [This] 390 6. Acknowledgements 392 7. References 394 7.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 400 Rose, "DNS Security Introduction and Requirements", 401 RFC 4033, March 2005. 403 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 404 Rose, "Resource Records for the DNS Security Extensions", 405 RFC 4034, March 2005. 407 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 408 Rose, "Protocol Modifications for the DNS Security 409 Extensions", RFC 4035, March 2005. 411 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 412 System (DNS)", RFC 4398, March 2006. 414 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 415 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 417 7.2. Non-Normative References 419 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 420 Material in DNS", RFC 4025, March 2005. 422 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 423 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 424 January 2006. 426 Appendix A. Appendix - Design Choices 428 This section provides rationales for design choices adopted in this 429 draft. 431 A.1. Key Digest 433 The use of CERT type for digests of keys as opposed to complete 434 certificates was considered and rejected. 436 Author's Address 438 Phillip Hallam-Baker 439 Comodo Inc. 441 Email: philliph@comodo.com