[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Internet Engineering Task Force                          P. Hallam-Baker
Internet-Draft                                               Comodo Inc.
Intended status: Informational                                  B. Smith
Expires: March 11, 2011                                          DNS.com
                                                       September 7, 2010


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

Abstract

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 11, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Hallam-Baker & Smith     Expires March 11, 2011                 [Page 1]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

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





















Hallam-Baker & Smith     Expires March 11, 2011                 [Page 2]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


1.  Definitions

   The following definitions are used in this document:

   DNS Resource Record  [TBS]

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Extended Service Discription

   Extended Service Discrpition (ESRV) DNS Resource Records extend the
   principles of named service discovery first proposed in SRV RFC 2782
   [RFC2782] and later extended in NAPTR RFC 3403 [RFC3403] and related
   specifications.  The ESRV record provides an extensible container
   that MAY be used to provide a description of an abstract Internet
   service bound to a domain name or a specific instance of that
   Internet Service on a specific host.

   Existing SRV records provide a means of allowing a client to discover
   a host and port number for a specific Internet protocol.  ESRV
   records allow a further layer of abstraction in which the discovery
   is of an Internet Service and the service provider MAY declare a
   range of supported protocol options.

   For example, POP RFC 1939 [RFC1939] and IMAP RFC 2060 [RFC2060] both
   provide means by which a mail client can access mail messages but the
   only means by which a client might discover that both protocols are
   supported is to attempt to connect to each in turn.

   Although discovery by polling is practical when there are only two
   options, it is impractical in application areas such as federated
   authentication (also known as 'identity') where the number of
   protocols that might be employed is very large (e.g.  Kerberos, SAML,
   OpenID, etc.) and the number of ways in which those protocols might
   be employed is even larger still.  Not only is polling inefficient in
   such circumstances, a client that fails to find a means of connection
   has no way to know how it might have succeeded.

   ESRV records provide a means by which Internet clients and Servers
   can negotiate choice of protocols and protocol properties.  In
   particular, when publication of the ESRV record is appropriately
   secure (e.g. through a use of DNSSEC RFC 4033 [RFC4033]), the ESRV
   record provides a means of securely negotiating critical security



Hallam-Baker & Smith     Expires March 11, 2011                 [Page 3]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


   properties.

   Today use of Internet security is the exception rather than the rule.
   As a result, an attacker can frequently bypass security enhancements
   by persuading the parties that they do not exist.

   This form of attack is a downgrade attack.  While protocols such as
   SSL RFC 5246 [RFC5246] and S/MIME have measures that are intended to
   prevent downgrade attacks in which weaker algorithms are substituted
   for strong, there is currently no in-band mechanism for specifying
   that these enhancements are available or that they should or must be
   used.

   While it is possible to infer such information from existing DNS
   records such as the port number specification in an SRV record, such
   approaches represent heuristics and as such are not appropriate as a
   means of achieving an essential security objective.

2.1.  ESRV Prefixes

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

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

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

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

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

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

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







Hallam-Baker & Smith     Expires March 11, 2011                 [Page 4]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


2.2.  ESRV Properties

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

   Only one ESRV property is defined:

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

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

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

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

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

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

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

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

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

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

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



Hallam-Baker & Smith     Expires March 11, 2011                 [Page 5]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


   records:

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

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

   Attempting to resolve services and domains has effect as follows:

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

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

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

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

2.3.  Protocol Properties

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






Hallam-Baker & Smith     Expires March 11, 2011                 [Page 6]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


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

      Support for the prot specifier is optional.

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

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

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

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

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

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

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

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

2.4.  Security Properties

   Security properties allow a service provider to describe the security
   critieria for a service.  When an ESRV record is secured using an
   appropriate means (e.g.  DNSSEC), the security properties MAY be used
   to prevent a downgrade attack on the security enhancements offered.




Hallam-Baker & Smith     Expires March 11, 2011                 [Page 7]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


   Only one security property is currently defined:

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

   It is anticipated that the list of tags will be expanded at a future
   date to support other Internet security protocols such as IPSEC and
   WS-Security.

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


3.  ESRV Syntax

3.1.  DNS Resource Record Syntax

   The ESRV record has the same DNS record syntax as the existing TXT
   field specified in RFC 1035 [RFC1035].

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

   where:

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

   ESRV record data consists of a sequence of (tag, value) tuples
   encoded in tag=value format following the format established in DKIM
   (RFC 4871 [RFC4871])

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

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

   ALNUMPUNC =  ALPHA / DIGIT / "_"








Hallam-Baker & Smith     Expires March 11, 2011                 [Page 8]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


3.2.  Tag Specifications

3.2.1.  ESRV Processing Rules

   The purpose of ESRV service discovery is to refine an abstract
   specification of a DNS host name and protocol prefix to a concrete
   specification for the name of a specific network host, a specific
   network port number and a specific network protocol and associated
   protocol parameters.

   The ESRV Resource Record is used in combination with the SRV and URI
   Resource Records to perform extended service discovery.  An API call
   for ESRV processing has the following signature:

   name (input/output)  The DNS name of the service.

   protocol (input/output)  The DNS prefix of the protocol.

   protocol_list (input)  The DNS prefixes of the supported protocols.

   port (output)  The IP port number to conect to at the host

   uri (output)  The canonical uri of the service to connect to

   attributes (output)  A list of attribute value pairs that specify
      characteristics of the connection to the service.

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

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

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

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



Hallam-Baker & Smith     Expires March 11, 2011                 [Page 9]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


      set to DISC if a disc tag specification is present and FINAL
      otherwise.

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

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

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

   FINAL  Terminal state.  No processing is performed.

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

3.2.2.  ref

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

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

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

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






Hallam-Baker & Smith     Expires March 11, 2011                [Page 10]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


3.2.3.  prot

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

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

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

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

3.2.4.  disc

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

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

   Two discovery tag values are defined:

   srv  Service discovery is performed by means of the DNS SRV record
      RFC 2119 [RFC2119]

   naptr  Service discovery is performed by means of the DNS NAPTR
      record NAPTR RFC 3403 [RFC3403]

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

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

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



Hallam-Baker & Smith     Expires March 11, 2011                [Page 11]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


   attempted for the new name and protocol.

3.2.5.  ssl

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

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

   Three tag values are defined:

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

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

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

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


4.  Security Considerations

   TBS


5.  IANA Considerations

   TBS


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Hallam-Baker & Smith     Expires March 11, 2011                [Page 12]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

6.2.  Non-Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

   [RFC2060]  Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 2060, December 1996.

   [RFC2905]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
              Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
              D. Spence, "AAA Authorization Application Examples",
              RFC 2905, August 2000.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.


Authors' Addresses

   Phillip Hallam-Baker
   Comodo Inc.

   Email: philliph@comodo.com





Hallam-Baker & Smith     Expires March 11, 2011                [Page 13]

Internet-Draft   DNS Extended Service Parameters (ESRV)   September 2010


   Brian Smith
   DNS.com

   Email: brian@dns.com















































Hallam-Baker & Smith     Expires March 11, 2011                [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/