Internet Engineering Task Force P. Hallam-Baker Internet-Draft Comodo Group Inc. Intended status: Experimental April 7, 2011 Expires: October 9, 2011 DANE Use Cases, Requirement and Deployment draft-hallambaker-dane-requirements-01 Abstract Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 9, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hallam-Baker Expires October 9, 2011 [Page 1] Internet-Draft DANE Use Cases and Requirements April 2011 Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Attack Model . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Eve the Evesdropper: Confidentiality . . . . . . . . . 5 2.1.2. Simon DNS Spoofer: Integrity . . . . . . . . . . . . . 6 2.1.3. Denis the Denier of Service: Service . . . . . . . . . 6 2.1.4. Ulma, the Untrustworthy Third Party . . . . . . . . . 6 2.1.5. Mallet the Man-in-the-Middle: Confidentiality + Integrity + Service . . . . . . . . . . . . . . . . . 6 2.2. Server Use Cases (Alice) . . . . . . . . . . . . . . . . . 7 2.2.1. Server Types . . . . . . . . . . . . . . . . . . . . . 7 2.2.1.1. Human/Machine Interaction: Web Browser . . . . . . 7 2.2.1.2. Human/Machine Interaction: Other . . . . . . . . . 7 2.2.1.3. Web Service / Internet Service . . . . . . . . . . 7 2.2.2. Administrative Use Cases . . . . . . . . . . . . . . . 7 2.2.2.1. Trusted Third Party Restriction . . . . . . . . . 7 2.2.2.2. Single Service . . . . . . . . . . . . . . . . . . 8 2.2.2.3. Multiple Services . . . . . . . . . . . . . . . . 8 2.2.2.4. Rapid Configuration Changes . . . . . . . . . . . 8 2.2.2.5. [U-S-ALIAS] Service Mapping . . . . . . . . . . . 8 2.2.2.6. [U-S-DEFAULT] Default Service . . . . . . . . . . 8 2.3. Client Use Cases . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Verify DNS Identity . . . . . . . . . . . . . . . . . 9 2.3.2. Establish Trust . . . . . . . . . . . . . . . . . . . 9 2.3.3. Establish Un-Trust . . . . . . . . . . . . . . . . . . 9 2.3.4. Best Connection . . . . . . . . . . . . . . . . . . . 9 2.3.5. User Presence . . . . . . . . . . . . . . . . . . . . 9 2.3.6. Secure Email . . . . . . . . . . . . . . . . . . . . . 9 3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. DNS Size Constraints . . . . . . . . . . . . . . . . . . . 10 3.2. DNSSEC Deployment . . . . . . . . . . . . . . . . . . . . 10 3.3. DNS Prefixing . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Extended Discovery . . . . . . . . . . . . . . . . . . . . 11 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Cryptographic Requirements . . . . . . . . . . . . . . . . 11 4.1.1. Key Publication . . . . . . . . . . . . . . . . . . . 11 4.1.2. Domain Validation . . . . . . . . . . . . . . . . . . 12 4.1.3. Subject Validation . . . . . . . . . . . . . . . . . . 12 4.1.4. Subject Attestation . . . . . . . . . . . . . . . . . 13 4.1.5. Certificate Validation . . . . . . . . . . . . . . . . 13 4.1.6. Certificate Issue Control . . . . . . . . . . . . . . 13 4.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 13 4.2.1. Service Discovery . . . . . . . . . . . . . . . . . . 13 4.2.1.1. A RR Discovry . . . . . . . . . . . . . . . . . . 13 Hallam-Baker Expires October 9, 2011 [Page 2] Internet-Draft DANE Use Cases and Requirements April 2011 4.2.1.2. A/AAAA RR Discovry . . . . . . . . . . . . . . . . 13 4.2.1.3. Extended Discovery . . . . . . . . . . . . . . . . 14 4.2.1.4. Extended Meta-Discovery . . . . . . . . . . . . . 14 4.2.2. DNS Administration . . . . . . . . . . . . . . . . . . 14 4.2.2.1. First Party Deployment . . . . . . . . . . . . . . 14 4.2.2.2. First Party with DNSSEC Deployment . . . . . . . . 14 4.2.2.3. Use of CNAME and other Aliases . . . . . . . . . . 14 4.2.2.4. Use of Wildcards . . . . . . . . . . . . . . . . . 14 4.2.3. Protocol Specific Properties . . . . . . . . . . . . . 14 4.2.3.1. Security Properties . . . . . . . . . . . . . . . 14 4.2.3.2. Version Properties . . . . . . . . . . . . . . . . 15 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Performance Metrics . . . . . . . . . . . . . . . . . . . 15 5.1.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.2.1. TCP Fallback . . . . . . . . . . . . . . . . . . . 16 5.1.2.2. Round Trip Count . . . . . . . . . . . . . . . . . 16 5.1.2.3. DNS Lookup Count . . . . . . . . . . . . . . . . . 17 5.1.3. Caching . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Implementation Metrics . . . . . . . . . . . . . . . . . . 17 5.2.1. Number of States . . . . . . . . . . . . . . . . . . . 17 5.2.2. Number of Transitions . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Non Normative References . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Hallam-Baker Expires October 9, 2011 [Page 3] Internet-Draft DANE Use Cases and Requirements April 2011 1. Definitions 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Defined Terms The following terms are used in this document: Abstract Syntax Notation One (ASN.1) A notation for describing abstract types and values, as specified in X.680 [X.680]. Certificate An X.509 Certificate, as specified in RFC 5280 [RFC5280]. Certification Policy (CP) Specifies the criteria that a Certification Authority undertakes to meet in its issue of certificates. Certification Practices Statement (CPS) Specifies the means by which the criteria of the Certification Policy are met. In most cases this will be the document against which the operations of the Certification Authority are audited. Certification Authority (CA) An entity that issues Certificates in accordance with a specified Certification Policy. Distinguished Encoding Rules (DER) A set of rules for encoding ASN.1 objects, as specified in X.690 [X.690]. Domain The set of resources associated with a DNS Domain Name. Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and revisions. Domain Name System (DNS) The Internet naming system specified in RFC 1035 [RFC1035] and revisions. DNS Security (DNSSEC) Extensions to the DNS that provide authentication services as specified in RFC 4033 [RFC4033] and revisions. Hallam-Baker Expires October 9, 2011 [Page 4] Internet-Draft DANE Use Cases and Requirements April 2011 Key A cryptographic key. Public Key Infrastructure X.509 (PKIX) Standards and specifications issued by the IETF that apply the X.509 [X.509] certificate standards specified by the ITU to Internet applications as specified in RFC 5280 [RFC5280] and related documents. Resource Record (RR) A set of attributes bound to a Domain Name. Relying Party A party that makes use of an application whose operation depends on use of a Certificate or Key for making a security decision. Relying Application An application whose operation depends on use of a Certificate or Key for making a security decision. 2. Use Cases Developing use cases for a network security protocol is a developing art. Should the use cases be speficied from the point of view of the client or the server? How does the threat model tie in? In this document we begin by classifying attackers according to their capabilities. The use cases are then developed from the point of view of the client and the server. 2.1. Attack Model The asset to be protected is information. Information assets are subject to Confidentiality Integrity and Service risks. For breivty, service risks are not addressed directly, although it should be noted that many controls to mitigate Denial of Service attacks are possible if a client can establish a secure connection to a trustworthy DNS service. 2.1.1. Eve the Evesdropper: Confidentiality [A-EVE] Eve has the ability to read communications between the parties but cannot modify them. Eve typically observes traffic by evesdropping on wireless connections or other brodcast hops but may also have access to the cabling through which the signals run. Hallam-Baker Expires October 9, 2011 [Page 5] Internet-Draft DANE Use Cases and Requirements April 2011 2.1.2. Simon DNS Spoofer: Integrity [A-DNS] Simon the spoofer can control the DNS service responses for a domain. Simon's attacks may affect the entire Internet or be limited in scope. Simon employs a range of techniques to achieve DNS spoofing on a local level. His favorites being cache poisoning and capture of DNS resolvers. He also uses malware attacks that redirect DNS resolution on an infected host or possibly by redirection of a local DNS forwarder at an unsecured network access point. While such attacks are limited in scope, this may actually be preferable since limited scope attacks are more likely to escape detection for an extended period of time. On occasion Simon has redirected DNS domains across the entire Internet through attacks on the registry and/or registrar infrastructure. Such attacks frequently involve social engineering 2.1.3. Denis the Denier of Service: Service [A-DENY] Denis the denier of service can prevent the parties from communicating on some but not all communication channels and/or routes. Denis has used a wide range of techniques to effect his attacks including SYN flooding, BGP level attacks and on occasion disconnecting Internet service for an entire country. Denis has also been known to be extremely careless with a backhoe. 2.1.4. Ulma, the Untrustworthy Third Party [A-UCA] Ulma is an Untrustworthy Third Party whose root signature key is configured to be trusted by default. Opinions on Ulma vary. Some say that she is trying her best, others worry that her best may not be good enough, others still worry that Ulma is intentionally acting in bad faith. 2.1.5. Mallet the Man-in-the-Middle: Confidentiality + Integrity + Service [A-MALLET] Mallet is the man in the middle, the attacker who can control every aspect of a communication. While the activities of Eve, Simon or Ulma may ultimately lead to a successful man in the middle attack, Mallet has the ability to perform such attacks a-priori. He does this by techniques such as Hallam-Baker Expires October 9, 2011 [Page 6] Internet-Draft DANE Use Cases and Requirements April 2011 BGP spoofing and compromise of infrastructure such as hubs and routers. 2.2. Server Use Cases (Alice) [P-Alice] Alice is the administrator of Internet services for a wide variety of customers with very different security needs (and willingness to pay for her services). Some customers want Alice to install and deploy a service as quickly and simply as possible with minimal concern for security. Other customers have more demanding security needs and Alice must meet these as well. 2.2.1. Server Types 2.2.1.1. Human/Machine Interaction: Web Browser A Web Server that is primarily intended to support human-machine interaction MAY permit the display of a security signal in some circumstances. 2.2.1.2. Human/Machine Interaction: Other Other protocols that are primarily intended to support human-machine interaction MAY permit the display of a security signal in some circumstances but the support for such signals is poorly defined. 2.2.1.3. Web Service / Internet Service A service that is primarily designed to support machine/machine interaction. for example delivery of SMTP messages from an outgoing to an incoming mail server, Web Services of all types, etc. Since there is no user in such cases, there is no party to read or interpert a UI security signal. 2.2.2. Administrative Use Cases 2.2.2.1. Trusted Third Party Restriction [U-S-TRUST] Having noted the behavior of Ulma and the risk of compromise due to [A-UCA], Alice wishes to ensure that the only certificates that are issued for a domain or accepted by applications are those issued by Carol [P-CAROL] Hallam-Baker Expires October 9, 2011 [Page 7] Internet-Draft DANE Use Cases and Requirements April 2011 2.2.2.2. Single Service [U-S-SINGLE] Alice is deploying a single service in a domain and wishes to do so with minimal effort. 2.2.2.3. Multiple Services [U-S-MULTIPLE] Alice is deploying many services in a domain and is more concerned with the stability and long-term maintenance of the systems. 2.2.2.4. Rapid Configuration Changes [U-S-RAPID] Alice is deploying many services in a domain with rapidly changing configuration demands. For example, Alice is supporting a Web site that has greatly varying capacity requirements throughout the day. A single server is sufficient to meet demand for most of the day but at peak times demand can rapidly grow to 16 servers or more. Alice meets these requirements by renting services in the cloud in response to current needs. 2.2.2.5. [U-S-ALIAS] Service Mapping [U-S-ALIAS1] Alice has been asked to change the name of a Web site from www.example.net to www.example.com so that a single server can support both sites without the need for separate management. [U-S-ALIAS2] Although the official name for the Web site is www.example.com, many users rely on the autocomplete feature in most Web browsers and only type in example.com and this can lead to performance issues. Service mappings through use of CNAME and/or internal HTTP redirects on a Web server are a frequent administrative requirement. 2.2.2.6. [U-S-DEFAULT] Default Service [U-S-DEFAULT] Alice has been asked to ensure that a visitor attempting to connect to a Web site with any domain name in or under example.com will always succeed, even if the corresponding DNS name is empty. 2.3. Client Use Cases Bob [P-BOB] is a human who uses a range of Web sites, Web Services and Internet services with different security requirements. Hallam-Baker Expires October 9, 2011 [Page 8] Internet-Draft DANE Use Cases and Requirements April 2011 In some cases Bob makes use of a Web Service that will in turn make service requests on his behalf, acting as an Intelligent Agent [P-IA]. 2.3.1. Verify DNS Identity [U-C-DNSID-BOB] Bob has used the site example.com for many years and trusts the site maintainer. How can Bob ensure that he has connected to the real 'example.conm'? [U-C-DNSID-IA] Similar to [U-C-DNSID-BOB] above, the Intelligent Agent is preconfigured through an out-of-band mechanism to trust a Web Service offered by a particular DNS domain. 2.3.2. Establish Trust [U-C-TRUST-BOB] Bob is looking for an Internet source supplying widgest. He discovers such a site through a Web search engine that does meet his trust criteria but Bob is not aware that this is the case. How can Bob determine that he can trust the Web site he has found with his credit card details? [U-C-TRUST-IA]Similar to [U-C-TRUST-BOB] above, but the transaction is to be handled by the Intelligent agent. 2.3.3. Establish Un-Trust [U-C-UNTRUST] In the converse of [U-C-TRUST-BOB], the Web site found does not meet Bob's trust criteria. How can Bob distinguish this case from the case where his criteria are met? [U-C-UNTRUST-IA]Similar to [U-C-UNTRUST] above, but the transaction is to be handled by the Intelligent agent. 2.3.4. Best Connection [U-C-BEST] Bob connects to a Web site. Bob wants connections to the example.com Web site to be 'as secure as possible'. 2.3.5. User Presence [U-C-ACCOUNT] TBS 2.3.6. Secure Email [U-C-EMAIL] TBS Hallam-Baker Expires October 9, 2011 [Page 9] Internet-Draft DANE Use Cases and Requirements April 2011 3. Constraints 3.1. DNS Size Constraints [C-SIZE] DNS responses must fit into a single IP packet if TCP fallback is to be avoided and such mackets must be smaller than the path MTU if fragmentation is to be avoided. While some of the worst consequences of this restriction have been mitigated through EDNS(0), use of DNSSEC and in particular the need to attach DNS SIG records for each recordset mean that its consequences cannot be entirely ignored. 3.2. DNSSEC Deployment [C-DNSSEC] DNSSEC is only partially deployed. While DNSSEC is deployed at most DNS TLDs, deployment has not been effected in many TLDs. Moreover in some TLDs where DNSSEC is 'deployed' it is only supported by the registry and not by registrars. 3.3. DNS Prefixing [C-PREFIX] The practice of using prefixes to DNS names to allow protocol and/or service specific properties to be specified is not fully interoperable with existing practices for using aliases or wildcards. As far as the DNS infrastructure is concerned, a DNS name that incorporates a prefix is no different from any other DNS name and that creates problems for DNS administration since it is generally desirable that wildcards and aliases apply to all protocol properties associated with a domain name, including those expressed using a prefix. The DNS infrastructure does not support midpoint wildcard record of the form 'x.*.y.z'. The only wildcard form supported being the case where the wildcard is a prefix, i.e. '*.y.z'. While it is possible to create wildcards that create the desired matches for a given prefix record, it is not possible to do so without ambiguity. The patern *.y.z will match _p1.y.z as desired, but it will also match _p2.y.z and any other prefix. A DNS CNAME Resource record declares the canonical name for a given domain name. Since the purpose of a DNS CNAME record is to 'alias' one name to another, it is clearly desirable for an alias to have effect for all prefixes associated with the domain name as well. In practice a CNAME mapping x.y.z to p.q.r has no effect on queries for _prefix.x.y.z and the only way to ensure that these forward correctly Hallam-Baker Expires October 9, 2011 [Page 10] Internet-Draft DANE Use Cases and Requirements April 2011 is to create mappings for each case. 3.4. Extended Discovery [C-DISC] Use of an extended discovery mechanism such as SRV, NAPTR and/or URI may be an Internet architecture requirement at some date in the future. Just as IPv4 addresses are running out, IP port numbers are facing a similar exhaustion issue. IP only allows 16 bits for specification of port numbers and this is not extended in IPv6. It is thus inevitable that the 'well known ports' mechanism will eventually run out of code points for assignment and that this will be replaced by some other mechanism. Extended discovery mechanisms such as SRV, NAPTR and URI provide an alternative means of service discovery, albeit with significant practical limitations in their current form. In particular the extended discovery mechansisms proposed to date all employ some form of prefix mechanism as a substitute for well known port numbers and thus subject to the corresponding constraints [C-PREFIX]. Another practical limitation to the use of SRV, NAPTR, URI, etc. is that the decision to support extended discovery and the selection of the extended discovery mechanism to be used rests with the protocol designer rather than the admninistrator of the domain where they are to be deployed. 4. Requirements For convenience, requirements are separated into cryptographic requirements and protocol requirements. No attempt has been made to separate requirements according to priority except to note where a requirement is mandated by the DANE charter or is met by existing infrastrtucture. 4.1. Cryptographic Requirements The cryptographic requirements are set out with the intention of drawing attention to the precise semantics involved. 4.1.1. Key Publication [R-C-KEYPUB] Allow relying party to access the value of the key material which may or may not be valid for the domain for which it is published. Hallam-Baker Expires October 9, 2011 [Page 11] Internet-Draft DANE Use Cases and Requirements April 2011 Key Publication does not necessarily entail any assertion concerning the validity and/or use of the certificate in question. The certificate may have expired, it may have been revoked, it may bear no correspondance to the domain at which it is published whatsover. Example: www.example.com CERT 1 0 [ICANN KSK Certificate] Since publication of a key or certificaste does not in itself imply an assertion that it is to be considered trustworthy, satisfying this requirement does not necessitate the use of DNSSEC. Publication of cryptographic keying material is supported by the existing DNS CERT record. Existing CERT certificate types do not imply an assertion on the part of a domain name owner that the published keying material is valid for or indeed has any relationship to the specified domain whatsoever. 4.1.2. Domain Validation [R-C-DV] Assert that a key is valid for use with a specific domain Example: www.example.com RR-TBS [CA root for *.example.com] Domain Validation entails an assertion that the specified certificate or key is valid for the associated domain but does not necessarily entail an assertion that the subject is trustworthy. Since the only criteria required to register a domain in most domains is to pay a registration fee, Domain Validation alone does not normally provide a useful basis for trust. 4.1.3. Subject Validation [R-C-SV] Determine criteria that may indicate that the subject should be trusted. E.g. reputation mechanisms, evidence of accountability. Subject Validation involves verification that is above and beyond the requirement for registration of a domain name. The Extended Validation criteria set out requirements that are intended to provide a high degree of assurance that the subject is accountable according to legal process. Example: www.example.com RR-TBS [EV Cert for www.example.com] Hallam-Baker Expires October 9, 2011 [Page 12] Internet-Draft DANE Use Cases and Requirements April 2011 4.1.4. Subject Attestation [R-C-SA] Vouch for the trustworthiness of the subject, i.e. shoulc we show Padlock Icon, Green Bar 4.1.5. Certificate Validation [R-C-CV] Additional means of certificate validation/revocation that are outside the normal PKIX path. E.g. specify trust roots, enumeration of valid certs. 4.1.6. Certificate Issue Control [R-C-CI] Inform certificate issuers that a domain name owner requires specified validation criteria to apply in addition to those normally applied. 4.2. Protocol Requirements In order for a client to make contact with a server, the client must discover the IP address and port number to connect to. 4.2.1. Service Discovery Although the design of discovery mechanisms is outside the scope of DANE, the use of the DNS to obtain cryptographic service properties is predicated on the use of the DNS to perform service discovery. The means of DNS service discovery employed and interoperation of that means with DANE will have impact on performance. Also relevant to consideration in DANE is the range of discovery mechanisms supported. 4.2.1.1. A RR Discovry [R-P-A] Support use of Internet service discovery by means of DNS A record and well known port assignment. 4.2.1.2. A/AAAA RR Discovry [R-P-AAAA] Support use of Internet service discovery by means of DNS A record and AAAA record and well known port assignment. The introduction of IPv6 has led many protocol stacks to issue parallel requests for A and AAAA DNS records. While this practice is out of scope for DANE protocol, the performance impact may be relevant. Hallam-Baker Expires October 9, 2011 [Page 13] Internet-Draft DANE Use Cases and Requirements April 2011 4.2.1.3. Extended Discovery [R-P-EDISC] Support use of extended discovery mechanisms (e.g. SRV, NAPTR, URI) mandated in protocol specification. 4.2.1.4. Extended Meta-Discovery [R-P-MDISC] Support use of extended discovery mechanisms (e.g. SRV, NAPTR, URI) selected by local DNS administrator. 4.2.2. DNS Administration 4.2.2.1. First Party Deployment [R-P-LOCAL] Support deployment by local network administration without reference to any other party. 4.2.2.2. First Party with DNSSEC Deployment [R-P-LOCALD] Support deployment by local network administration without reference to any other party except for enrollment of DNSSEC KSK. 4.2.2.3. Use of CNAME and other Aliases [R-P-CNAME] Support use of single CNAME records to establish aliases for a domain name and all associated protocol properties. 4.2.2.4. Use of Wildcards [R-P-WILD] Support use of wildcards to establish default properties for all empty domain names within a tree. 4.2.3. Protocol Specific Properties 4.2.3.1. Security Properties 4.2.3.1.1. Opportunistic Enhancement [R-P-OPP] Support protocol-specific properties to declare that a security enhancement is offered. Since most Internet traffic is exchanged without any form of cryptographic security, there is a school of thought that holds that any form of security enhancement must be an improvement, provided that the user is not led to believe that the degree of security offered is greater than it is. Hallam-Baker Expires October 9, 2011 [Page 14] Internet-Draft DANE Use Cases and Requirements April 2011 For example, an encryption mode that is vulnerable to a man in the middle attack is generally to be preferred to performing the same communication in plaintext. The use of DNS based keying and self signed certificates for such purposes has a long history in the IETF. 4.2.3.1.2. Strict Security [R-P-STRICT] Support protocol-specific properties to declare that a security enhancement is offered and that strict compliance is requested. Strict security is similar to opportunistic enhancement except that it is intended to provide protection against downgrade attack by informing the client that it MUST NOT accept a service connection that does not meet certain security and/or trust criteria. 4.2.3.2. Version Properties [R-P-VER] Support protocol specific properties such as identifying the version(s) of a protocol supported by a given service instance. 5. Metrics Relevant performance and implementation metrics are specified as a means of guiding the selection process. 5.1. Performance Metrics When defining performance metrics it is important to consider the performance of the system in which they are to be used rather than identifying easily measured but irrelevant properties of isolated components. Since the end goal of the application client is to establish a secure connection with the server, it is important to consider the performance metrics for both discovery and keying related purposes. A proposal that obtains the keying material in one round trip that can be performed in parallel with discovery by A-record will in the general case be more performant than one that only requires one round trip but the resquest cannot be made until after the A-record lookup has completed. Hallam-Baker Expires October 9, 2011 [Page 15] Internet-Draft DANE Use Cases and Requirements April 2011 5.1.1. Bandwidth DNS requests and responses are typically limited to a single packet in each case and thus bandwidth is normally irrelevant as far as measurement of performance goes. 5.1.2. Latency Latency is a key performance metric for many interactive network applications. Browser authors report that DNS latency has a major impact on overall user satisfaction [TBS]. The extent that a protocol design choice has impact on latency depends on properties of the DNS that are heavily context dependent and thus do not translate directly into a latency metric. In particular the time taken to complete a DNS round trip, the failure rate of DNS requests and the retransmit interval are all situation dependent and will have impact on how protocol design properties result in latency. 5.1.2.1. TCP Fallback [M-TCP] Probability that a request will result in TCP/IP fallback. Attempts to exchange DNS packets larger than the maximum packet size supported results in an error and a retry using TCP/IP. In the best case, TCP fallback will result in a major impact on latency and server performance. In the worst case, TCP fallback may fail as the mechanism is rarely required in normal DNS configuration and is frequently misconfigured in middleboxes such as firewalls. 5.1.2.2. Round Trip Count [M-RT] Number of sequential DNS round trips required to address supported use cases. The number of round trips may depend on the circumstances. For example a proposal might require 3 round trips in the worst case but resolve in 1 round trip in 95% of cases. This may be preferable to a protocol that resolves in 2 round trips in every case. Implementations may in some cases mitigate the impact of a proposal requiring multiple round trips through speculative lookups. For example, a protocol requirement to obtain the canonical form of 'www.example.com' before applying a protocol specific prefix '_http._tcp' will require two round trips but this can be achieved in a single round trip if www.example.com is in fact canonical and the Hallam-Baker Expires October 9, 2011 [Page 16] Internet-Draft DANE Use Cases and Requirements April 2011 implementation makes a speculative request for '_http._tcp.www.example.com' at the same time as resolving for the 5.1.2.3. DNS Lookup Count [M-LC] Total number of DNS queries required to address supported use cases including lookups performed in parallel. If DNS queries were perfectly reliable, a proposal that required ten lookups to be performed in parallel would have essentially the same performance characteristics as a proposal that only required one. In practice, DNS queries are not perfectly reliable and a proposal that requires ten lookups rather than one has roughly ten times the probability of a random failure. Should a failure occur, the client must wait before retransmitting the request. The typical timeout periods being many times the time taken for a round trip. Although preliminary studies [AL] suggest a failure rate for unknown DNS RR codes of approximately 1.5% it is not known what proportion of such requests will never resolve under any circumstances. 5.1.3. Caching [Should say something obvious here] 5.2. Implementation Metrics 5.2.1. Number of States [M-STATES] Code Complexity measured by reference to the number of states required to create an implementation that is not optimized for performance. 5.2.2. Number of Transitions [M-TRANS] Code Complexity measured by reference to the number of state transitions required to create an implementation that is not optimized for performance. 6. Security Considerations [TBS] Hallam-Baker Expires October 9, 2011 [Page 17] Internet-Draft DANE Use Cases and Requirements April 2011 7. IANA Considerations None 8. References 8.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA Considerations", RFC 5395, November 2008. [X.509] International Telecommunication Union, "ITU-T Recommendation X.509 (11/2008): Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, November 2008. [X.680] International Telecommunication Union, "ITU-T Recommendation X.680 (11/2008): Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, November 2008. [X.690] International Telecommunication Union, "ITU-T Recommendation X.690 (11/2008): Information technology - Abstract Syntax Notation One (ASN.1): Specification of Hallam-Baker Expires October 9, 2011 [Page 18] Internet-Draft DANE Use Cases and Requirements April 2011 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, November 2008. 8.2. Non Normative References [NIST-ALGS] National Institute of Standards and Technology, "Cryptographic Algorithm Registration", March 2009. [RFC3642] Legg, S., "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, October 2003. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. Author's Address Phillip Hallam-Baker Comodo Group Inc. Email: philliph@comodo.com Hallam-Baker Expires October 9, 2011 [Page 19]