DNS Extended Service Parameters (ESRV) Record.
draft-hallambaker-esrv-00

Abstract

Extended Service Description (ESRV) records are DNS Resource Records that provide information to applications attempting to establish a network connection. When authenticated using an appropriate means ESRV records may be used to prevent a downgrade attack in cases where use of security enhancements with an application protocol are optional.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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.

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 March 11, 2011.

Copyright Notice

Copyright (c) 2010 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.

Table of Contents

1.  Definitions
    1.1.  Requirements Language
2.  Extended Service Discription
    2.1.  ESRV Prefixes
    2.2.  ESRV Properties
    2.3.  Protocol Properties
    2.4.  Security Properties
3.  ESRV Syntax
    3.1.  DNS Resource Record Syntax
    3.2.  Tag Specifications
        3.2.1.  ESRV Processing Rules
        3.2.2.  ref
        3.2.3.  prot
        3.2.4.  disc
        3.2.5.  ssl
4.  Security Considerations
5.  IANA Considerations
6.  References
    6.1.  Normative References
    6.2.  Non-Normative References
§  Authors' Addresses

1.  Definitions

The following definitions are used in this document:

DNS Resource Record

[TBS]

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Extended Service Discription

Extended Service Discrpition (ESRV) DNS Resource Records extend the principles of named service discovery first proposed in SRV RFC 2782 (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) [RFC2782] and later extended in NAPTR RFC 3403 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” October 2002.) [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 (Myers, J. and M. Rose, “Post Office Protocol - Version 3,” May 1996.) [RFC1939] and IMAP RFC 2060 (Crispin, M., “Internet Message Access Protocol - Version 4rev1,” December 1996.) [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 (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) [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 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [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.

2.1.  ESRV Prefixes

ESRV makes use of the same system of protocol prefixes originally proposed for use with SRV and subsequently applied to NAPTR and URI.

For example, the ESRV record for a HTTP service at example.com would use the prefix _http._tcp. The following record specifies that a connection to the web service at example.com requires use of SSL.

_http._tcp.example.com   ESRV "ssl=required"

When processing ESRV records, a distinction is maintained between the domain name and the prefix. In the case above, the domain name is 'example.com' and the prefix is '_http._tcp'.

An ESRV record may be used to declare support for a group of protocols that support different aspects of a single Internet service. For example, a mail service will typically comprise the SMTP, SUBMIT and at least one of IMAP and POP.

In order to support such services a new DNS protocol prefix registry for abstract services is proposed with the extension _as. For example, the abstract service mail would be specified as follows:

_mail._as.example.com   ESRV
                "prot=_submit._tcp,_smtp._tcp,_imap._tcp,_pop._tcp,"

2.2.  ESRV Properties

ESRV properties specify properties that control the interpretation of the ESRV tag itself.

Only one ESRV property is defined:

ref

The ref tag supports delegation and wildcard semantics for ESRV Records

As has been noticed by other authors, it is not possible to use DNSSEC to authenticate a DNS wildcard record of the form x.*.y.z. This has proved inconvenient when prefixed records such as SRV are employed and their use is thus discouraged.

The ref tag allows these limitations to be avoided and provides a means of supporting delegation.

For example, the following ESRV wildcard record redirects all attempts to establish a service connection made to a non-existent DNS node in *.example.com to the ESRV record at example.com.

*.example.com   ESRV "ref=example.com"

When the response to an initial ESRV query contains a ref tag, the client first checks to see if the referenced domain name is the same as the domain name of the original query. If the two domain names are the same the ref tag field is ignored and the remaining tags are processed as if the ref tag had not been specified.

Otherwise the original domain name is replaced by the domain name specified in the ref tag value and a new referenced ESRV query is made. All subsequent prefixed queries (e.g. for SRV records) are made relative to the referenced domain name and not the original.

Processing of ESRV tags is not recursive. A client MUST process the first ref tag occuring in the result returned in an initial query and a client MUST NOT process any ref tag returned in a reference query.

When processing of a tag other than a ref tag results in an ESRV query being made, the query is made as an initial query but the same non recursion principle is applied.

When querying for a prefixed record following a ref tag redirect, the target domain of the ref tag is used as the base for further prefixes.

For example, consider the zone example.com with the following records:

_http._tcp.example.com   ESRV "ssl=optional"
*.example.com   ESRV "ref=example.com"
_imap._tcp.example.com   ESRV "ref=example.net"

_imap._tcp.example.net   ESRV
                      "ref=internal.example.net ssl=optional disc=srv"
_imap._tcp.internal.example.net   ESRV
                      "ssl=required disc=srv"

Attempting to resolve services and domains has effect as follows:

_http._tcp at example.com

The client queries the ESRV record for _http._tcp.example.com. There is a record at this node so the wildcard record is not returned. There is an ESRV record and so the ESRV record stating that SSL is always offered is returned.

_http._tcp at www.example.com

The client queries the ESRV record for _http._tcp.www.example.com and the wildcard record for *.example.com is returned. The client then queries for _http._tcp.example.com and the ESRV record ecord stating that SSL is always offered is returned.

_imap._tcp at example.com

The query for the IMAP service at example.com leads to a redirect to example.net. Although this record also contains a ref tag, it is ignored. The client is informaed that the IMAP service always offers SSL. The host providing the service is discovered by querying for the SRV record(s) at _imap._tcp.example.net.

_imap._tcp at example.net

The query for the IMAP service at example.net leads to a redirect to internal.example.net. This allows the operator of example.net to require use of IMAP for example.net even though it is only an option for other domains that delegate their IMAP service to example.net. The client is informed that the IMAP service always offers SSL. The host providing the service is discovered by querying for the SRV record(s) at _imap._tcp.internal.example.net.

2.3.  Protocol Properties

Protocol properties allow a service provider to describe the protocols and service discovery mechanisms supported by an Internet protocol instance.

prot

The prot tag specification lists protocols supported by an Internet service. For example an abstract 'mail' Internet service might list SUBMIT, POP, IMAP and LDAP as supported protocols. The prot tag is the protocol equivalent of the ref tag, specifying a new protocol prefix as opposed to a new domain name.

Support for the prot specifier is optional.

disc

The disc tag specification lists the means of service discovery supported by a protocol. For example discovery by means of SRV, NAPTR or URI may be specified.

As with the ref tag, the principle of non recursion is applied. If resolution of an ESRV record returns a prot tag that specifies a new prefix, a client MUST NOT resolve any further prot tags in the ESRV record returned.

When processing of a prot or disc tag results in a new ESRV query, thje query made is always an initial query and ref tags MUST be processed.

The ref, prot and disc tags may be used in combination to effect a gradual refinement of the service characteristics. For example, consider the following DNS zone:

_mail._as.example.com             ESRV
                    "prot=_submit._tcp,_smtp._tcp,_imap._tcp,_pop._tcp"
_submit._tcp.example.com          ESRV "disc=srv-e"

_submit._tcp.example.com          SRV 1 1 587 submit1.example.com
_submit._tcp.submit1.example.com  ESRV "ssl=required"
submit1.example.com               A    10.1.1.1

_submit._tcp.example.com          SRV 1 1 587 submit2.example.com
_submit._tcp.submit2.example.com  ESRV "ssl=required"
submit1.example.com               A    10.1.1.2

A mail client attempting to configure a service through which to submit mail could in principle make queries for five DNS records of which two queries may be made in parallel).

2.4.  Security Properties

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.

Only one security property is currently defined:

ssl

Specifies the use of ssl. Valid values are refused, optional and required.

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.

If the values optional or required are specified, the corresponding service MUST support TLS version 1.1 or above.

3.  ESRV Syntax

3.1.  DNS Resource Record Syntax

The ESRV record has the same DNS record syntax as the existing TXT field specified in RFC 1035 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) [RFC1035].

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                   ESRV-DATA                   /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

ESRV-DATA One or more <character-strings>.

ESRV record data consists of a sequence of (tag, value) tuples encoded in tag=value format following the format established in DKIM (RFC 4871 (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) [RFC4871])

tag-list  =  tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA 0*ALNUMPUNC
tag-value =  [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end

tval      =  1*VALCHAR
VALCHAR   =  %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON

ALNUMPUNC =  ALPHA / DIGIT / "_"

3.2.  Tag Specifications

3.2.1.  ESRV Processing Rules

The purpose of ESRV 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 ESRV Resource Record is used in combination with the SRV and URI Resource Records to perform extended service discovery. An API call for ESRV processing has the following signature:

name (input/output)

The DNS name of the service.

protocol (input/output)

The DNS prefix of the protocol.

protocol_list (input)

The DNS prefixes of the supported protocols.

port (output)

The IP port number to conect to at the host

uri (output)

The canonical uri of the service to connect to

attributes (output)

A list of attribute value pairs that specify characteristics of the connection to the service.

During the course of ESRV service discovery, a client MAY encounter between zero and six ESRV records. Processing of ESRV record tags is managed using a Finite State Machine as follows:

START

If a ref tag is present, the ref tag is processed and all other tag specifications MUST be ignored, the next state is START-REF. Otherwise the processing rules for all the remaining tag specifications are processed and the next state is set to PROT if a prot tag specification is present, DISC if a disc tag specification is present and FINAL otherwise.

START-REF

If a ref tag is present it MUST be ignored. The processing rules for all the remaining tag specifications are processed and the next state is set to PROT-REF if a prot tag specification is present, DISC if a disc tag specification is present and FINAL otherwise.

PROT

If a ref tag is present, the ref tag is processed and all other tag specifications MUST be ignored, the next state is PROT-REF. Otherwise the processing rules for all the remaining tag specifications except for prot are processed and the next state is set to DISC if a disc tag specification is present and FINAL otherwise.

PROT-REF

If a ref tag is present it MUST be ignored. The processing rules for all the remaining tag specifications except for prot are processed and the next state is set to DISC if a disc tag specification is present and FINAL otherwise.

DISC

If a ref tag is present, the ref tag is processed and all other tag specifications MUST be ignored, the next state is DISC-REF. Otherwise the processing rules for all the remaining tag specifications except for prot and disc are processed and the next state is set to FINAL.

DISC-REF

If a ref tag is present it MUST be ignored. The processing rules for all the remaining tag specifications except for prot and disc are processed and the next state is set to FINAL.

FINAL

Terminal state. No processing is performed.

After each state transition that causes a change in the value of either 'name' or 'protocol', a DNS query is issued for the ESRV record at prefix + '.' name. If the ESRV query is successful the values of any tag specifications in the returned record override those previously specified.

3.2.2.  ref

The ref tag specification supports delegation and wildcard semantics for ESRV Records.

Clients MUST perform processing of ref tags when in the states START, PROT, or DISC. Clients MUST NOT perform processing of ref tags when in any other state.

The tag-value specified in a ref tag specification MUST be a DNS Domain name in DNS format (i.e. with UNICODE characters encoded in punycode format).

To process a ref tag the client replaces the state variable 'name' with the domain specified in the tag-value, the state. If the current state is START, the new state is set to START-REF, if the current state is PROT, the new state is set to PROT-REF and if the current state is DISC the new state is set to DISC-REF. A new ESRV query is made for the new target specification.

3.2.3.  prot

The prot tag specification lists DNS prefixes of protocols supported by an Internet service as a list of comma separated values.

Clients MAY perform processing of prot tags when in the states START or START-REF. Clients MUST NOT perform processing of prot tags when in any other state.

To process a prot tag the client selects a supported protocol prefix from the list of prefixes specified in the prot tag. The state value 'protocol' is replaced by the selected value, the state is set to PROT if the current state is START and PROT-REF if the current state is START-REF and an ESRV request attempted for the new value of prefix + '.' name.

Should a client be unable to identify any acceptable protcol prefix, the discovery attempt has failed.

3.2.4.  disc

The prot tag specification advises a client that the specified mode of discovery is supported.

Clients MUST perform processing of disc tags when in the states START, START-REF, PROT or PROT-REF. Clients MUST NOT perform processing of disc tags when in any other state.

Two discovery tag values are defined:

srv

Service discovery is performed by means of the DNS SRV record RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119]

naptr

Service discovery is performed by means of the DNS NAPTR record NAPTR RFC 3403 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” October 2002.) [RFC3403]

uri

Service discovery is performed by means of the DNS URI record [draft-faltstrom-uri-05]

Clients MUST support the use of SRV discovery and SHOULD support the use of URI discovery.

To process a disc tag the client selects the preferred discovery mode from those specified and retrieves the corresponding Resource Records for the current value of the 'name' and 'protocol' state values. If the discovery process results in a new host name, port number and/or URI stem value being specified, these replace the current values in the state table. The state is set to DISC and an ESRV value attempted for the new name and protocol.

3.2.5.  ssl

The ssl tag specification describes the level of support for SSl/TLS transport layer security at a service instance.

The ssl tag only declares protocol properties and thus does not have processing rules.

Three tag values are defined:

refused

The service does not support use of TLS transport layer security. Requests to establish an SSL connection will be refused.

optional

The service always offers use of TLS transport layer security using SSL version 3.0 or Transport Layer Security version 1.0 or above.

required

The service requires use of TLS transport layer security using SSL version 3.0 or Transport Layer Security version 1.0 or above.

The tag values 'optional' and 'required' MAY be used to prevent downgrade attacks. When expressed in an ESRV record secured using an appropriate DNS security mechanism (e.g. DNSSEC), these tag values provide notice that the authoritative service offers TLS security and that any service that does not offer TLS security MUST be considered non-authoritative.

4.  Security Considerations

TBS

5.  IANA Considerations

TBS

6.  References

6.1. Normative References

6.2. Non-Normative References

Authors' Addresses