Internet Engineering Task Force P. Hallam-Baker
Internet-Draft Comodo Inc.
Intended status: Informational B. Smith
Expires: March 11, 2011 DNS.com
September 7, 2010
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
Hallam-Baker & Smith Expires March 11, 2011 [Page 1]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Extended Service Discription . . . . . . . . . . . . . . . . . 3
2.1. ESRV Prefixes . . . . . . . . . . . . . . . . . . . . . . 4
2.2. ESRV Properties . . . . . . . . . . . . . . . . . . . . . 5
2.3. Protocol Properties . . . . . . . . . . . . . . . . . . . 6
2.4. Security Properties . . . . . . . . . . . . . . . . . . . 7
3. ESRV Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. DNS Resource Record Syntax . . . . . . . . . . . . . . . . 8
3.2. Tag Specifications . . . . . . . . . . . . . . . . . . . . 9
3.2.1. ESRV Processing Rules . . . . . . . . . . . . . . . . 9
3.2.2. ref . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. prot . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4. disc . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.5. ssl . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Non-Normative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Hallam-Baker & Smith Expires March 11, 2011 [Page 2]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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 [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
[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
Hallam-Baker & Smith Expires March 11, 2011 [Page 3]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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.
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,"
Hallam-Baker & Smith Expires March 11, 2011 [Page 4]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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
Hallam-Baker & Smith Expires March 11, 2011 [Page 5]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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.
Hallam-Baker & Smith Expires March 11, 2011 [Page 6]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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.
Hallam-Baker & Smith Expires March 11, 2011 [Page 7]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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 [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 [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 / "_"
Hallam-Baker & Smith Expires March 11, 2011 [Page 8]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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
Hallam-Baker & Smith Expires March 11, 2011 [Page 9]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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.
Hallam-Baker & Smith Expires March 11, 2011 [Page 10]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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 [RFC2119]
naptr Service discovery is performed by means of the DNS NAPTR
record NAPTR RFC 3403 [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
Hallam-Baker & Smith Expires March 11, 2011 [Page 11]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Hallam-Baker & Smith Expires March 11, 2011 [Page 12]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
6.2. Non-Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1939] Myers, J. and M. 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.
[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.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
Authors' Addresses
Phillip Hallam-Baker
Comodo Inc.
Email: philliph@comodo.com
Hallam-Baker & Smith Expires March 11, 2011 [Page 13]
Internet-Draft DNS Extended Service Parameters (ESRV) September 2010
Brian Smith
DNS.com
Email: brian@dns.com
Hallam-Baker & Smith Expires March 11, 2011 [Page 14]