One document matched: draft-hallambaker-esrv-01.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 RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.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 RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.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-01" ipr="noModificationTrust200902">
<front>
<title abbrev="DNS Extended Service Parameters (ESRV)" >DNS Extended Service Discovery (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>Comodo Inc.</organization>
<address>
<email>brian@dns.com</email>
</address>
</author>
<date day="9" month="March" year="2011" />
<area>Operations</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>DNS</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Definitions">
<t>The following definitions are used in this document:</t>
<t>
<list style="hanging">
<t hangText="Abstract Syntax Notation One (ASN.1)">
A notation for describing abstract types and values,
as specified in <xref target="X.680">X.680</xref>.
</t>
<t hangText="Authorization Entry">
An authorization assertion that grants or denies a specific set of permissions
to a specific group of entities.
</t>
<t hangText="Canonical Domain Name">
A Domain Name that is not an alias.
</t>
<t hangText="Canonical Domain Name Value">
The value of a Canonical Domain Name. The value resulting from applying alias
transformations to a Domain Name that is not canonical.
</t>
<t hangText="Certificate">
An X.509 Certificate, as specified in <xref target="RFC5280">RFC 5280</xref>.
</t>
<t hangText="Certification Policy (CP)">
Specifies the criteria that a Certification Authority undertakes to meet
in its issue of certificates.
</t>
<t hangText="Certification Practices Statement (CPS)">
Specifies the means by which the criteria of the Certification Policy
are met. In most cases this will be the document against which the
operations of the Certification Authority are audited.
</t>
<t hangText="Certification Authority (CA)">
An entity that issues Certificates in accordance with a specified
Certification Policy.
</t>
<t hangText="Distinguished Encoding Rules (DER)">
A set of rules for encoding ASN.1 objects, as specified in
<xref target="X.690">X.690</xref>.
</t>
<t hangText="Domain">
The set of resources associated with a DNS Domain Name.
</t>
<t hangText="Domain Name">
A DNS Domain name as specified in <xref target="RFC1035">RFC 1035</xref>
and revisions.
</t>
<t hangText="Domain Name System (DNS)">
The Internet naming system specified in <xref target="RFC1035">RFC 1035</xref>
and revisions.
</t>
<t hangText="DNS Security (DNSSEC)">
Extensions to the DNS that provide authentication services as specified in
<xref target="RFC4033">RFC 4033</xref>
and revisions.
</t>
<t hangText="Public Delegation Point">
A Domain Name that is obtained from a public DNS registry as defined by a
Certification Policy.
</t>
<t hangText="Public Key Infrastructure X.509 (PKIX)">
Standards and specifications issued by the IETF that apply the
<xref target="X.509">X.509</xref> certificate standards specified
by the ITU to Internet applications as specified in
<xref target="RFC5280">RFC 5280</xref> and related documents.
</t>
<t hangText="Resource Record (RR)">
A set of attributes bound to a Domain Name.
</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>
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.
</t>
<t>
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.
</t>
<t>
Extended Service Description allows properties to be expressed at three
levels of granularity:
</t>
<t>
<list style="hanging">
<t hangText="Domain">
Properties that apply to all services offered at the corresponding
domain name. Domain level properties do not take prefixes and are
published using the GSRV Resource Record.
</t>
<t>
For example, a site might declare that all services offered at a
domain name support use of SRV service discovery.
</t>
<t hangText="Service">
Properties that apply to all instances of a service offered at the
corresponding domain name. Service level properties always take
a service specific prefix and are
published using the ESRV Resource Record.
</t>
<t>
For example, a site might specify that the SMTP service
always supports use of the TLS security protocol (via the
STARTTLS mechanism) while use of the TLS security protocol
is required for IMAP, POP and HTTP connections.
</t>
<t hangText="Instance">
Properties that apply to a specific instance of a service on a
specific host listening on a specific port. Instance level
properties always take a service specific prefix and a port specific prefix
and are
published using the ESRV Resource Record.
</t>
<t>
Declaration of Instance
specific properties is only possible when a DNS service discovery
protocol such as MX, SRV, NAPTR or DDDS is in use.
</t>
<t>
For example a site with two servers offering SMTP email service
might advertise different TLS certificates for each service instance.
</t>
</list>
</t>
<section title="Use of DNS Prefixing">
<t>
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.
</t>
<t>
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.
</t>
<section title="Interaction with Extended Service Discovery">
<t>
The GSRV/ESRV discovery mechanism is designed for use by itself or
in combination with service discovery mechanisms
such as SRV, NAPTR and URI.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
</t>
<figure>
<artwork>
<![CDATA[
example.com GSRV 0 srv "_http._tcp"
example.com GSRV 0 uri "*"]]>
</artwork>
</figure>
</section>
<section title="Abstract Services">
<t>
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.
</t>
<t>
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.
</t>
<figure>
<artwork>
<![CDATA[
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"]]>
</artwork>
</figure>
</section>
</section>
<section title="Resolution Mechanism">
<t>
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
</t>
<t>
Implementations MUST support
the Incremental mode and MAY support the Optimized mode.
</t>
<section title="Incremental Mode">
<t>
The incremental mode allows extended service discovery
to be used in conjunction with DNS resolvers that do not
support the Optimized mode.
</t>
<section title="Domain Resolution">
<t>
In the incremental mode the DNS client attempting service
discovery begins by querying for Domain level properties.
</t>
<t>
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.
</t>
<t>
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 "*".
</t>
</section>
<section title="Service Resolution">
<t>
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.
</t>
<t>
There are three possible outcomes in which the query is
successful and returns a GSRV record:
</t>
<t>
<list>
<t>
The queried domain name is canonical and a GSRV record
is returned for that domain name.
</t>
<t>
The queried domain name is not canonical and an alias
is returned (e.g. CNAME) together with the GSRV record
for the canonical name.
</t>
<t>
The queried domain name does not exist but is in the scope
of a wildcard record.
</t>
</list>
</t>
<t>
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
</t>
<t>
prefix the canonical name to perform the service lookup
</t>
<t>
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.
</t>
<figure>
<artwork>
<![CDATA[
$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 "*"]]>
</artwork>
</figure>
<t>
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.
</t>
<section title="Prefetching of Protocol Records">
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Instance Resolution">
<t>
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.
</t>
<t>
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:
</t>
<figure>
<artwork>
<![CDATA[
$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" ]]>
</artwork>
</figure>
</section>
</section>
<section title="Optimized Mode">
<t>
DNS servers MAY advertise support for the optimized mode
query by means of the EDNS0 meta-query extension.
</t>
<t>
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.
</t>
<t>
For example, a query for the HTTP service at example.com would
be made as:
</t>
<figure>
<artwork>
<![CDATA[
METASRV ? _http._tcp._0.www.example.com]]>
</artwork>
</figure>
<t>
Since the two hosts have the same weighting, there is
a 50% probability that the response to this query would be:
</t>
<figure>
<artwork>
<![CDATA[
_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"
]]>
</artwork>
</figure>
<t>
Should the attempt to connect to host1.example.com fail, the
client MAY make a second attempt:
</t>
<figure>
<artwork>
<![CDATA[
METASRV ? _http._tcp._1.www.example.com]]>
</artwork>
</figure>
<t>
Since there is now only one service instance remaining, the
response would be:
</t>
<figure>
<artwork>
<![CDATA[
_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"
]]>
</artwork>
</figure>
<t>
[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.]
</t>
<section title="EDNS0 Meta-Query Extension">
<t>
The EDNS0 Meta-Query extension has code TBS and is used
to advertise support for one or more meta-queries.
</t>
<t>
The parameter data for the Meta-Query Extension consists
of a list of DNS query numbers for the supported meta
queries.
</t>
</section>
</section>
<section title="Interactive HTTP Properties">
<t>
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.
</t>
<t>
For example, the following configuration
specifies that tls is always offered for the
application protocols HTTP and POP.
</t>
<figure>
<artwork>
<![CDATA[
$ORIGIN example.com
. GSRV 0 service "*"
. GSRV 0 http_tls "required"
_pop._tcp ESRV 0 tls "offered"
]]>
</artwork>
</figure>
<t>
The above example is functionally equivalent to specifying the
HTTP properties as instance properties:
</t>
<figure>
<artwork>
<![CDATA[
$ORIGIN example.com
. GSRV 0 service "*"
_http._tcp ESRV 0 tls "required"
_pop._tcp ESRV 0 tls "offered"
]]>
</artwork>
</figure>
<t>
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.
</t>
</section>
</section>
<section title="Syntax">
<t>
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.
</t>
<t>
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.
</t>
<t>
The GSRV/ESRV data field consists of a sequence of at least one property
entry. Each property entry consists of a sequence of:
</t>
<t>
<list style="hanging">
<t hangText="Flags">
One octet containing the following field:
<list style="hanging">
<t hangText="Bit 0: Critical Flag">
If the value is set (1), the critical flag is asserted and the
property
MUST be understood if the record is to be correctly processed.
</t>
</list>
</t>
<t>
Note that according to the conventions set out in <xref target="RFC1035">RFC 1035</xref>
Bit 0 is the Most Significant Bit and Bit 7 is the Least Significant.
Thus a flags value of 0x51 indicates a tag length of 5 octets and that
the property entry is not critical and is not to be used for relying
party processing.
</t>
<t hangText="Tag Length">
A single octet containing an unsigned integer
specifying the tag length
in octets. The tag length MUST be at least 1 and
SHOULD be no more than 15.
</t>
<t hangText="Tag">The property identifier, a sequence of ASCII characters.</t>
<t>
Tag values MAY contain ASCII characters a through z
and the numbers 0 through 9. Tag values MUST NOT contain
any other characters. Matching of tag values is case
insensitive.
</t>
<t hangText="Value">
A sequence of octets representing the property
value. Property values are encoded as binary values and MAY employ
sub-formats.
</t>
<t>
The length of the value field is specified implicitly as the remaining
length of the enclosing Resource Record data field.
</t>
</list>
</t>
<section title="Presentation Format" anchor="zoneformat">
<t>
The presentation format of the GSRV and ESRV
resource records is as follows:
</t>
<t>
GSRV <flags> <tag> <data>
</t>
<t>
ESRV <flags> <tag> <data>
</t>
<t>
Where:
</t>
<t>
<list style="hanging">
<t hangText="flags">Is an unsigned integer between 0 and 15.</t>
<t hangText="tag">
Is a non-zero sequence of ASCII letter and
numbers in lower case.
</t>
<t hangText="data">
The parameter data for the property specified as either a
quoted text string or an unquoted
Base64 Encoding <xref target="RFC4648"></xref>
of the value.
</t>
</list>
</t>
</section>
</section>
<section title="ESRV Processing Rules">
<t>
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.
</t>
<section title="Service Discovery">
<t>
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:
</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="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="properties (output)">
A list of attribute value pairs that specify characteristics of the
connection to the service.
</t>
</list>
</t>
</section>
<section title="Abstract Service Discovery">
<t>
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:
</t>
<t>
<list style="hanging">
<t hangText="name (input/output)">
The DNS name of the service.
</t>
<t hangText="protocol (input)">
The DNS prefix of the abstract protocol.
</t>
<t hangText="implementations (output)">
A list of DNS prefixes for the protocols implementing
the specified protocol that are supported at the specified
domain.
</t>
</list>
</t>
</section>
</section>
</section>
<section title="Properties">
<section title="Property Values">
<t>
GSRV/ESRV properties take different parameter values according
to the specific label.
</t>
<t>
<list style='hanging'>
<t hangText="[domain_name]">
A DNS domain name.
</t>
<t hangText="[protocol_specifier]">
An ASCII string containing a protocol prefix string
or the wildcard character '*'.
</t>
<t hangText="[tls_specifier]">
A sequence of one or more TLS attributes or
attribute value pairs.
</t>
</list>
</t>
</section>
<section title="Processing Properties">
<t>
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.
</t>
<t>
Three processing properties are defined.
</t>
<t>
<list style='hanging'>
<t hangText="canonical [domain_name]">
The canonical property directs the client to use the
specified property value as the canonical domain name
to be used in service resolution.
</t>
<t>
The canonical property only has effect if declared
as a domain property.
</t>
<t hangText="service [protocol_specifier]">
The service property directs the client to perform
service resolution if the property value matches the
query protocol.
</t>
<t>
The service property only has effect if declared
as a domain property.
</t>
<t hangText="instance [protocol_specifier]">
The service property directs the client to perform
instance resolution if the property value matches the
query protocol.
</t>
<t>
The instance property only has effect if declared
as a domain property or as a service property.
</t>
</list>
</t>
</section>
<section title="Discovery Properties">
<t>
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.
</t>
<t>
If multiple discovery properties are specified, the most specific
property or properties are to be used.
</t>
<t>
If no discovery property is specified, 'a' record service
discovery (i.e. IPv4) is indicated.
</t>
<t>
<list style='hanging'>
<t hangText="a [protocol_specifier]">
Specifies discovery by means of A record lookup;
the traditional means of service resolution for IPv4.
</t><t>
Since A record lookup is the default, this
property is most likely to be used to specify a
protocol specific exception to a wildcard
discovery property.
</t>
<t hangText="aaaa [protocol_specifier]">
Specifies discovery by means of AAAA record lookup;
the traditional means of service resolution for IPv6.
</t>
<t hangText="srv [protocol_specifier]">
Specifies discovery using the SRV service discovery mechanism.
</t>
<t hangText="uri [protocol_specifier]">
Specifies discovery using the URI service discovery mechanism.
</t>
<t hangText="naptr [protocol_specifier]">
Reserved for specifying discovery using the URI service discovery mechanism.
</t>
<t>
Since NAPTR records are designed to support URN resolution
rather than service resolution, the manner of using NAPTR
records within the GSRV/ESRV framework is left unspecified
in this version of the specification.
</t>
<t hangText="prot [protocol_specifier]">
Specifies that the specified protocol MAY be resolved to
discover a protocol related to the specified protocol.
</t>
<t>
The prot Discovery Property is used to support abstract
service resolution and alternative service resolution.
When encountered in the domain resolution phase, the
prot property advises the resolver that an alternative to the
requested protocol is available.
</t>
<t>
In the case of an abstract protocol such as a prefix representing
'email', there is no concrete service to resolve and the
only discovery properties that are valid are prot discovery properties.
</t>
<t>
In the case of a concrete protocol such as _http._tcp, a
prot specifier MAY be used to advise the resolver that
use of an alternative protocol is available
(e.g. _httpng._tcp).
</t>
</list>
</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>
<list style='hanging'>
<t hangText="tls [tls_specifier]">
Specifies the use of tls. Valid property values are refused, optional
and required.
</t>
<t>
If the property value refused is specified, the corresponding
service does not support use of the TLS security enhancement.
</t>
<t>
If the property value optional is specified, the corresponding
service always offers use of the TLS security enhancement.
</t>
<t>
If the property value optional is specified, the corresponding
service requires of use of the TLS security enhancement.
</t>
<t hangText="http-tls [tls_specifier]">
Specifies the use of tls with HTTP. Valid values are
refused, optional and required with the same semantics as
for the tis property.
</t>
<t>
The http-tls property allows security properties
to be declared for the http protocol as domain properties,
thus allowing the properties to be resolved in a single
round trip.
</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>
<section title="tls_specifier Attributes">
<t>
A tls_specifier property value consists of a sequence of
case insensitive atributes or attribute-value pairs separated by
spaces as follows:
</t>
<t>
[EBNF To Be Specified]
</t>
<t>
<list style="hanging">
<t hangText="refused">
The specified service or service instance does not support
TLS.
</t>
<t hangText="optional[=<port]>">
The specified service or service instance always offered
on an alternative IP port but does not require use of TLS.
</t>
<t>
If the port parameter is specified, it speficies
the port number for the TLS service in decimal.
</t>
<t>
If no port number is specified the TLS service is provided on
the default port for using TLS with the specified protocol.
</t>
<t hangText="required[=<port]>">
The specified service or service instance requires use of TLS.
</t>
<t>
If the port parameter is specified, it speficies
the port number for the TLS service in decimal.
</t>
<t>
If no port number is specified the TLS service is provided on
the default port for using TLS with the specified protocol.
</t>
<t hangText="upgrade">
The specified service or service instance always accepts
a client request to upgrade the connection to use TLS.
</t>
</list>
</t>
<t>
</t>
</section>
</section>
</section>
<section title="Relation to Existing Work">
<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>
<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;
&RFC4648;
&RFC4871;
&RFC5246;
&RFC5280;
<!-- http://tools.ietf.org/html/draft-faltstrom-uri-05 -->
<reference anchor="X.509">
<front>
<title>
ITU-T Recommendation X.509 (11/2008): Information
technology - Open systems interconnection - The
Directory: Public-key and attribute certificate
frameworks
</title>
<author>
<organization>
International Telecommunication Union
</organization>
</author>
<date month="November" year="2008"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.509"/>
<format type="HTML" target="http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.509"/>
</reference>
<reference anchor="X.680">
<front>
<title>
ITU-T Recommendation X.680 (11/2008): Information
technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
</title>
<author>
<organization>
International Telecommunication Union
</organization>
</author>
<date month="November" year="2008"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/>
<format type="HTML" target="http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.680"/>
</reference>
<reference anchor="X.690">
<front>
<title>
ITU-T Recommendation X.690 (11/2008): Information
technology - Abstract Syntax Notation One (ASN.1):
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)
</title>
<author>
<organization>
International Telecommunication Union
</organization>
</author>
<date month="November" year="2008"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
<format type="HTML" target="http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.690"/>
</reference>
</references>
<references title="Non-Normative References">
&RFC1035;
&RFC2905;
&RFC1939;
&RFC2060;
&RFC4033;
&RFC3851;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:55:52 |