| Internet Engineering Task Force | P. M. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Intended status: Experimental Protocol | April 06, 2011 |
| Expires: October 08, 2011 |
DANE Use Cases, Requirement and Deployment
draft-hallambaker-dane-requirements-00
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 08, 2011.
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.
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
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].
The following terms are used in this document:
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.
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.
[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.
[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
[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.
[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.
[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 BGP spoofing and compromise of infrastructure such as hubs and routers.
[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.
A Web Server that is primarily intended to support human-machine interaction MAY permit the display of a security signal in some circumstances.
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.
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.
[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]
[U-S-SINGLE] Alice is deploying a single service in a domain and wishes to do so with minimal effort.
[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.
[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.
[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.
[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.
Bob [P-BOB] is a human who uses a range of Web sites, Web Services and Internet services with different security requirements.
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].
[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.
[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.
[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.
[U-C-BEST] Bob connects to a Web site. Bob wants connections to the example.com Web site to be 'as secure as possible'.
[U-C-ACCOUNT] TBS
[U-C-EMAIL] TBS
[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.
[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.
[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 is to create mappings for each case.
[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.
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.
The cryptographic requirements are set out with the intention of drawing attention to the precise semantics involved.
[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.
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.
[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.
[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]
[R-C-SA] Vouch for the trustworthiness of the subject, i.e. shoulc we show Padlock Icon, Green Bar
[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.
[R-C-CI] Inform certificate issuers that a domain name owner requires specified validation criteria to apply in addition to those normally applied.
In order for a client to make contact with a server, the client must discover the IP address and port number to connect to.
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.
[R-P-A] Support use of Internet service discovery by means of DNS A record and well known port assignment.
[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.
[R-P-EDISC] Support use of extended discovery mechanisms (e.g. SRV, NAPTR, URI) mandated in protocol specification.
[R-P-MDISC] Support use of extended discovery mechanisms (e.g. SRV, NAPTR, URI) selected by local DNS administrator.
[R-P-LOCAL] Support deployment by local network administration without reference to any other party.
[R-P-LOCALD] Support deployment by local network administration without reference to any other party except for enrollment of DNSSEC KSK.
[R-P-CNAME] Support use of single CNAME records to establish aliases for a domain name and all associated protocol properties.
[R-P-WILD] Support use of wildcards to establish default properties for all empty domain names within a tree.
[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.
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.
[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.
[R-P-VER] Support protocol specific properties such as identifying the version(s) of a protocol supported by a given service instance.
Relevant performance and implementation metrics are specified as a means of guiding the selection process.
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.
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.
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.
[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.
[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 implementation makes a speculative request for '_http._tcp.www.example.com' at the same time as resolving for the
[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.
[Should say something obvious here]
[M-STATES] Code Complexity measured by reference to the number of states required to create an implementation that is not optimized for performance.
[M-TRANS] Code Complexity measured by reference to the number of state transitions required to create an implementation that is not optimized for performance.
[TBS]
None
| [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. |
| [NIST-ALGS] | National Institute of Standards and Technology , "Cryptographic Algorithm Registration", March 2009. |