[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                          E. Nygren
Internet-Draft                                       Akamai Technologies
Intended status: Standards Track                            July 3, 2014
Expires: January 4, 2015


                  Service Binding DNS Records (DNS B)
                    draft-nygren-service-bindings-00

Abstract

   This document describes a DNS "B" RR which binds together information
   needed to establish connection to a service across multiple protocol
   layers, including the location of the server, the application-level
   protocol, and security bootstrap information.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 January 4, 2015.

Copyright Notice

   Copyright (c) 2014 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
   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.




Nygren                   Expires January 4, 2015                [Page 1]


Internet-Draft              Service Bindings                   July 2014


Table of Contents

   1.  Overview and rationale  . . . . . . . . . . . . . . . . . . .   2
     1.1.  Relationship to SRV RR type . . . . . . . . . . . . . . .   3
     1.2.  Introductory example  . . . . . . . . . . . . . . . . . .   3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   4
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   4
   4.  The Service Binding Record  . . . . . . . . . . . . . . . . .   5
     4.1.  B record RDATA encoding . . . . . . . . . . . . . . . . .   6
     4.2.  Service Binding Parameters  . . . . . . . . . . . . . . .   6
     4.3.  Standard Service Binding Parameters . . . . . . . . . . .   7
     4.4.  Optional Security Parameters  . . . . . . . . . . . . . .   8
     4.5.  Examples for other possible future Parameters . . . . . .   9
   5.  Selecting a Service Binding to Use  . . . . . . . . . . . . .  10
     5.1.  Handling B record responses . . . . . . . . . . . . . . .  10
     5.2.  Handling a lack of Service Binding records  . . . . . . .  10
   6.  Operational Examples  . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Example: Moving a service and domain between operators  .  11
   7.  Open Areas for Discussion . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
     11.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Overview and rationale

   As the protocols underlying services evolve to provide enhanced
   performance and security properties, clients have an increasing
   number of ways to contact any given service on a domain.  Contacting
   any given implementation instance of a service on a domain may
   require parameters across multiple protocol layers.  Different
   servers with different address records may even desire to implement
   the same service, especially in the case where older protocols lacked
   functionality required to make a smooth transition to newer
   protocols.

   The DNS B RR allows administrators to bind together the parameters
   needed to contact an instance of a service on a domain into a single
   record, or "service binding".  Multiple service bindings (multiple B
   records in an RRset) may provide a client with multiple ways to
   contact a given service, each with its own associated protocol(s) and
   related parameters.





Nygren                   Expires January 4, 2015                [Page 2]


Internet-Draft              Service Bindings                   July 2014


   Service bindings give clients a single DNS query [RFC1035] to resolve
   to obtain the B RRset for a service and domain.  Clients are able to
   then filter B RRs based on which protocols they support.  After
   selecting an B RR within this RRset, it should then be clear to the
   client whether other RRs need to be resolved prior to establishing
   communication with the service for a given protocol.

1.1.  Relationship to SRV RR type

   The B RR has close similarities of purpose to the SRV RR [RFC2782]
   but the B RR covers additional use-cases, including:

   o  Multiple application-level protocol implementations for a service

   o  Providing information for improving the security of a connection
      to a service (such as constraints on server certificates as well
      as handshake encryption keys)

   o  A single RRset name that can be queried that covers multiple
      lower-level protocol implementations for a service, such as when
      the same service is offered over multiple transport-layer
      protocols

   Similar to SRV, the B RR provides:

   o  Multiple address records for a given domain

   o  Priorities and weights to guide client selection

   o  The information needed to contact a given server (such as target
      hostname and port number) is bound together in a single record

1.2.  Introductory example

   If a web browser supporting B records wishes to fetch the URL
   https://www.example.com/, it would use the URI scheme ("https") as
   the the service and perform a lookup of:

   QNAME=_https._b.www.example.com, QCLASS=IN, QTYPE=B

   which might return an RRset with multiple resource records:










Nygren                   Expires January 4, 2015                [Page 3]


Internet-Draft              Service Bindings                   July 2014


   1 0 server-experimental.example.com.
        { "a": "h2", "t": "fictionfast", "tp": 9443 }

   3 0 server-primary.example.com.
        { "a": "h2", "t": "tcp", "tp": 443,
          "dane": "_443._tcp.server-primary-www-cert.example.com.",
          "tlshp": ["JgxJkCv0va0", "OBZVN8LPo+SB9eQ/"] }

   5 0 server-legacy.example.com.
        { "a": "http/1.1", "t": "tcp", "tp": 443,
          "dane": "_443._tcp.server-legacy-www-cert.example.com" }

   The first of these specifies using HTTP/2 over a fictional
   experimental secure transport protocol "fictionfast" over UDP port
   9443 from the server(s) with address record server-
   experimental.example.com.

   For clients not supporting this first item, HTTP/2
   [I-D.ietf-httpbis-http2] is available over TLS via TCP port 443 with
   certificate information available from a DANE record at
   "_443._tcp.server-primary-www-cert.example.com." and with TLS 1.3
   server handshake encryption parameters specified
   [I-D.rescorla-tls13-new-flows] from server(s) with the server-
   primary.example.com address record.

   For clients not supporting HTTP/2, a separate set of legacy servers
   is available for HTTP/1.1 which happens to have different certificate
   information available from a separate DANE record.

   *NOTE:* HTTPS is selected above for illustrative purposes only, and
   the HTTPS examples within this document should not be considered to
   be a definitive statement on the way for HTTPS to use B records.

2.  Notational Conventions

   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 [RFC2119].

3.  Applicability Statement

   In general, it is expected that service binding records will be used
   by clients for applications where the relevant protocol specification
   indicates that clients should use the B record.  Such specification
   MUST define the symbolic name to be used in the Service field of the
   B record as described below.  Such specification MUST also define the
   Parameters available as well as their interpretation.  It also MUST




Nygren                   Expires January 4, 2015                [Page 4]


Internet-Draft              Service Bindings                   July 2014


   include security considerations.  Service binding records SHOULD NOT
   be used in the absence of such specification.

   The current version of this proposal includes specifics for how
   service bindings might be used in the context of HTTP/2 as well as
   TLS/1.3.  It is expected that those would be split out to a separate
   draft.

4.  The Service Binding Record

   The service binding record is of the format:

       _Service._b.Name TTL Class B Priority Weight Target Parameters

   where:

   Service  The symbolic name of the desired service.
      An underscore (_) is prepended to the service identifier to avoid
      collisions with DNS labels that occur in nature.  In many
      specifications it is expected that the Service is likely to be the
      same as the URI Scheme [RFC3986] (such as "http" or "https").

   _b The literal label "_b", intended to prevent collisions with DNS
      labels that occur in nature.

   Name  The domain this RR refers to.  Similar to SRV RR [RFC2782], the
      name one searches for is not this name.

   TTL  Standard DNS meaning [RFC1035].

   Class  Standard DNS meaning [RFC1035].  B records occur in the IN
      Class.

   Priority  The priority of this service binding.  After filtering
      service bindings for protocols that it supports, the client MUST
      attempt to contact the target host with the lowest-numbered
      priority it can reach; target hosts with the same priority SHOULD
      be tried in an order defined by the weight field.  The range is
      0-65535.  This is a 16 bit unsigned integer in network byte order.

   Weight  A server selection mechanism.  The weight field specifies a
      relative weight for entries with the same priority.  Larger
      weights SHOULD be given a proportionately higher probability of
      being selected.  The range of this number is 0-65535.  This is a
      16 bit unsigned integer in network byte order.  Domain
      administrators SHOULD use Weight 0 when there isn't any server
      selection to do, to make the RR easier to read for humans (less
      noisy).  In the presence of records containing weights greater



Nygren                   Expires January 4, 2015                [Page 5]


Internet-Draft              Service Bindings                   July 2014


      than 0, records with weight 0 should have a very small chance of
      being selected.  Clients SHOULD use the same weight selection
      algorithm as described in [RFC2782].

   Target  The domain name of the target host.  There MUST be one or
      more address records for this name (A RR's and/or AAAA RR's, or
      their most modern equivalent).  The name MAY be a CNAME alias (in
      the sense of [RFC1034]).  Implementors are encouraged, but not
      required, to return the address record(s) in the Additional Data
      section where possible and appropriate.  Unless and until
      permitted by future standards action, name compression is not to
      be used for this field.

      The special target value of "." indicates that this service is not
      available on this domain.  When used, the RRset MUST contain only
      this single record.  However, the record MAY have additional
      parameters (not yet defined), such as to specify that an alternate
      service should be used instead.

   Parameters  A collection of tag:value parameters specifying
      additional attributes for this service binding.  These are encoded
      in canonicalized CBOR [RFC7049] using the map data type.  Their
      textual representation is JSON, with binary byte arrays (such as
      literal keys) being base64 [RFC4648] encoded.  While some tags are
      defined here, additional tags may be defined in the specifications
      for the particular Service, as well as in specifications for
      additional protocols for implementing the Service.

4.1.  B record RDATA encoding

   _A more formal definition of the RDATA encoding and parameter textual
   representation syntax will be included in a future version of this
   draft once the core concepts have stabilized._

4.2.  Service Binding Parameters

   The parameters of the B record provide extensibility, allowing
   additional parameters to be specified depending on the particular
   service and protocol.

   Clients MUST use parameters to filter out service bindings specifying
   protocols or other parameters that they do not support, as specified
   by those parameters.

   Any parameters not specified in the initial specification of Service
   Binding usage for a given Service and protocol combination must be
   capable of being safely ignored by a client.




Nygren                   Expires January 4, 2015                [Page 6]


Internet-Draft              Service Bindings                   July 2014


   Some parameters MUST NOT be used by a client unless all relevant DNS
   records can be securely validated, such as with DNSSEC [RFC2535].
   This means that both the B record, any aliases leading to it, and any
   aliases and records leading from names specified in that parameter
   must be validated.  This is discussed in more length in Security
   Considerations [1].

   The specification for any given parameter SHOULD include:

   o  The tag used to identify the parameter

   o  The valid type and allowed value ranges for the parameter

   o  Whether the parameter is optional, and its default value if not

   o  What is the behavior if the DNS records can not be securely
      validated

   o  A description of how the client should use the parameter value

4.3.  Standard Service Binding Parameters

   Application Layer Protocol (tag "a")  A string representing the
      application layer protocol to be used when contacting the service.
      The valid values are service-dependent and should be the same
      values as used in ALPN [I-D.ietf-tls-applayerprotoneg].  For
      example, "h2" represents HTTP/2.

      If not specified, the default application-layer protocol for the
      given service is assumed.

      Clients MUST filter out service bindings utilizing application
      layer protocols that they do not support or recognize, as well as
      to use the proper application protocol when contacting servers
      using this binding.

   Transport Layer Protocol (tag "t")  A string representing the
      transport layer protocol to be used when contacting the service.
      The valid values are service dependent.  For example, "tcp" is
      likely to be used for many services.

      If not specified, the default transport-layer protocol for the
      given service is assumed.

      Clients MUST filter out service bindings utilizing transport layer
      protocols that they do not support or recognize, as well as to use
      the proper transport protocol when contacting servers using this
      binding.



Nygren                   Expires January 4, 2015                [Page 7]


Internet-Draft              Service Bindings                   July 2014


      _Note for discussion: it may make sense to omit this as a separate
      parameter and to have the Application Layer Protocol tag describe
      the entire stack, as in_ [I-D.ietf-httpbis-http2].

   Transport Layer Port (tag "tp")  An integer specifying the transport
      layer protocol port to be used when contacting the service.  The
      valid values are transport layer protocol dependent.

      If not specified, the default port for the given service and
      transport protocol is assumed.

4.4.  Optional Security Parameters

   The following parameters should likely move to separate
   specifications:

   DANE Certificate Controls  (tag "dane")  The value of this optional
      parameter is a DNS domain name pointing to a DANE TLSA [RFC6698]
      record associated with this service binding.

      This is particularly useful to bind TLSA records with specific
      servers, especially in the case where different servers have
      different certificates and perhaps even different operators.

      This is also useful to indicate that TLSA records are available
      (to reduce the need for speculative DNS lookups)

      If relevant DNS records can not be securely validated, clients
      MUST NOT loosen their security policies based on the TLSA record.
      However, clients MAY use the record to apply more restrictive
      policies even if the TLSA record could not be securely validated.

      In particular, if this parameter is present, a client SHOULD
      resolve the named TLSA record and use it to constrain the TLS
      server certificates that it will accept.  If the the relevant DNS
      records can not be securely validated, the TLSA record must only
      be used in addition to policies already enforced by the client.
      For example, if a "CA Constraint" certificate usage is specified,
      then this SHOULD limit the CA allowed to those specified in the
      TLSA record(s), but only if the CA is also in a trust chain that
      the client would already accept.

   TLS Handshake Parameters (tag "tlshp")  This optional parameter
      specifies ServerParameters for bootstrapping the TLS 1.3
      handshake, such as for encrypting the SNI and other parts of the
      ClientHello to make them less vulnerable to passive eavesdropping
      [I-D.rescorla-tls13-new-flows].




Nygren                   Expires January 4, 2015                [Page 8]


Internet-Draft              Service Bindings                   July 2014


      The value of this parameter is a list containing the binary values
      of the ServerParameter label followed by the ServerDHParams or
      ServerECDHParams.

      Clients MAY use these values even if the B record is not securely
      validated, as the intent of these parameters is to protect against
      passive eavesdropping.  Note that there may be limited value in
      handshake encryption unless DNS lookups are also encrypted.

4.5.  Examples for other possible future Parameters

   Some of these may also make sense to include in an future version of
   this draft:

   o  A parameter indicating that this DNS record must have been
      securely validated (such as with DNSSEC) or must otherwise be
      skipped.  This could allow for incremental deployment of DANE-
      managed certificates on some alternate set of servers even without
      universal DNSSEC adoption.

   o  Minimum and/or maximum version of a protocol supported.  (For
      example, this could be helpful to mitigate downgrade attacks.)

   o  Which extensions to a protocol are supported, allowing a client to
      opportunistically send them in its handshake.

   o  Hints as to whether a target address record has A and/or AAAA
      records.  (Careful consideration would need to be given to how
      this played with DNS64 as well as other transition technologies.)
      A reasonable compromise would be to have a hint indicating that a
      AAAA record was available and encouraged (such that clients might
      wait longer to get a response from nameservers) as well as a
      separate hint indicating that no A record is available.

   o  Selected Service Binding Indicator - a label that can be passed
      from client to server indicating which service binding it
      selected.  This may be helpful for both load reporting/feedback,
      and diagnostics.

   o  HSTS-style [RFC6797] indicator parameter.  This would be returned
      along with a target of "." on a less secure service to indicate
      that a more secure scheme/service should be used (such as "https"
      instead of "http").  This might be a boolean "sts=1" parameter,
      such as with a record like:

   _http._b.www.example.com 2D IN B 0 0 . { "sts": 1 }





Nygren                   Expires January 4, 2015                [Page 9]


Internet-Draft              Service Bindings                   July 2014


5.  Selecting a Service Binding to Use

   When a client supporting Service Bindings wishes to make a connection
   to a service, it SHOULD query the B records for the service.  It MAY
   choose to opportunistically also issue DNS queries for the address
   records (eg, A and AAAA) to reduce the latency for the case where no
   B record is available.

5.1.  Handling B record responses

   In the case where an RRset for B records is returned, the client
   should:

   1.  Filter out any B RR's from the RRset which it does not support.
       In particular, it MUST ignore any B records containing an
       Application Layer Protocol that is unknown, unsupported, or
       explicitly disallowed for the particular service.

   2.  The remaining B RR's should be sorted by priority.  An entry
       should be selected from the top priority (lowest numeric priority
       value).  It multiple records have the same priority, the
       weighting algorithm specified in [RFC2782] SHOULD be used to
       order them.

   3.  The client should attempt to contact the service using the
       parameters specified in the first selected record from the sorted
       list.

   4.  If a given attempt fails, the client MAY attempt to contact the
       service using the next record in the sorted list.  After some
       number of tries, the client MAY attempt to contact the service
       directly using the address records for the domain.

5.2.  Handling a lack of Service Binding records

   Not all clients will immediately implement Service Binding records
   for any given Service, and administrators may not always put Service
   Binding records in-place.  Just as importantly, experiments have
   shown that new DNS RR types take awhile before they are accessible to
   most clients.  (_Reference needed_)

   As such, client SHOULD directly lookup and use the address records
   for the domain name when no valid B record is unavailable.  In this
   case, the default application and transport layer protocols SHOULD be
   used.  Clients and Servers MAY then use inline upgrade or signaling
   mechanisms such as AltSvc [I-D.ietf-httpbis-alt-svc] or ALPN
   [I-D.ietf-tls-applayerprotoneg] for upgrading to newer protocols
   instantiating the Service.



Nygren                   Expires January 4, 2015               [Page 10]


Internet-Draft              Service Bindings                   July 2014


6.  Operational Examples

   A few illustrative examples follow to help to demonstrate how Service
   Binding records might be used.  More examples may be added in a
   future version of this draft.  (_In particular, an example should be
   added on how a client might resolve and use some specific B records.)

6.1.  Example: Moving a service and domain between operators

   A common deployment model is for different administrators (and
   sometimes entirely separate organizations) to operate the DNS for a
   domain than those that operate a service on the domain.  Either or
   both might even be out-sourced to separate entities such as a
   hosting/infrastructure provider or Content Delivery Network (CDN).
   It is critical that it be possible to move domains and services
   between operators and administrators without any disruption in
   service and with minimal coordination between the different
   organizations.  Service Binding records simplify this by allowing a
   delegation of name via a single DNS alias per service/domain.  All
   other properties (such as TLSA records) then follow directly along
   from this.

   For example with:

   _https._b.www.example.com.
            6H IN CNAME _https._b.www.example.com.example-1.net.

   _https._b.www.example.com.example-1.net.
            6H IN B 0 0 server-primary.example-1.net.
            { "a": "h2",
            "dane": "_443._tcp.server-primary-www-cert.example-1.net.",
            "tlshp": ["JgxJkCv0va0", "OBZVN8LPo+SB9eQ/"] }

   the administrator of the example.com DNS zone delegated control over
   www.example.com to an operator example-1.net.

   In the example above, it would be recommended for the example-1.net
   authorities to also return ADDITIONAL records for the "server-
   primary.example-1.net." address records and for the
   "_443._tcp.server-primary-www-cert.example-1.net."  TLSA record along
   with the B record response.

   The DANE TLSA records and TLS 1.3 handshake parameters and supported
   Application Layer Protocols are bound in this case to the "server-
   primary.example-1.net." target as they should be.  If the
   administrator of example.com were to move the "www.example.com."
   CNAME to point to a different operator (eg, "example-2.net"), that




Nygren                   Expires January 4, 2015               [Page 11]


Internet-Draft              Service Bindings                   July 2014


   second operator would provide their own service bindings which
   clients would use as a unit.

   The value of this Service Binding approach can be seen here when
   contrasting against having multiple independent records, each with
   their own TTL.  For example, if "www.example.com" is a CNAME to
   address records on example-1.net and "_443._tcp.www.example.com" is a
   CNAME to TLSA records on example-1.net, there is no way to change
   either of these CNAMEs to point to example-2.net without a situation
   where some clients are getting address records for example-1 and TLSA
   records for example-2, resulting in a possible denial-of-service.

7.  Open Areas for Discussion

   As this is a early version of this draft, a number of design choices
   are still open for active discussion:

   o  What encoding should be used for the Parameters?  Some options
      include:

      *  CBOR [RFC7049] - has the advantage of allowing new parameters
         to be added with self-describing types in a way that unknown
         new parameters can be ignored.

      *  Something ad-hoc, such as the tag-value system of DKIM
         [RFC6376] section 3.2.  This might be more compact, but also
         ends up being more ad-hoc.

      *  What textual representation should be used?  JSON, or something
         more in-line with other DNS record types?  The illustrative
         examples here use JSON for the time-being.

   o  Should there be a more formal general definition of the transport
      vs protocol layering and filtering?  It may be preferable to have
      a single identifier (ALPN) specifying the full stack.

      *  Which layers should be included?  More or less?

      *  How does TLS fit in?

      *  What more examples should we give?

   o  How much do we need to worry about packet size limitations, and
      what can we do about them?

      *  Should we do any form of name compression?

      *  Should we allow names (such as the DANE names) to be relative?



Nygren                   Expires January 4, 2015               [Page 12]


Internet-Draft              Service Bindings                   July 2014


   o  Should the TLS 1.3 handshake parameters move to their own record
      that is just named from the B record?

   o  What should be the name of the Resource Record type: is "B" a good
      name, or should something longer such as "SB" or "SBND" be used?

   o  What should be a standard part of the record and what should be
      parameters?  Everything could be a parameter, including priority
      and target and weight.  In the other direction, some existing
      parameters could be standard.  There may be a reasonable balance
      in the current proposal.

   o  There is an operational risk that the B record and normal address
      records (A and AAAA) could diverge over time due to administrative
      management skew.  For a CDN or hosting provider, taking advantage
      of B records also means that the content provider would need to
      CNAME over an additional records per-service.

   o  We may want to give examples of additional use-cases where this is
      helpful:

      1.  Apex zone domain names - can be used instead of a CNAME to
          delegate over to a CDN or hosting provider

      2.  Dealing with the SNI challenge for TLS: specify that clients
          using a Service Binding MUST send TLS SNI.  This would allow
          the use of a larger set of SNI-only servers for the B record
          targets than for the normal address records on the domain,

   o  Should there be a parameter to indication which service binding
      was used when making a connection?  In particular, a parameter
      which is a label or string that gets passed from the client to the
      server (such as a response header or as "Indicated Service")?

   o  Why a separate domain name (eg, "_http._b.www.example.com") rather
      than just a record on "www.example.com" (as in the DANISH
      proposal)?

      *  The reason is that you _do_ want a separate name-per-service,
         as otherwise the RRset will get too big if you have multiple
         names.

      *  Is the "_b" actually needed?  Or could this just be
         "_http.www.example.com" ?

   o  Which of the additional parameters above should we include in
      subsequent versions of this draft?




Nygren                   Expires January 4, 2015               [Page 13]


Internet-Draft              Service Bindings                   July 2014


8.  IANA Considerations

   The IANA will need to assign an RR type value to the B RR.

   The IANA will also need to maintain a registry of Parameters allowed
   B RRs.  (Details on this will need to be expanded in a future version
   of this draft.)

9.  Security Considerations

   Service Bindings have many of the same security issues as SRV records
   or most other DNS record types (such as A and AAAA address records).
   In particular, if the client is not securely validating DNS
   resolutions then a man-in-the-middle attacker could trick a client
   into contacting an attacker selected server and port and protocol.
   Similar attacks could also force a client to downgrade to a less
   secure protocol or to fall back to using address records.

   Clients MAY chose to bound the TTLs of B RRsets to a reasonable value
   and/or forget B RRsets on network changes to limit the damage that
   can be done by such a man-in-the-middle.

   For each service binding parameter type, specific attention must be
   paid to the security considerations relevant to it.  In particular:

   Application Layer Protocol  Care must be taken to disallow and filter
      out any invalid ALPN and Service combinations.  For example,
      clients MUST NOT allow ALPN "h2c" in combination with Service
      "https".

   DANE Certificate Controls  DANE TLSA records can be used to either
      restrict the set of allowed server certificates to a subset of
      those that a client would normally allow.  They can also be used
      to specify alternate certificates or trust roots to use for
      validation, relying on DNSSEC instead of the CA hierarchy.

      If a man-in-the-middle attacker can inject DNS responses (and the
      client is not securely validating the responses), then in the
      former case the attacker can only force a denial-of-service by
      causing the client to fail its validation.  Allowing this may be
      an acceptable trade-off to allow administrators to limit the scope
      of allowed certificates even for clients not performing
      validation.  As such, clients MAY use B and TLSA records to
      constrain allowed certificates to a strict subset of those that
      would otherwise be allowed.

      However, in the former case (where alternate certificates that are
      not ones a client would already trust can be specified), an



Nygren                   Expires January 4, 2015               [Page 14]


Internet-Draft              Service Bindings                   July 2014


      attacker or unscrupulous DNS resolver operator could utilize this
      to force a client to trust an adversary-controlled server.  As
      such, clients MUST NOT use DANE TLSA records unless the B RRset,
      the TLSA RRset, all aliases (eg, CNAMEs) pointing to them, and all
      authorities of these can be securely validated.

   (_Additional security considerations will need to be added to a
   future version of this draft._)

10.  Acknowledgments

   This draws heavily on many previous DNS RFCs such as [RFC2782].

   Discussions with Eric Rescorla, Daniel Kahn Gilmore, Mark Nottingham,
   and others on the TLS and HTTPBIS working groups have heavily
   influenced this proposal.  Suggestions from Richard Barnes and others
   have also been incorporated into this draft.

11.  References

11.1.  Normative References

   [I-D.ietf-tls-applayerprotoneg]
              Friedl, S., Popov, A., Langley, A., and S. Emile,
              "Transport Layer Security (TLS) Application Layer Protocol
              Negotiation Extension", draft-ietf-tls-applayerprotoneg-05
              (work in progress), March 2014.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

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

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

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.




Nygren                   Expires January 4, 2015               [Page 15]


Internet-Draft              Service Bindings                   July 2014


   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [RFC6797]  Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
              Transport Security (HSTS)", RFC 6797, November 2012.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, October 2013.

11.2.  Informative References

   [I-D.ietf-httpbis-alt-svc]
              Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", draft-ietf-httpbis-alt-svc-01 (work
              in progress), April 2014.

   [I-D.ietf-httpbis-http2]
              Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
              Protocol version 2", draft-ietf-httpbis-http2-13 (work in
              progress), June 2014.

   [I-D.rescorla-tls13-new-flows]
              Rescorla, E., "New Handshake Flows for TLS 1.3", draft-
              rescorla-tls13-new-flows-01 (work in progress), February
              2014.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
              September 2011.

11.3.  URIs

   [1] #security

Author's Address

   Erik Nygren
   Akamai Technologies

   Email: erik+ietf@nygren.org
   URI:   http://erik.nygren.org/






Nygren                   Expires January 4, 2015               [Page 16]