One document matched: draft-hallambaker-esrv-01.txt
Differences from draft-hallambaker-esrv-00.txt
Internet Engineering Task Force P. Hallam-Baker
Internet-Draft B. Smith
Intended status: Informational Comodo Inc.
Expires: September 10, 2011 March 9, 2011
DNS Extended Service Discovery (ESRV) Record.
draft-hallambaker-esrv-01
Abstract
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.
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 September 10, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Hallam-Baker & Smith Expires September 10, 2011 [Page 1]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
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 . . . . . . . . . . . . . . . . . . 4
2. Extended Service Discription . . . . . . . . . . . . . . . . . 4
2.1. Use of DNS Prefixing . . . . . . . . . . . . . . . . . . . 5
2.1.1. Interaction with Extended Service Discovery . . . . . 5
2.1.2. Abstract Services . . . . . . . . . . . . . . . . . . 6
2.2. Resolution Mechanism . . . . . . . . . . . . . . . . . . . 6
2.2.1. Incremental Mode . . . . . . . . . . . . . . . . . . . 6
2.2.1.1. Domain Resolution . . . . . . . . . . . . . . . . 6
2.2.1.2. Service Resolution . . . . . . . . . . . . . . . . 7
2.2.1.3. Instance Resolution . . . . . . . . . . . . . . . 8
2.2.2. Optimized Mode . . . . . . . . . . . . . . . . . . . . 8
2.2.2.1. EDNS0 Meta-Query Extension . . . . . . . . . . . . 9
2.2.3. Interactive HTTP Properties . . . . . . . . . . . . . 9
2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Presentation Format . . . . . . . . . . . . . . . . . 11
2.4. ESRV Processing Rules . . . . . . . . . . . . . . . . . . 12
2.4.1. Service Discovery . . . . . . . . . . . . . . . . . . 12
2.4.2. Abstract Service Discovery . . . . . . . . . . . . . . 12
3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Property Values . . . . . . . . . . . . . . . . . . . . . 13
3.2. Processing Properties . . . . . . . . . . . . . . . . . . 13
3.3. Discovery Properties . . . . . . . . . . . . . . . . . . . 14
3.4. Security Properties . . . . . . . . . . . . . . . . . . . 15
3.4.1. tls_specifier Attributes . . . . . . . . . . . . . . . 15
4. Relation to Existing Work . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Non-Normative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Hallam-Baker & Smith Expires September 10, 2011 [Page 2]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
1. Definitions
The following definitions are used in this document:
Abstract Syntax Notation One (ASN.1) A notation for describing
abstract types and values, as specified in X.680 [X.680].
Authorization Entry An authorization assertion that grants or denies
a specific set of permissions to a specific group of entities.
Canonical Domain Name A Domain Name that is not an alias.
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.
Certificate An X.509 Certificate, as specified in RFC 5280
[RFC5280].
Certification Policy (CP) Specifies the criteria that a
Certification Authority undertakes to meet in its issue of
certificates.
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.
Certification Authority (CA) An entity that issues Certificates in
accordance with a specified Certification Policy.
Distinguished Encoding Rules (DER) A set of rules for encoding ASN.1
objects, as specified in X.690 [X.690].
Domain The set of resources associated with a DNS Domain Name.
Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and
revisions.
Domain Name System (DNS) The Internet naming system specified in RFC
1035 [RFC1035] and revisions.
DNS Security (DNSSEC) Extensions to the DNS that provide
authentication services as specified in RFC 4033 [RFC4033] and
revisions.
Hallam-Baker & Smith Expires September 10, 2011 [Page 3]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
Public Delegation Point A Domain Name that is obtained from a public
DNS registry as defined by a Certification Policy.
Public Key Infrastructure X.509 (PKIX) Standards and specifications
issued by the IETF that apply the X.509 [X.509] certificate
standards specified by the ITU to Internet applications as
specified in RFC 5280 [RFC5280] and related documents.
Resource Record (RR) A set of attributes bound to a Domain Name.
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
General Service Description (GSRV) and Extended Service Discrpition
(ESRV) DNS Resource Records provide a mechanism for specifying
properties relating to Internet services associated with a DNS name.
GSRV and ESRV records are intended to serve the same function at
different levels of generality. GSRV records specify properties that
apply to all Internet services provided in the Domain. ESRV records
are used to specify properties that apply to finer levels of detail.
Extended Service Description allows properties to be expressed at
three levels of granularity:
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.
For example, a site might declare that all services offered at a
domain name support use of SRV service discovery.
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.
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.
Hallam-Baker & Smith Expires September 10, 2011 [Page 4]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
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.
Declaration of Instance specific properties is only possible when
a DNS service discovery protocol such as MX, SRV, NAPTR or DDDS is
in use.
For example a site with two servers offering SMTP email service
might advertise different TLS certificates for each service
instance.
2.1. Use of DNS Prefixing
GRSV/ESRV records make use of the service prefixing mechanism
introduced in SRV and employed in later advanced service discovery
mechanisms such as NAPTR and URI.
The need for separate DNS Resource Record types to express properties
at different levels of granularity arises from the need to support
use of wildcards and DNS aliases such as CNAME and DNAME records when
specifying properties that apply to a whole domain and the need to
use prefix labels to specify properties at finer granularity.
2.1.1. Interaction with Extended Service Discovery
The GSRV/ESRV discovery mechanism is designed for use by itself or in
combination with service discovery mechanisms such as SRV, NAPTR and
URI.
One of the main limitations of service discovery schemes such as SRV,
NAPTR and URI is that they can only be used if a client knows to look
for them.
Without provision for meta-service discovery, the service discovery
mechanisms supported by a protocol are limited to those which exist
at the time the protocol is developed and that the protocol designer
decides to support. In most cases however, it is the site
administrator rather than the protocol designer who is best placed to
know which form of extended discovery is most applicable to their
service.
GSRV records may be used to inform clients that a service discovery
mechanism is supported for specific protocols or for all protocols.
In the following example clients are advised to attempt service
discovery using the SRV mechanism for the HTTP protocol and to
attempt URI service discovery for all others:
Hallam-Baker & Smith Expires September 10, 2011 [Page 5]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
example.com GSRV 0 srv "_http._tcp"
example.com GSRV 0 uri "*"
2.1.2. Abstract Services
Publication of ESRV properties for abstract services allows a site to
enable clients to perform protocol negotiation by specifying the
range of services offered that support a specific purpose.
For example, the SMTP, POP3 and IMAP4 protocols are all used for
exchange of mail. An abstract service for the mail protocol with the
prefix '_mail._as' allows clients to discover the full range of mail
related protocols in a single query.
example.com GSRV 0 service "_mail._as"
_mail._as.example.com ESRV 0 prot "_smtp._tcp"
_mail._as.example.com ESRV 0 prot "_pop._tcp"
_mail._as.example.com ESRV 0 prot "_imap._tcp"
2.2. Resolution Mechanism
Extended Service description records MAY be resolved in an
Incremental mode or an Optimized mode. Incremental mode allows
records to be advertised and resolved by existing DNS servers,
optimized mode allows for improved performance when
Implementations MUST support the Incremental mode and MAY support the
Optimized mode.
2.2.1. Incremental Mode
The incremental mode allows extended service discovery to be used in
conjunction with DNS resolvers that do not support the Optimized
mode.
2.2.1.1. Domain Resolution
In the incremental mode the DNS client attempting service discovery
begins by querying for Domain level properties.
For example, a client attempting to perform extended service
discovery for the HTTP protocol server at www.example.com would begin
by querying for the GSRV record at www.example.com.
Domain properties MAY include property entries for the service
property type. The service property entry indicates that additional
property entries are specified at the service level for either a
Hallam-Baker & Smith Expires September 10, 2011 [Page 6]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
specific serviceby means of the protocol prefix or for all services
by means of the wildcard entry "*".
2.2.1.2. Service Resolution
If the domain resolution indicates that property entries are declared
for the service prefix being resolved or for the wildcard prefix
type, service level resolution is performed.
There are three possible outcomes in which the query is successful
and returns a GSRV record:
The queried domain name is canonical and a GSRV record is returned
for that domain name.
The queried domain name is not canonical and an alias is returned
(e.g. CNAME) together with the GSRV record for the canonical
name.
The queried domain name does not exist but is in the scope of a
wildcard record.
In the last case we require that the GSRV record set returned contain
a canonical property entry specifying a canonical name. We are thus
assured that
prefix the canonical name to perform the service lookup
In the following example a query for the _prefix protocol at domain
names canonical.example.com, cname.example.com or
wildcard.example.com will all result in the resolution process
continuing with a query for an ESRV record for
_prefix.canonical.example.com.
$ORIGIN example.com
canonical GSRV 0 service "*"
cname.example.com CNAME canonical.example.com
*.example.com GSRV 0 canonical "canonical.example.com"
*.example.com GSRV 0 service "*"
If use of a service discovery mechanism is indicated a site MAY
choose to advertise properties specific to a particular service
instance through use of the instance property type.
Hallam-Baker & Smith Expires September 10, 2011 [Page 7]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
2.2.1.2.1. Prefetching of Protocol Records
Client implementations MAY attempt to optimize incremental mode
discovery by initiating service resolution in parallel with domain
resolution by applying the protocol prefix to the query domain.
If the response to the domain resolution query indicates that the
query domain is not-canonical, any answer returned to the pre-fetched
query is ignored and a new query made if inidcated by the answer
returned to the domain resolution query.
2.2.1.3. Instance Resolution
If the service level resolution indicates that instance level
property entries MAY exist, these are resolved by querying for the
chosen host name prefixed by the service prefix and a second prefix
formed from the decimal port identifier.
For example a the www.example.com HTTP server is supported by two
separate service instances (host1, host2). TLS security is always
offered on host1 instance but not on host2:
$ORIGIN example.com
www GSRV 0 service "*"
www GSRV 0 srv "_http._tcp"
_http._tcp.www ESRV 0 instance ""
_http._tcp.www SRV 1 1 80 host1.example.com
_http._tcp.www SRV 1 1 80 host2.example.com
_http._tcp._80.host1 ESRV 0 tls "required"
2.2.2. Optimized Mode
DNS servers MAY advertise support for the optimized mode query by
means of the EDNS0 meta-query extension.
When optimized mode queries are supported, the client MAY present a
meta-query consisting of the protocol prefix concatenated to an
iteration count concatenated to the query domain. The server
receiving the query then performs the GSRV/ESRV discovery process on
the client's behalf and returns the whole result chain in a single
response.
For example, a query for the HTTP service at example.com would be
made as:
METASRV ? _http._tcp._0.www.example.com
Hallam-Baker & Smith Expires September 10, 2011 [Page 8]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
Since the two hosts have the same weighting, there is a 50%
probability that the response to this query would be:
_http._tcp._0.www.example.com METASRV 2
www.example.com GSRV 0 service "*"
www.example.com GSRV 0 srv "_http._tcp"
_http._tcp.www.example.com ESRV 0 instance ""
_http._tcp.www.example.com SRV 1 1 80 host2.example.com
_http._tcp._80.host1 ESRV 0 tls "required"
Should the attempt to connect to host1.example.com fail, the client
MAY make a second attempt:
METASRV ? _http._tcp._1.www.example.com
Since there is now only one service instance remaining, the response
would be:
_http._tcp._1.www.example.com METASRV 2
www.example.com GSRV 0 service "*"
www.example.com GSRV 0 srv "_http._tcp"
_http._tcp.www.example.com ESRV 0 instance ""
_http._tcp.www.example.com SRV 1 1 80 host1.example.com
_http._tcp._80.host1 ESRV 0 tls "required"
[TBS: work out how to allow the server to calculate the random number
deterministically on the query, may need to add a state parameter
here.]
2.2.2.1. EDNS0 Meta-Query Extension
The EDNS0 Meta-Query extension has code TBS and is used to advertise
support for one or more meta-queries.
The parameter data for the Meta-Query Extension consists of a list of
DNS query numbers for the supported meta queries.
2.2.3. Interactive HTTP Properties
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
Hallam-Baker & Smith Expires September 10, 2011 [Page 9]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
optimized resolution mode to resolve HTTP properties in a single
round trip rather than two.
For example, the following configuration specifies that tls is always
offered for the application protocols HTTP and POP.
$ORIGIN example.com
. GSRV 0 service "*"
. GSRV 0 http_tls "required"
_pop._tcp ESRV 0 tls "offered"
The above example is functionally equivalent to specifying the HTTP
properties as instance properties:
$ORIGIN example.com
. GSRV 0 service "*"
_http._tcp ESRV 0 tls "required"
_pop._tcp ESRV 0 tls "offered"
Special provision is justified in this instance by the widespread use
of HTTP and the effect that service discovery latency has on the Web
Browser user experience.
2.3. Syntax
The GSRV and ESRV have the same record syntax which is the same as
the syntax of the CAA record. A GSRV or ESRV RR contains a single
property entry consisting of a tag value pair. Each tag represents a
property of the CAA record. The value of a property entry is that
specified in the corresponding value field.
A domain name MAY have multiple GSRV or ESRV RRs associated with it
and a given property MAY be specified more than once. Where multiple
properties are specified they are additive. That is if SRV and URI
records are advertised for a service then both mechanisms for
advanced discovery are offered.
The GSRV/ESRV data field consists of a sequence of at least one
property entry. Each property entry consists of a sequence of:
Hallam-Baker & Smith Expires September 10, 2011 [Page 10]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
Flags One octet containing the following field:
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.
Note that according to the conventions set out in RFC 1035
[RFC1035] 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.
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.
Tag The property identifier, a sequence of ASCII characters.
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.
Value A sequence of octets representing the property value.
Property values are encoded as binary values and MAY employ sub-
formats.
The length of the value field is specified implicitly as the
remaining length of the enclosing Resource Record data field.
2.3.1. Presentation Format
The presentation format of the GSRV and ESRV resource records is as
follows:
GSRV <flags> <tag> <data>
ESRV <flags> <tag> <data>
Where:
flags Is an unsigned integer between 0 and 15.
tag Is a non-zero sequence of ASCII letter and numbers in lower
case.
Hallam-Baker & Smith Expires September 10, 2011 [Page 11]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
data The parameter data for the property specified as either a
quoted text string or an unquoted Base64 Encoding [RFC4648] of the
value.
2.4. ESRV Processing Rules
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.
2.4.1. Service Discovery
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:
name (input/output) The DNS name of the service.
protocol (input/output) The DNS prefix of the protocol.
port (output) The IP port number to conect to at the host
uri (output) The canonical uri of the service to connect to
properties (output) A list of attribute value pairs that specify
characteristics of the connection to the service.
2.4.2. Abstract Service Discovery
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:
name (input/output) The DNS name of the service.
protocol (input) The DNS prefix of the abstract protocol.
implementations (output) A list of DNS prefixes for the protocols
implementing the specified protocol that are supported at the
specified domain.
Hallam-Baker & Smith Expires September 10, 2011 [Page 12]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
3. Properties
3.1. Property Values
GSRV/ESRV properties take different parameter values according to the
specific label.
[domain_name] A DNS domain name.
[protocol_specifier] An ASCII string containing a protocol prefix
string or the wildcard character '*'.
[tls_specifier] A sequence of one or more TLS attributes or
attribute value pairs.
3.2. Processing Properties
Processing properties direct the process of property resolution.
Since a processing property is used to direct the resolution process,
they only have effect when encountered at a relevant stage of
resolution. A service property that directs a client to resolve for
service properties has no effect.
Three processing properties are defined.
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.
The canonical property only has effect if declared as a domain
property.
service [protocol_specifier] The service property directs the client
to perform service resolution if the property value matches the
query protocol.
The service property only has effect if declared as a domain
property.
instance [protocol_specifier] The service property directs the
client to perform instance resolution if the property value
matches the query protocol.
The instance property only has effect if declared as a domain
property or as a service property.
Hallam-Baker & Smith Expires September 10, 2011 [Page 13]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
3.3. Discovery Properties
Discovery Properties specify the resolution mechanism(s) to be used
for service resolution. Discovery properties only have effect when
encountered in the Domain resolution phase and always take a
protocol_specifier as the property type.
If multiple discovery properties are specified, the most specific
property or properties are to be used.
If no discovery property is specified, 'a' record service discovery
(i.e. IPv4) is indicated.
a [protocol_specifier] Specifies discovery by means of A record
lookup; the traditional means of service resolution for IPv4.
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.
aaaa [protocol_specifier] Specifies discovery by means of AAAA
record lookup; the traditional means of service resolution for
IPv6.
srv [protocol_specifier] Specifies discovery using the SRV service
discovery mechanism.
uri [protocol_specifier] Specifies discovery using the URI service
discovery mechanism.
naptr [protocol_specifier] Reserved for specifying discovery using
the URI service discovery mechanism.
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.
prot [protocol_specifier] Specifies that the specified protocol MAY
be resolved to discover a protocol related to the specified
protocol.
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.
Hallam-Baker & Smith Expires September 10, 2011 [Page 14]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
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.
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).
3.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.
tls [tls_specifier] Specifies the use of tls. Valid property values
are refused, optional and required.
If the property value refused is specified, the corresponding
service does not support use of the TLS security enhancement.
If the property value optional is specified, the corresponding
service always offers use of the TLS security enhancement.
If the property value optional is specified, the corresponding
service requires of use of the TLS security enhancement.
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.
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.
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.
3.4.1. tls_specifier Attributes
A tls_specifier property value consists of a sequence of case
insensitive atributes or attribute-value pairs separated by spaces as
follows:
[EBNF To Be Specified]
Hallam-Baker & Smith Expires September 10, 2011 [Page 15]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
refused The specified service or service instance does not support
TLS.
optional[=<port]> The specified service or service instance always
offered on an alternative IP port but does not require use of TLS.
If the port parameter is specified, it speficies the port number
for the TLS service in decimal.
If no port number is specified the TLS service is provided on the
default port for using TLS with the specified protocol.
required[=<port]> The specified service or service instance requires
use of TLS.
If the port parameter is specified, it speficies the port number
for the TLS service in decimal.
If no port number is specified the TLS service is provided on the
default port for using TLS with the specified protocol.
upgrade The specified service or service instance always accepts a
client request to upgrade the connection to use TLS.
4. Relation to Existing Work
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
Hallam-Baker & Smith Expires September 10, 2011 [Page 16]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
authentication (also known as 'identity') where the number of
protocols that might be employed is very large (e.g. Kerberos, SAML,
OpenID, etc.) and the number of ways in which those protocols might
be employed is even larger still. Not only is polling inefficient in
such circumstances, a client that fails to find a means of connection
has no way to know how it might have succeeded.
ESRV records provide a means by which Internet clients and Servers
can negotiate choice of protocols and protocol properties. In
particular, when publication of the ESRV record is appropriately
secure (e.g. through a use of DNSSEC RFC 4033 [RFC4033]), the ESRV
record provides a means of securely negotiating critical security
properties.
Today use of Internet security is the exception rather than the rule.
As a result, an attacker can frequently bypass security enhancements
by persuading the parties that they do not exist.
This form of attack is a downgrade attack. While protocols such as
SSL RFC 5246 [RFC5246] and S/MIME have measures that are intended to
prevent downgrade attacks in which weaker algorithms are substituted
for strong, there is currently no in-band mechanism for specifying
that these enhancements are available or that they should or must be
used.
While it is possible to infer such information from existing DNS
records such as the port number specification in an SRV record, such
approaches represent heuristics and as such are not appropriate as a
means of achieving an essential security objective.
5. Security Considerations
TBS
6. IANA Considerations
TBS
7. References
7.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 September 10, 2011 [Page 17]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
[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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[X.509] International Telecommunication Union, "ITU-T
Recommendation X.509 (11/2008): Information technology -
Open systems interconnection - The Directory: Public-key
and attribute certificate frameworks", ITU-T
Recommendation X.509, November 2008.
[X.680] International Telecommunication Union, "ITU-T
Recommendation X.680 (11/2008): Information technology -
Abstract Syntax Notation One (ASN.1): Specification of
basic notation", ITU-T Recommendation X.680,
November 2008.
[X.690] International Telecommunication Union, "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)", ITU-T
Recommendation X.690, November 2008.
7.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",
Hallam-Baker & Smith Expires September 10, 2011 [Page 18]
Internet-Draft DNS Extended Service Parameters (ESRV) March 2011
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
Brian Smith
Comodo Inc.
Email: brian@dns.com
Hallam-Baker & Smith Expires September 10, 2011 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 09:04:05 |