One document matched: draft-hallambaker-esrv-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!ENTITY RFC2060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2060.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC2905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2905.xml">
<!ENTITY RFC3403 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3403.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3851 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3851.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4871 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4871.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-hallambaker-esrv-00" ipr="noModificationTrust200902">
<front>
<title abbrev="DNS Extended Service Parameters (ESRV)" >DNS Extended Service Parameters (ESRV) Record.</title>
<author fullname="Phillip Hallam-Baker" initials="P. M."
surname="Hallam-Baker">
<organization>Comodo Inc.</organization>
<address>
<email>philliph@comodo.com</email>
</address>
</author>
<author fullname="Brian Smith" initials="B."
surname="Smith">
<organization>DNS.com</organization>
<address>
<email>brian@dns.com</email>
</address>
</author>
<date day="7" month="September" year="2010" />
<area>Operations</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>DNS</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Definitions">
<t>The following definitions are used in this document:</t>
<t>
<list style="hanging">
<t hangText="DNS Resource Record">
[TBS]
</t>
</list>
</t>
<section title="Requirements Language">
<t>
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 <xref
target="RFC2119">RFC 2119</xref>.
</t>
</section>
</section>
<section title="Extended Service Discription">
<t>
Extended Service Discrpition (ESRV) DNS Resource Records extend the
principles of named service discovery first proposed in SRV <xref
target="RFC2782">RFC 2782</xref> and later extended
in NAPTR <xref target="RFC3403">RFC 3403</xref>
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.
</t>
<t>
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.
</t>
<t>
For example, POP <xref target="RFC1939">RFC 1939</xref> and IMAP
<xref target="RFC2060">RFC 2060</xref> 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.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC4033">RFC 4033</xref>), the ESRV
record provides a means of securely negotiating
critical security properties.
</t>
<t>
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.
</t>
<t>
This form of attack is a downgrade attack. While protocols such as SSL
<xref target="RFC5246">RFC 5246</xref>
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.
</t>
<t>
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.
</t>
<section title="ESRV Prefixes">
<t>
ESRV makes use of the same system of protocol prefixes originally
proposed for use with SRV and subsequently applied to NAPTR and URI.
</t>
<t>
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.
</t>
<figure>
<artwork>
<![CDATA[_http._tcp.example.com ESRV "ssl=required"]]>
</artwork>
</figure>
<t>
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'.
</t>
<t>
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.
</t>
<t>
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:
</t>
<figure>
<artwork>
<![CDATA[_mail._as.example.com ESRV
"prot=_submit._tcp,_smtp._tcp,_imap._tcp,_pop._tcp,"]]>
</artwork>
</figure>
</section>
<section title="ESRV Properties">
<t>
ESRV properties specify properties that control the interpretation
of the ESRV tag itself.
</t>
<t>
Only one ESRV property is defined:
</t>
<t>
<list style='hanging'>
<t hangText="ref">
The ref tag supports delegation and wildcard semantics for ESRV
Records
</t>
</list>
</t>
<t>
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.
</t>
<t>
The ref tag allows these limitations to be avoided and provides
a means of supporting delegation.
</t>
<t>
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.
</t>
<figure>
<artwork>
<![CDATA[*.example.com ESRV "ref=example.com"]]>
</artwork>
</figure>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
For example, consider the zone example.com with the following
records:
</t>
<figure>
<artwork>
<![CDATA[_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"]]>
</artwork>
</figure>
<t>
Attempting to resolve services and domains has effect as follows:
</t>
<t>
<list style='hanging'>
<t hangText="_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.
</t>
<t hangText="_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.
</t>
<t hangText="_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.
</t>
<t hangText="_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.
</t>
</list>
</t>
</section>
<section title="Protocol Properties">
<t>
Protocol properties allow a service provider to describe the
protocols and service discovery mechanisms supported by an
Internet protocol instance.
</t>
<t>
<list style='hanging'>
<t hangText="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.
</t>
<t>
Support for the prot specifier is optional.
</t>
<t hangText="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.
</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
</t>
<figure>
<artwork>
<![CDATA[_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]]>
</artwork>
</figure>
<t>
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).
</t>
</section>
<section title="Security Properties">
<t>
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.
</t>
<t>
Only one security property is currently defined:
</t>
<t>
<list style='hanging'>
<t hangText="ssl">
Specifies the use of ssl. Valid values are refused, optional
and required.
</t>
</list>
</t>
<t>
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.
</t>
<t>
If the values optional or required are specified, the corresponding
service MUST support TLS version 1.1 or above.
</t>
</section>
</section>
<section title="ESRV Syntax">
<section title="DNS Resource Record Syntax">
<t>
The ESRV record has the same DNS record syntax as the existing TXT field
specified in <xref target="RFC1035">RFC 1035</xref>.
</t>
<figure>
<artwork>
<![CDATA[+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ ESRV-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+]]>
</artwork>
</figure>
<t>
where:
</t>
<t>
ESRV-DATA One or more <character-strings>.
</t>
<t>
ESRV record data consists of a sequence of (tag, value) tuples encoded in
tag=value format following the format established in DKIM
(<xref target="RFC4871">RFC 4871</xref>)
</t>
<figure>
<artwork>
<![CDATA[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 / "_"]]>
</artwork>
</figure>
</section>
<section title="Tag Specifications">
<section title="ESRV Processing Rules">
<t>
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.
</t>
<t>
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:
</t>
<t>
<list style="hanging">
<t hangText="name (input/output)">
The DNS name of the service.
</t>
<t hangText="protocol (input/output)">
The DNS prefix of the protocol.
</t>
<t hangText="protocol_list (input)">
The DNS prefixes of the supported protocols.
</t>
<t hangText="port (output)">
The IP port number to conect to at the host
</t>
<t hangText="uri (output)">
The canonical uri of the service to connect to
</t>
<t hangText="attributes (output)">
A list of attribute value pairs that specify characteristics of the
connection to the service.
</t>
</list>
</t>
<t>
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:
</t>
<t>
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="FINAL">
Terminal state. No processing is performed.
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="ref">
<t>
The ref tag specification supports delegation and wildcard semantics
for ESRV Records.
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
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.
</t>
</section>
<section title="prot">
<t>
The prot tag specification lists DNS prefixes of protocols supported by an
Internet service as a list of comma separated values.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Should a client be unable to identify any acceptable protcol prefix, the discovery
attempt has failed.
</t>
</section>
<section title="disc">
<t>
The prot tag specification advises a client that the specified mode of discovery is
supported.
</t>
<t>
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.
</t>
<t>Two discovery tag values are defined:</t>
<t>
<list style='hanging'>
<t hangText="srv">
Service discovery is performed by means of the DNS SRV record <xref
target="RFC2119">RFC 2119</xref>
</t>
<t hangText="naptr">
Service discovery is performed by means of the DNS NAPTR record NAPTR <xref
target="RFC3403">RFC 3403</xref>
</t>
<t hangText="uri">
Service discovery is performed by means of the DNS URI record
[draft-faltstrom-uri-05]
</t>
</list>
</t>
<t>
Clients MUST support the use of SRV discovery and SHOULD support the use of URI
discovery.
</t>
<t>
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.
</t>
</section>
<section title="ssl">
<t>
The ssl tag specification describes the level of support for SSl/TLS
transport layer security at a service instance.
</t>
<t>
The ssl tag only declares protocol properties and thus does not have
processing rules.
</t>
<t>
Three tag values are
defined:
</t>
<t>
<list style='hanging'>
<t hangText="refused">
The service does not support use of TLS transport layer security.
Requests to establish an SSL connection will be refused.
</t>
<t hangText="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.
</t>
<t hangText="required">
The service requires use of TLS transport layer security using SSL
version 3.0 or Transport Layer Security version 1.0 or above.
</t>
</list>
</t>
<t>
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.
</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>
TBS
</t>
</section>
<section title="IANA Considerations">
<t>
TBS
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3403;
&RFC2782;
&RFC4871;
&RFC5246;
<!-- http://tools.ietf.org/html/draft-faltstrom-uri-05 -->
</references>
<references title="Non-Normative References">
&RFC1035;
&RFC2905;
&RFC1939;
&RFC2060;
&RFC4033;
&RFC3851;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:57:46 |