idnits 2.17.1 draft-hallambaker-dane-requirements-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 (April 7, 2011) is 4740 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'A-EVE' is mentioned on line 204, but not defined == Missing Reference: 'A-DNS' is mentioned on line 213, but not defined == Missing Reference: 'A-DENY' is mentioned on line 232, but not defined == Missing Reference: 'A-UCA' is mentioned on line 302, but not defined == Missing Reference: 'A-MALLET' is mentioned on line 253, but not defined == Missing Reference: 'P-Alice' is mentioned on line 264, but not defined == Missing Reference: 'U-S-TRUST' is mentioned on line 301, but not defined == Missing Reference: 'P-CAROL' is mentioned on line 304, but not defined == Missing Reference: 'U-S-SINGLE' is mentioned on line 308, but not defined == Missing Reference: 'U-S-MULTIPLE' is mentioned on line 313, but not defined == Missing Reference: 'U-S-RAPID' is mentioned on line 319, but not defined == Missing Reference: 'U-S-ALIAS' is mentioned on line 329, but not defined == Missing Reference: 'U-S-ALIAS1' is mentioned on line 331, but not defined == Missing Reference: 'U-S-ALIAS2' is mentioned on line 335, but not defined == Missing Reference: 'U-S-DEFAULT' is mentioned on line 345, but not defined == Missing Reference: 'P-BOB' is mentioned on line 352, but not defined == Missing Reference: 'P-IA' is mentioned on line 357, but not defined == Missing Reference: 'U-C-DNSID-BOB' is mentioned on line 365, but not defined == Missing Reference: 'U-C-DNSID-IA' is mentioned on line 365, but not defined == Missing Reference: 'U-C-TRUST-BOB' is mentioned on line 382, but not defined == Missing Reference: 'U-C-TRUST-IA' is mentioned on line 377, but not defined == Missing Reference: 'U-C-UNTRUST' is mentioned on line 386, but not defined == Missing Reference: 'U-C-UNTRUST-IA' is mentioned on line 386, but not defined == Missing Reference: 'U-C-BEST' is mentioned on line 391, but not defined == Missing Reference: 'U-C-ACCOUNT' is mentioned on line 396, but not defined == Missing Reference: 'U-C-EMAIL' is mentioned on line 400, but not defined == Missing Reference: 'C-SIZE' is mentioned on line 406, but not defined == Missing Reference: 'C-DNSSEC' is mentioned on line 417, but not defined == Missing Reference: 'C-PREFIX' is mentioned on line 470, but not defined == Missing Reference: 'C-DISC' is mentioned on line 454, but not defined == Missing Reference: 'R-C-KEYPUB' is mentioned on line 494, but not defined == Missing Reference: 'R-C-DV' is mentioned on line 519, but not defined == Missing Reference: 'R-C-SV' is mentioned on line 533, but not defined == Missing Reference: 'R-C-SA' is mentioned on line 546, but not defined == Missing Reference: 'R-C-CV' is mentioned on line 551, but not defined == Missing Reference: 'R-C-CI' is mentioned on line 557, but not defined == Missing Reference: 'R-P-A' is mentioned on line 579, but not defined == Missing Reference: 'R-P-AAAA' is mentioned on line 584, but not defined == Missing Reference: 'R-P-EDISC' is mentioned on line 594, but not defined == Missing Reference: 'R-P-MDISC' is mentioned on line 599, but not defined == Missing Reference: 'R-P-LOCAL' is mentioned on line 606, but not defined == Missing Reference: 'R-P-LOCALD' is mentioned on line 611, but not defined == Missing Reference: 'R-P-CNAME' is mentioned on line 617, but not defined == Missing Reference: 'R-P-WILD' is mentioned on line 622, but not defined == Missing Reference: 'R-P-OPP' is mentioned on line 631, but not defined == Missing Reference: 'R-P-STRICT' is mentioned on line 649, but not defined == Missing Reference: 'R-P-VER' is mentioned on line 660, but not defined == Missing Reference: 'TBS' is mentioned on line 774, but not defined == Missing Reference: 'M-TCP' is mentioned on line 706, but not defined == Missing Reference: 'M-RT' is mentioned on line 718, but not defined == Missing Reference: 'M-LC' is mentioned on line 737, but not defined == Missing Reference: 'AL' is mentioned on line 750, but not defined == Missing Reference: 'M-STATES' is mentioned on line 762, but not defined == Missing Reference: 'M-TRANS' is mentioned on line 768, but not defined == Missing Reference: 'NIST-ALGS' is mentioned on line 829, but not defined == Missing Reference: 'RFC3642' is mentioned on line 833, but not defined == Missing Reference: 'RFC4648' is mentioned on line 836, but not defined == Unused Reference: 'RFC4055' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'RFC5395' is defined on line 805, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) Summary: 1 error (**), 0 flaws (~~), 60 warnings (==), 1 comment (--). 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 Group Inc. 4 Intended status: Experimental April 7, 2011 5 Expires: October 9, 2011 7 DANE Use Cases, Requirement and Deployment 8 draft-hallambaker-dane-requirements-01 10 Abstract 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute 19 working documents as Internet-Drafts. The list of current Internet- 20 Drafts is at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 This Internet-Draft will expire on October 9, 2011. 29 Copyright Notice 31 Copyright (c) 2011 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Table of Contents 46 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 48 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 2.1. Attack Model . . . . . . . . . . . . . . . . . . . . . . . 5 51 2.1.1. Eve the Evesdropper: Confidentiality . . . . . . . . . 5 52 2.1.2. Simon DNS Spoofer: Integrity . . . . . . . . . . . . . 6 53 2.1.3. Denis the Denier of Service: Service . . . . . . . . . 6 54 2.1.4. Ulma, the Untrustworthy Third Party . . . . . . . . . 6 55 2.1.5. Mallet the Man-in-the-Middle: Confidentiality + 56 Integrity + Service . . . . . . . . . . . . . . . . . 6 57 2.2. Server Use Cases (Alice) . . . . . . . . . . . . . . . . . 7 58 2.2.1. Server Types . . . . . . . . . . . . . . . . . . . . . 7 59 2.2.1.1. Human/Machine Interaction: Web Browser . . . . . . 7 60 2.2.1.2. Human/Machine Interaction: Other . . . . . . . . . 7 61 2.2.1.3. Web Service / Internet Service . . . . . . . . . . 7 62 2.2.2. Administrative Use Cases . . . . . . . . . . . . . . . 7 63 2.2.2.1. Trusted Third Party Restriction . . . . . . . . . 7 64 2.2.2.2. Single Service . . . . . . . . . . . . . . . . . . 8 65 2.2.2.3. Multiple Services . . . . . . . . . . . . . . . . 8 66 2.2.2.4. Rapid Configuration Changes . . . . . . . . . . . 8 67 2.2.2.5. [U-S-ALIAS] Service Mapping . . . . . . . . . . . 8 68 2.2.2.6. [U-S-DEFAULT] Default Service . . . . . . . . . . 8 69 2.3. Client Use Cases . . . . . . . . . . . . . . . . . . . . . 8 70 2.3.1. Verify DNS Identity . . . . . . . . . . . . . . . . . 9 71 2.3.2. Establish Trust . . . . . . . . . . . . . . . . . . . 9 72 2.3.3. Establish Un-Trust . . . . . . . . . . . . . . . . . . 9 73 2.3.4. Best Connection . . . . . . . . . . . . . . . . . . . 9 74 2.3.5. User Presence . . . . . . . . . . . . . . . . . . . . 9 75 2.3.6. Secure Email . . . . . . . . . . . . . . . . . . . . . 9 76 3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1. DNS Size Constraints . . . . . . . . . . . . . . . . . . . 10 78 3.2. DNSSEC Deployment . . . . . . . . . . . . . . . . . . . . 10 79 3.3. DNS Prefixing . . . . . . . . . . . . . . . . . . . . . . 10 80 3.4. Extended Discovery . . . . . . . . . . . . . . . . . . . . 11 81 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 4.1. Cryptographic Requirements . . . . . . . . . . . . . . . . 11 83 4.1.1. Key Publication . . . . . . . . . . . . . . . . . . . 11 84 4.1.2. Domain Validation . . . . . . . . . . . . . . . . . . 12 85 4.1.3. Subject Validation . . . . . . . . . . . . . . . . . . 12 86 4.1.4. Subject Attestation . . . . . . . . . . . . . . . . . 13 87 4.1.5. Certificate Validation . . . . . . . . . . . . . . . . 13 88 4.1.6. Certificate Issue Control . . . . . . . . . . . . . . 13 89 4.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 13 90 4.2.1. Service Discovery . . . . . . . . . . . . . . . . . . 13 91 4.2.1.1. A RR Discovry . . . . . . . . . . . . . . . . . . 13 92 4.2.1.2. A/AAAA RR Discovry . . . . . . . . . . . . . . . . 13 93 4.2.1.3. Extended Discovery . . . . . . . . . . . . . . . . 14 94 4.2.1.4. Extended Meta-Discovery . . . . . . . . . . . . . 14 95 4.2.2. DNS Administration . . . . . . . . . . . . . . . . . . 14 96 4.2.2.1. First Party Deployment . . . . . . . . . . . . . . 14 97 4.2.2.2. First Party with DNSSEC Deployment . . . . . . . . 14 98 4.2.2.3. Use of CNAME and other Aliases . . . . . . . . . . 14 99 4.2.2.4. Use of Wildcards . . . . . . . . . . . . . . . . . 14 100 4.2.3. Protocol Specific Properties . . . . . . . . . . . . . 14 101 4.2.3.1. Security Properties . . . . . . . . . . . . . . . 14 102 4.2.3.2. Version Properties . . . . . . . . . . . . . . . . 15 103 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 5.1. Performance Metrics . . . . . . . . . . . . . . . . . . . 15 105 5.1.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 16 106 5.1.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 16 107 5.1.2.1. TCP Fallback . . . . . . . . . . . . . . . . . . . 16 108 5.1.2.2. Round Trip Count . . . . . . . . . . . . . . . . . 16 109 5.1.2.3. DNS Lookup Count . . . . . . . . . . . . . . . . . 17 110 5.1.3. Caching . . . . . . . . . . . . . . . . . . . . . . . 17 111 5.2. Implementation Metrics . . . . . . . . . . . . . . . . . . 17 112 5.2.1. Number of States . . . . . . . . . . . . . . . . . . . 17 113 5.2.2. Number of Transitions . . . . . . . . . . . . . . . . 17 114 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 115 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 116 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 117 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 118 8.2. Non Normative References . . . . . . . . . . . . . . . . . 19 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 121 1. Definitions 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 1.2. Defined Terms 131 The following terms are used in this document: 133 Abstract Syntax Notation One (ASN.1) A notation for describing 134 abstract types and values, as specified in X.680 [X.680]. 136 Certificate An X.509 Certificate, as specified in RFC 5280 137 [RFC5280]. 139 Certification Policy (CP) Specifies the criteria that a 140 Certification Authority undertakes to meet in its issue of 141 certificates. 143 Certification Practices Statement (CPS) Specifies the means by which 144 the criteria of the Certification Policy are met. In most cases 145 this will be the document against which the operations of the 146 Certification Authority are audited. 148 Certification Authority (CA) An entity that issues Certificates in 149 accordance with a specified Certification Policy. 151 Distinguished Encoding Rules (DER) A set of rules for encoding ASN.1 152 objects, as specified in X.690 [X.690]. 154 Domain The set of resources associated with a DNS Domain Name. 156 Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and 157 revisions. 159 Domain Name System (DNS) The Internet naming system specified in RFC 160 1035 [RFC1035] and revisions. 162 DNS Security (DNSSEC) Extensions to the DNS that provide 163 authentication services as specified in RFC 4033 [RFC4033] and 164 revisions. 166 Key A cryptographic key. 168 Public Key Infrastructure X.509 (PKIX) Standards and specifications 169 issued by the IETF that apply the X.509 [X.509] certificate 170 standards specified by the ITU to Internet applications as 171 specified in RFC 5280 [RFC5280] and related documents. 173 Resource Record (RR) A set of attributes bound to a Domain Name. 175 Relying Party A party that makes use of an application whose 176 operation depends on use of a Certificate or Key for making a 177 security decision. 179 Relying Application An application whose operation depends on use of 180 a Certificate or Key for making a security decision. 182 2. Use Cases 184 Developing use cases for a network security protocol is a developing 185 art. Should the use cases be speficied from the point of view of the 186 client or the server? How does the threat model tie in? 188 In this document we begin by classifying attackers according to their 189 capabilities. The use cases are then developed from the point of 190 view of the client and the server. 192 2.1. Attack Model 194 The asset to be protected is information. Information assets are 195 subject to Confidentiality Integrity and Service risks. 197 For breivty, service risks are not addressed directly, although it 198 should be noted that many controls to mitigate Denial of Service 199 attacks are possible if a client can establish a secure connection to 200 a trustworthy DNS service. 202 2.1.1. Eve the Evesdropper: Confidentiality 204 [A-EVE] Eve has the ability to read communications between the 205 parties but cannot modify them. 207 Eve typically observes traffic by evesdropping on wireless 208 connections or other brodcast hops but may also have access to the 209 cabling through which the signals run. 211 2.1.2. Simon DNS Spoofer: Integrity 213 [A-DNS] Simon the spoofer can control the DNS service responses for a 214 domain. Simon's attacks may affect the entire Internet or be limited 215 in scope. 217 Simon employs a range of techniques to achieve DNS spoofing on a 218 local level. His favorites being cache poisoning and capture of DNS 219 resolvers. He also uses malware attacks that redirect DNS resolution 220 on an infected host or possibly by redirection of a local DNS 221 forwarder at an unsecured network access point. While such attacks 222 are limited in scope, this may actually be preferable since limited 223 scope attacks are more likely to escape detection for an extended 224 period of time. 226 On occasion Simon has redirected DNS domains across the entire 227 Internet through attacks on the registry and/or registrar 228 infrastructure. Such attacks frequently involve social engineering 230 2.1.3. Denis the Denier of Service: Service 232 [A-DENY] Denis the denier of service can prevent the parties from 233 communicating on some but not all communication channels and/or 234 routes. 236 Denis has used a wide range of techniques to effect his attacks 237 including SYN flooding, BGP level attacks and on occasion 238 disconnecting Internet service for an entire country. Denis has also 239 been known to be extremely careless with a backhoe. 241 2.1.4. Ulma, the Untrustworthy Third Party 243 [A-UCA] Ulma is an Untrustworthy Third Party whose root signature key 244 is configured to be trusted by default. 246 Opinions on Ulma vary. Some say that she is trying her best, others 247 worry that her best may not be good enough, others still worry that 248 Ulma is intentionally acting in bad faith. 250 2.1.5. Mallet the Man-in-the-Middle: Confidentiality + Integrity + 251 Service 253 [A-MALLET] Mallet is the man in the middle, the attacker who can 254 control every aspect of a communication. 256 While the activities of Eve, Simon or Ulma may ultimately lead to a 257 successful man in the middle attack, Mallet has the ability to 258 perform such attacks a-priori. He does this by techniques such as 259 BGP spoofing and compromise of infrastructure such as hubs and 260 routers. 262 2.2. Server Use Cases (Alice) 264 [P-Alice] Alice is the administrator of Internet services for a wide 265 variety of customers with very different security needs (and 266 willingness to pay for her services). 268 Some customers want Alice to install and deploy a service as quickly 269 and simply as possible with minimal concern for security. 271 Other customers have more demanding security needs and Alice must 272 meet these as well. 274 2.2.1. Server Types 276 2.2.1.1. Human/Machine Interaction: Web Browser 278 A Web Server that is primarily intended to support human-machine 279 interaction MAY permit the display of a security signal in some 280 circumstances. 282 2.2.1.2. Human/Machine Interaction: Other 284 Other protocols that are primarily intended to support human-machine 285 interaction MAY permit the display of a security signal in some 286 circumstances but the support for such signals is poorly defined. 288 2.2.1.3. Web Service / Internet Service 290 A service that is primarily designed to support machine/machine 291 interaction. for example delivery of SMTP messages from an outgoing 292 to an incoming mail server, Web Services of all types, etc. 294 Since there is no user in such cases, there is no party to read or 295 interpert a UI security signal. 297 2.2.2. Administrative Use Cases 299 2.2.2.1. Trusted Third Party Restriction 301 [U-S-TRUST] Having noted the behavior of Ulma and the risk of 302 compromise due to [A-UCA], Alice wishes to ensure that the only 303 certificates that are issued for a domain or accepted by applications 304 are those issued by Carol [P-CAROL] 306 2.2.2.2. Single Service 308 [U-S-SINGLE] Alice is deploying a single service in a domain and 309 wishes to do so with minimal effort. 311 2.2.2.3. Multiple Services 313 [U-S-MULTIPLE] Alice is deploying many services in a domain and is 314 more concerned with the stability and long-term maintenance of the 315 systems. 317 2.2.2.4. Rapid Configuration Changes 319 [U-S-RAPID] Alice is deploying many services in a domain with rapidly 320 changing configuration demands. 322 For example, Alice is supporting a Web site that has greatly varying 323 capacity requirements throughout the day. A single server is 324 sufficient to meet demand for most of the day but at peak times 325 demand can rapidly grow to 16 servers or more. Alice meets these 326 requirements by renting services in the cloud in response to current 327 needs. 329 2.2.2.5. [U-S-ALIAS] Service Mapping 331 [U-S-ALIAS1] Alice has been asked to change the name of a Web site 332 from www.example.net to www.example.com so that a single server can 333 support both sites without the need for separate management. 335 [U-S-ALIAS2] Although the official name for the Web site is 336 www.example.com, many users rely on the autocomplete feature in most 337 Web browsers and only type in example.com and this can lead to 338 performance issues. 340 Service mappings through use of CNAME and/or internal HTTP redirects 341 on a Web server are a frequent administrative requirement. 343 2.2.2.6. [U-S-DEFAULT] Default Service 345 [U-S-DEFAULT] Alice has been asked to ensure that a visitor 346 attempting to connect to a Web site with any domain name in or under 347 example.com will always succeed, even if the corresponding DNS name 348 is empty. 350 2.3. Client Use Cases 352 Bob [P-BOB] is a human who uses a range of Web sites, Web Services 353 and Internet services with different security requirements. 355 In some cases Bob makes use of a Web Service that will in turn make 356 service requests on his behalf, acting as an Intelligent Agent 357 [P-IA]. 359 2.3.1. Verify DNS Identity 361 [U-C-DNSID-BOB] Bob has used the site example.com for many years and 362 trusts the site maintainer. How can Bob ensure that he has connected 363 to the real 'example.conm'? 365 [U-C-DNSID-IA] Similar to [U-C-DNSID-BOB] above, the Intelligent 366 Agent is preconfigured through an out-of-band mechanism to trust a 367 Web Service offered by a particular DNS domain. 369 2.3.2. Establish Trust 371 [U-C-TRUST-BOB] Bob is looking for an Internet source supplying 372 widgest. He discovers such a site through a Web search engine that 373 does meet his trust criteria but Bob is not aware that this is the 374 case. How can Bob determine that he can trust the Web site he has 375 found with his credit card details? 377 [U-C-TRUST-IA]Similar to [U-C-TRUST-BOB] above, but the transaction 378 is to be handled by the Intelligent agent. 380 2.3.3. Establish Un-Trust 382 [U-C-UNTRUST] In the converse of [U-C-TRUST-BOB], the Web site found 383 does not meet Bob's trust criteria. How can Bob distinguish this 384 case from the case where his criteria are met? 386 [U-C-UNTRUST-IA]Similar to [U-C-UNTRUST] above, but the transaction 387 is to be handled by the Intelligent agent. 389 2.3.4. Best Connection 391 [U-C-BEST] Bob connects to a Web site. Bob wants connections to the 392 example.com Web site to be 'as secure as possible'. 394 2.3.5. User Presence 396 [U-C-ACCOUNT] TBS 398 2.3.6. Secure Email 400 [U-C-EMAIL] TBS 402 3. Constraints 404 3.1. DNS Size Constraints 406 [C-SIZE] DNS responses must fit into a single IP packet if TCP 407 fallback is to be avoided and such mackets must be smaller than the 408 path MTU if fragmentation is to be avoided. 410 While some of the worst consequences of this restriction have been 411 mitigated through EDNS(0), use of DNSSEC and in particular the need 412 to attach DNS SIG records for each recordset mean that its 413 consequences cannot be entirely ignored. 415 3.2. DNSSEC Deployment 417 [C-DNSSEC] DNSSEC is only partially deployed. While DNSSEC is 418 deployed at most DNS TLDs, deployment has not been effected in many 419 TLDs. Moreover in some TLDs where DNSSEC is 'deployed' it is only 420 supported by the registry and not by registrars. 422 3.3. DNS Prefixing 424 [C-PREFIX] The practice of using prefixes to DNS names to allow 425 protocol and/or service specific properties to be specified is not 426 fully interoperable with existing practices for using aliases or 427 wildcards. 429 As far as the DNS infrastructure is concerned, a DNS name that 430 incorporates a prefix is no different from any other DNS name and 431 that creates problems for DNS administration since it is generally 432 desirable that wildcards and aliases apply to all protocol properties 433 associated with a domain name, including those expressed using a 434 prefix. 436 The DNS infrastructure does not support midpoint wildcard record of 437 the form 'x.*.y.z'. The only wildcard form supported being the case 438 where the wildcard is a prefix, i.e. '*.y.z'. While it is possible 439 to create wildcards that create the desired matches for a given 440 prefix record, it is not possible to do so without ambiguity. The 441 patern *.y.z will match _p1.y.z as desired, but it will also match 442 _p2.y.z and any other prefix. 444 A DNS CNAME Resource record declares the canonical name for a given 445 domain name. Since the purpose of a DNS CNAME record is to 'alias' 446 one name to another, it is clearly desirable for an alias to have 447 effect for all prefixes associated with the domain name as well. In 448 practice a CNAME mapping x.y.z to p.q.r has no effect on queries for 449 _prefix.x.y.z and the only way to ensure that these forward correctly 450 is to create mappings for each case. 452 3.4. Extended Discovery 454 [C-DISC] Use of an extended discovery mechanism such as SRV, NAPTR 455 and/or URI may be an Internet architecture requirement at some date 456 in the future. 458 Just as IPv4 addresses are running out, IP port numbers are facing a 459 similar exhaustion issue. IP only allows 16 bits for specification 460 of port numbers and this is not extended in IPv6. It is thus 461 inevitable that the 'well known ports' mechanism will eventually run 462 out of code points for assignment and that this will be replaced by 463 some other mechanism. 465 Extended discovery mechanisms such as SRV, NAPTR and URI provide an 466 alternative means of service discovery, albeit with significant 467 practical limitations in their current form. In particular the 468 extended discovery mechansisms proposed to date all employ some form 469 of prefix mechanism as a substitute for well known port numbers and 470 thus subject to the corresponding constraints [C-PREFIX]. 472 Another practical limitation to the use of SRV, NAPTR, URI, etc. is 473 that the decision to support extended discovery and the selection of 474 the extended discovery mechanism to be used rests with the protocol 475 designer rather than the admninistrator of the domain where they are 476 to be deployed. 478 4. Requirements 480 For convenience, requirements are separated into cryptographic 481 requirements and protocol requirements. 483 No attempt has been made to separate requirements according to 484 priority except to note where a requirement is mandated by the DANE 485 charter or is met by existing infrastrtucture. 487 4.1. Cryptographic Requirements 489 The cryptographic requirements are set out with the intention of 490 drawing attention to the precise semantics involved. 492 4.1.1. Key Publication 494 [R-C-KEYPUB] Allow relying party to access the value of the key 495 material which may or may not be valid for the domain for which it is 496 published. 498 Key Publication does not necessarily entail any assertion concerning 499 the validity and/or use of the certificate in question. The 500 certificate may have expired, it may have been revoked, it may bear 501 no correspondance to the domain at which it is published whatsover. 503 Example: www.example.com CERT 1 0 [ICANN KSK Certificate] 505 Since publication of a key or certificaste does not in itself imply 506 an assertion that it is to be considered trustworthy, satisfying this 507 requirement does not necessitate the use of DNSSEC. 509 Publication of cryptographic keying material is supported by the 510 existing DNS CERT record. 512 Existing CERT certificate types do not imply an assertion on the part 513 of a domain name owner that the published keying material is valid 514 for or indeed has any relationship to the specified domain 515 whatsoever. 517 4.1.2. Domain Validation 519 [R-C-DV] Assert that a key is valid for use with a specific domain 521 Example: www.example.com RR-TBS [CA root for *.example.com] 523 Domain Validation entails an assertion that the specified certificate 524 or key is valid for the associated domain but does not necessarily 525 entail an assertion that the subject is trustworthy. 527 Since the only criteria required to register a domain in most domains 528 is to pay a registration fee, Domain Validation alone does not 529 normally provide a useful basis for trust. 531 4.1.3. Subject Validation 533 [R-C-SV] Determine criteria that may indicate that the subject should 534 be trusted. E.g. reputation mechanisms, evidence of accountability. 536 Subject Validation involves verification that is above and beyond the 537 requirement for registration of a domain name. The Extended 538 Validation criteria set out requirements that are intended to provide 539 a high degree of assurance that the subject is accountable according 540 to legal process. 542 Example: www.example.com RR-TBS [EV Cert for www.example.com] 544 4.1.4. Subject Attestation 546 [R-C-SA] Vouch for the trustworthiness of the subject, i.e. shoulc we 547 show Padlock Icon, Green Bar 549 4.1.5. Certificate Validation 551 [R-C-CV] Additional means of certificate validation/revocation that 552 are outside the normal PKIX path. E.g. specify trust roots, 553 enumeration of valid certs. 555 4.1.6. Certificate Issue Control 557 [R-C-CI] Inform certificate issuers that a domain name owner requires 558 specified validation criteria to apply in addition to those normally 559 applied. 561 4.2. Protocol Requirements 563 In order for a client to make contact with a server, the client must 564 discover the IP address and port number to connect to. 566 4.2.1. Service Discovery 568 Although the design of discovery mechanisms is outside the scope of 569 DANE, the use of the DNS to obtain cryptographic service properties 570 is predicated on the use of the DNS to perform service discovery. 571 The means of DNS service discovery employed and interoperation of 572 that means with DANE will have impact on performance. 574 Also relevant to consideration in DANE is the range of discovery 575 mechanisms supported. 577 4.2.1.1. A RR Discovry 579 [R-P-A] Support use of Internet service discovery by means of DNS A 580 record and well known port assignment. 582 4.2.1.2. A/AAAA RR Discovry 584 [R-P-AAAA] Support use of Internet service discovery by means of DNS 585 A record and AAAA record and well known port assignment. 587 The introduction of IPv6 has led many protocol stacks to issue 588 parallel requests for A and AAAA DNS records. While this practice is 589 out of scope for DANE protocol, the performance impact may be 590 relevant. 592 4.2.1.3. Extended Discovery 594 [R-P-EDISC] Support use of extended discovery mechanisms (e.g. SRV, 595 NAPTR, URI) mandated in protocol specification. 597 4.2.1.4. Extended Meta-Discovery 599 [R-P-MDISC] Support use of extended discovery mechanisms (e.g. SRV, 600 NAPTR, URI) selected by local DNS administrator. 602 4.2.2. DNS Administration 604 4.2.2.1. First Party Deployment 606 [R-P-LOCAL] Support deployment by local network administration 607 without reference to any other party. 609 4.2.2.2. First Party with DNSSEC Deployment 611 [R-P-LOCALD] Support deployment by local network administration 612 without reference to any other party except for enrollment of DNSSEC 613 KSK. 615 4.2.2.3. Use of CNAME and other Aliases 617 [R-P-CNAME] Support use of single CNAME records to establish aliases 618 for a domain name and all associated protocol properties. 620 4.2.2.4. Use of Wildcards 622 [R-P-WILD] Support use of wildcards to establish default properties 623 for all empty domain names within a tree. 625 4.2.3. Protocol Specific Properties 627 4.2.3.1. Security Properties 629 4.2.3.1.1. Opportunistic Enhancement 631 [R-P-OPP] Support protocol-specific properties to declare that a 632 security enhancement is offered. 634 Since most Internet traffic is exchanged without any form of 635 cryptographic security, there is a school of thought that holds that 636 any form of security enhancement must be an improvement, provided 637 that the user is not led to believe that the degree of security 638 offered is greater than it is. 640 For example, an encryption mode that is vulnerable to a man in the 641 middle attack is generally to be preferred to performing the same 642 communication in plaintext. 644 The use of DNS based keying and self signed certificates for such 645 purposes has a long history in the IETF. 647 4.2.3.1.2. Strict Security 649 [R-P-STRICT] Support protocol-specific properties to declare that a 650 security enhancement is offered and that strict compliance is 651 requested. 653 Strict security is similar to opportunistic enhancement except that 654 it is intended to provide protection against downgrade attack by 655 informing the client that it MUST NOT accept a service connection 656 that does not meet certain security and/or trust criteria. 658 4.2.3.2. Version Properties 660 [R-P-VER] Support protocol specific properties such as identifying 661 the version(s) of a protocol supported by a given service instance. 663 5. Metrics 665 Relevant performance and implementation metrics are specified as a 666 means of guiding the selection process. 668 5.1. Performance Metrics 670 When defining performance metrics it is important to consider the 671 performance of the system in which they are to be used rather than 672 identifying easily measured but irrelevant properties of isolated 673 components. 675 Since the end goal of the application client is to establish a secure 676 connection with the server, it is important to consider the 677 performance metrics for both discovery and keying related purposes. 678 A proposal that obtains the keying material in one round trip that 679 can be performed in parallel with discovery by A-record will in the 680 general case be more performant than one that only requires one round 681 trip but the resquest cannot be made until after the A-record lookup 682 has completed. 684 5.1.1. Bandwidth 686 DNS requests and responses are typically limited to a single packet 687 in each case and thus bandwidth is normally irrelevant as far as 688 measurement of performance goes. 690 5.1.2. Latency 692 Latency is a key performance metric for many interactive network 693 applications. Browser authors report that DNS latency has a major 694 impact on overall user satisfaction [TBS]. 696 The extent that a protocol design choice has impact on latency 697 depends on properties of the DNS that are heavily context dependent 698 and thus do not translate directly into a latency metric. In 699 particular the time taken to complete a DNS round trip, the failure 700 rate of DNS requests and the retransmit interval are all situation 701 dependent and will have impact on how protocol design properties 702 result in latency. 704 5.1.2.1. TCP Fallback 706 [M-TCP] Probability that a request will result in TCP/IP fallback. 708 Attempts to exchange DNS packets larger than the maximum packet size 709 supported results in an error and a retry using TCP/IP. 711 In the best case, TCP fallback will result in a major impact on 712 latency and server performance. In the worst case, TCP fallback may 713 fail as the mechanism is rarely required in normal DNS configuration 714 and is frequently misconfigured in middleboxes such as firewalls. 716 5.1.2.2. Round Trip Count 718 [M-RT] Number of sequential DNS round trips required to address 719 supported use cases. 721 The number of round trips may depend on the circumstances. For 722 example a proposal might require 3 round trips in the worst case but 723 resolve in 1 round trip in 95% of cases. This may be preferable to a 724 protocol that resolves in 2 round trips in every case. 726 Implementations may in some cases mitigate the impact of a proposal 727 requiring multiple round trips through speculative lookups. For 728 example, a protocol requirement to obtain the canonical form of 729 'www.example.com' before applying a protocol specific prefix 730 '_http._tcp' will require two round trips but this can be achieved in 731 a single round trip if www.example.com is in fact canonical and the 732 implementation makes a speculative request for 733 '_http._tcp.www.example.com' at the same time as resolving for the 735 5.1.2.3. DNS Lookup Count 737 [M-LC] Total number of DNS queries required to address supported use 738 cases including lookups performed in parallel. 740 If DNS queries were perfectly reliable, a proposal that required ten 741 lookups to be performed in parallel would have essentially the same 742 performance characteristics as a proposal that only required one. 744 In practice, DNS queries are not perfectly reliable and a proposal 745 that requires ten lookups rather than one has roughly ten times the 746 probability of a random failure. Should a failure occur, the client 747 must wait before retransmitting the request. The typical timeout 748 periods being many times the time taken for a round trip. 750 Although preliminary studies [AL] suggest a failure rate for unknown 751 DNS RR codes of approximately 1.5% it is not known what proportion of 752 such requests will never resolve under any circumstances. 754 5.1.3. Caching 756 [Should say something obvious here] 758 5.2. Implementation Metrics 760 5.2.1. Number of States 762 [M-STATES] Code Complexity measured by reference to the number of 763 states required to create an implementation that is not optimized for 764 performance. 766 5.2.2. Number of Transitions 768 [M-TRANS] Code Complexity measured by reference to the number of 769 state transitions required to create an implementation that is not 770 optimized for performance. 772 6. Security Considerations 774 [TBS] 776 7. IANA Considerations 778 None 780 8. References 782 8.1. Normative References 784 [RFC1035] Mockapetris, P., "Domain names - implementation and 785 specification", STD 13, RFC 1035, November 1987. 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, March 1997. 790 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 791 Rose, "DNS Security Introduction and Requirements", 792 RFC 4033, March 2005. 794 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 795 Algorithms and Identifiers for RSA Cryptography for use in 796 the Internet X.509 Public Key Infrastructure Certificate 797 and Certificate Revocation List (CRL) Profile", RFC 4055, 798 June 2005. 800 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 801 Housley, R., and W. Polk, "Internet X.509 Public Key 802 Infrastructure Certificate and Certificate Revocation List 803 (CRL) Profile", RFC 5280, May 2008. 805 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 806 Considerations", RFC 5395, November 2008. 808 [X.509] International Telecommunication Union, "ITU-T 809 Recommendation X.509 (11/2008): Information technology - 810 Open systems interconnection - The Directory: Public-key 811 and attribute certificate frameworks", ITU-T 812 Recommendation X.509, November 2008. 814 [X.680] International Telecommunication Union, "ITU-T 815 Recommendation X.680 (11/2008): Information technology - 816 Abstract Syntax Notation One (ASN.1): Specification of 817 basic notation", ITU-T Recommendation X.680, 818 November 2008. 820 [X.690] International Telecommunication Union, "ITU-T 821 Recommendation X.690 (11/2008): Information technology - 822 Abstract Syntax Notation One (ASN.1): Specification of 823 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 824 and Distinguished Encoding Rules (DER)", ITU-T 825 Recommendation X.690, November 2008. 827 8.2. Non Normative References 829 [NIST-ALGS] 830 National Institute of Standards and Technology, 831 "Cryptographic Algorithm Registration", March 2009. 833 [RFC3642] Legg, S., "Common Elements of Generic String Encoding 834 Rules (GSER) Encodings", RFC 3642, October 2003. 836 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 837 Encodings", RFC 4648, October 2006. 839 Author's Address 841 Phillip Hallam-Baker 842 Comodo Group Inc. 844 Email: philliph@comodo.com