| Internet Engineering Task Force | P. M. Hallam-Baker |
| Internet-Draft | B. Smith |
| Intended status: Informational | Comodo Inc. |
| Expires: September 10, 2011 | March 09, 2011 |
DNS Extended Service Discovery (ESRV) Record.
draft-hallambaker-esrv-01
General Service Description (GSRV) and Extended Service Description records are DNS Resource Records that provide information to applications attempting to establish a network connection. When authenticated using an appropriate means GSRV and ESRV records may be used to prevent a downgrade attack in cases where use of security enhancements with an application protocol are optional.
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 September 10, 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 following definitions are used in this document:
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].
General Service Description (GSRV) and Extended Service Discrpition (ESRV) DNS Resource Records provide a mechanism for specifying properties relating to Internet services associated with a DNS name.
GSRV and ESRV records are intended to serve the same function at different levels of generality. GSRV records specify properties that apply to all Internet services provided in the Domain. ESRV records are used to specify properties that apply to finer levels of detail.
Extended Service Description allows properties to be expressed at three levels of granularity:
GRSV/ESRV records make use of the service prefixing mechanism introduced in SRV and employed in later advanced service discovery mechanisms such as NAPTR and URI.
The need for separate DNS Resource Record types to express properties at different levels of granularity arises from the need to support use of wildcards and DNS aliases such as CNAME and DNAME records when specifying properties that apply to a whole domain and the need to use prefix labels to specify properties at finer granularity.
The GSRV/ESRV discovery mechanism is designed for use by itself or in combination with service discovery mechanisms such as SRV, NAPTR and URI.
One of the main limitations of service discovery schemes such as SRV, NAPTR and URI is that they can only be used if a client knows to look for them.
Without provision for meta-service discovery, the service discovery mechanisms supported by a protocol are limited to those which exist at the time the protocol is developed and that the protocol designer decides to support. In most cases however, it is the site administrator rather than the protocol designer who is best placed to know which form of extended discovery is most applicable to their service.
GSRV records may be used to inform clients that a service discovery mechanism is supported for specific protocols or for all protocols. In the following example clients are advised to attempt service discovery using the SRV mechanism for the HTTP protocol and to attempt URI service discovery for all others:
example.com GSRV 0 srv "_http._tcp"
example.com GSRV 0 uri "*"
Publication of ESRV properties for abstract services allows a site to enable clients to perform protocol negotiation by specifying the range of services offered that support a specific purpose.
For example, the SMTP, POP3 and IMAP4 protocols are all used for exchange of mail. An abstract service for the mail protocol with the prefix '_mail._as' allows clients to discover the full range of mail related protocols in a single query.
example.com GSRV 0 service "_mail._as"
_mail._as.example.com ESRV 0 prot "_smtp._tcp"
_mail._as.example.com ESRV 0 prot "_pop._tcp"
_mail._as.example.com ESRV 0 prot "_imap._tcp"
Extended Service description records MAY be resolved in an Incremental mode or an Optimized mode. Incremental mode allows records to be advertised and resolved by existing DNS servers, optimized mode allows for improved performance when
Implementations MUST support the Incremental mode and MAY support the Optimized mode.
The incremental mode allows extended service discovery to be used in conjunction with DNS resolvers that do not support the Optimized mode.
In the incremental mode the DNS client attempting service discovery begins by querying for Domain level properties.
For example, a client attempting to perform extended service discovery for the HTTP protocol server at www.example.com would begin by querying for the GSRV record at www.example.com.
Domain properties MAY include property entries for the service property type. The service property entry indicates that additional property entries are specified at the service level for either a specific serviceby means of the protocol prefix or for all services by means of the wildcard entry "*".
If the domain resolution indicates that property entries are declared for the service prefix being resolved or for the wildcard prefix type, service level resolution is performed.
There are three possible outcomes in which the query is successful and returns a GSRV record:
In the last case we require that the GSRV record set returned contain a canonical property entry specifying a canonical name. We are thus assured that
prefix the canonical name to perform the service lookup
In the following example a query for the _prefix protocol at domain names canonical.example.com, cname.example.com or wildcard.example.com will all result in the resolution process continuing with a query for an ESRV record for _prefix.canonical.example.com.
$ORIGIN example.com
canonical GSRV 0 service "*"
cname.example.com CNAME canonical.example.com
*.example.com GSRV 0 canonical "canonical.example.com"
*.example.com GSRV 0 service "*"
If use of a service discovery mechanism is indicated a site MAY choose to advertise properties specific to a particular service instance through use of the instance property type.
Client implementations MAY attempt to optimize incremental mode discovery by initiating service resolution in parallel with domain resolution by applying the protocol prefix to the query domain.
If the response to the domain resolution query indicates that the query domain is not-canonical, any answer returned to the pre-fetched query is ignored and a new query made if inidcated by the answer returned to the domain resolution query.
If the service level resolution indicates that instance level property entries MAY exist, these are resolved by querying for the chosen host name prefixed by the service prefix and a second prefix formed from the decimal port identifier.
For example a the www.example.com HTTP server is supported by two separate service instances (host1, host2). TLS security is always offered on host1 instance but not on host2:
$ORIGIN example.com
www GSRV 0 service "*"
www GSRV 0 srv "_http._tcp"
_http._tcp.www ESRV 0 instance ""
_http._tcp.www SRV 1 1 80 host1.example.com
_http._tcp.www SRV 1 1 80 host2.example.com
_http._tcp._80.host1 ESRV 0 tls "required"
DNS servers MAY advertise support for the optimized mode query by means of the EDNS0 meta-query extension.
When optimized mode queries are supported, the client MAY present a meta-query consisting of the protocol prefix concatenated to an iteration count concatenated to the query domain. The server receiving the query then performs the GSRV/ESRV discovery process on the client's behalf and returns the whole result chain in a single response.
For example, a query for the HTTP service at example.com would be made as:
METASRV ? _http._tcp._0.www.example.com
Since the two hosts have the same weighting, there is a 50% probability that the response to this query would be:
_http._tcp._0.www.example.com METASRV 2
www.example.com GSRV 0 service "*"
www.example.com GSRV 0 srv "_http._tcp"
_http._tcp.www.example.com ESRV 0 instance ""
_http._tcp.www.example.com SRV 1 1 80 host2.example.com
_http._tcp._80.host1 ESRV 0 tls "required"
Should the attempt to connect to host1.example.com fail, the client MAY make a second attempt:
METASRV ? _http._tcp._1.www.example.com
Since there is now only one service instance remaining, the response would be:
_http._tcp._1.www.example.com METASRV 2
www.example.com GSRV 0 service "*"
www.example.com GSRV 0 srv "_http._tcp"
_http._tcp.www.example.com ESRV 0 instance ""
_http._tcp.www.example.com SRV 1 1 80 host1.example.com
_http._tcp._80.host1 ESRV 0 tls "required"
[TBS: work out how to allow the server to calculate the random number deterministically on the query, may need to add a state parameter here.]
The EDNS0 Meta-Query extension has code TBS and is used to advertise support for one or more meta-queries.
The parameter data for the Meta-Query Extension consists of a list of DNS query numbers for the supported meta queries.
Interactive HTTP Attributes are properties specific to the HTTP protocol that are declared as Domain Properties rather than service properties. Specifying the properties for HTTP as interactive HTTP properties allows clients using resolvers that do not support the optimized resolution mode to resolve HTTP properties in a single round trip rather than two.
For example, the following configuration specifies that tls is always offered for the application protocols HTTP and POP.
$ORIGIN example.com
. GSRV 0 service "*"
. GSRV 0 http_tls "required"
_pop._tcp ESRV 0 tls "offered"
The above example is functionally equivalent to specifying the HTTP properties as instance properties:
$ORIGIN example.com
. GSRV 0 service "*"
_http._tcp ESRV 0 tls "required"
_pop._tcp ESRV 0 tls "offered"
Special provision is justified in this instance by the widespread use of HTTP and the effect that service discovery latency has on the Web Browser user experience.
The GSRV and ESRV have the same record syntax which is the same as the syntax of the CAA record. A GSRV or ESRV RR contains a single property entry consisting of a tag value pair. Each tag represents a property of the CAA record. The value of a property entry is that specified in the corresponding value field.
A domain name MAY have multiple GSRV or ESRV RRs associated with it and a given property MAY be specified more than once. Where multiple properties are specified they are additive. That is if SRV and URI records are advertised for a service then both mechanisms for advanced discovery are offered.
The GSRV/ESRV data field consists of a sequence of at least one property entry. Each property entry consists of a sequence of:
The presentation format of the GSRV and ESRV resource records is as follows:
GSRV <flags> <tag> <data>
ESRV <flags> <tag> <data>
Where:
The purpose of extended service discovery is to refine an abstract specification of a DNS host name and protocol prefix to a concrete specification for the name of a specific network host, a specific network port number and a specific network protocol and associated protocol parameters.
The GSRV and ESRV Resource Record is used in combination with service discovery records (e.g. SRV, URI NAPTR) to perform extended service discovery. An API call for extended service discovery has the following signature:
The GSRV and ESRV Resource Records may be used to perform abstract service discovery providing a list of supported protocols that implement the abstract service. An API call for abstract service discovery has the following signature:
GSRV/ESRV properties take different parameter values according to the specific label.
Processing properties direct the process of property resolution. Since a processing property is used to direct the resolution process, they only have effect when encountered at a relevant stage of resolution. A service property that directs a client to resolve for service properties has no effect.
Three processing properties are defined.
Discovery Properties specify the resolution mechanism(s) to be used for service resolution. Discovery properties only have effect when encountered in the Domain resolution phase and always take a protocol_specifier as the property type.
If multiple discovery properties are specified, the most specific property or properties are to be used.
If no discovery property is specified, 'a' record service discovery (i.e. IPv4) is indicated.
Security properties allow a service provider to describe the security critieria for a service. When an ESRV record is secured using an appropriate means (e.g. DNSSEC), the security properties MAY be used to prevent a downgrade attack on the security enhancements offered.
It is anticipated that the list of tags will be expanded at a future date to support other Internet security protocols such as IPSEC and WS-Security.
A tls_specifier property value consists of a sequence of case insensitive atributes or attribute-value pairs separated by spaces as follows:
[EBNF To Be Specified]
Extended Service Discrpition (ESRV) DNS Resource Records extend the principles of named service discovery first proposed in SRV RFC 2782 [RFC2782] and later extended in NAPTR RFC 3403 [RFC3403] and related specifications. The ESRV record provides an extensible container that MAY be used to provide a description of an abstract Internet service bound to a domain name or a specific instance of that Internet Service on a specific host.
Existing SRV records provide a means of allowing a client to discover a host and port number for a specific Internet protocol. ESRV records allow a further layer of abstraction in which the discovery is of an Internet Service and the service provider MAY declare a range of supported protocol options.
For example, POP RFC 1939 [RFC1939] and IMAP RFC 2060 [RFC2060] both provide means by which a mail client can access mail messages but the only means by which a client might discover that both protocols are supported is to attempt to connect to each in turn.
Although discovery by polling is practical when there are only two options, it is impractical in application areas such as federated authentication (also known as 'identity') where the number of protocols that might be employed is very large (e.g. Kerberos, SAML, OpenID, etc.) and the number of ways in which those protocols might be employed is even larger still. Not only is polling inefficient in such circumstances, a client that fails to find a means of connection has no way to know how it might have succeeded.
ESRV records provide a means by which Internet clients and Servers can negotiate choice of protocols and protocol properties. In particular, when publication of the ESRV record is appropriately secure (e.g. through a use of DNSSEC RFC 4033 [RFC4033]), the ESRV record provides a means of securely negotiating critical security properties.
Today use of Internet security is the exception rather than the rule. As a result, an attacker can frequently bypass security enhancements by persuading the parties that they do not exist.
This form of attack is a downgrade attack. While protocols such as SSL RFC 5246 [RFC5246] and S/MIME have measures that are intended to prevent downgrade attacks in which weaker algorithms are substituted for strong, there is currently no in-band mechanism for specifying that these enhancements are available or that they should or must be used.
While it is possible to infer such information from existing DNS records such as the port number specification in an SRV record, such approaches represent heuristics and as such are not appropriate as a means of achieving an essential security objective.
TBS
TBS
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. |
| [RFC2905] | Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000. |
| [RFC1939] | Myers, J.G. and M.T. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. |
| [RFC2060] | Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996. |
| [RFC4033] | Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. |
| [RFC3851] | Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. |