Skip to main content

DANE TLSA implementation and operational guidance
draft-dukhovni-dane-ops-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Viktor Dukhovni
Last updated 2013-05-19
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dukhovni-dane-ops-00
DANE                                                         V. Dukhovni
Internet-Draft                                              Unaffiliated
Updates: 6698 (if approved)                                 May 19, 2013
Intended status: Informational
Expires: November 20, 2013

           DANE TLSA implementation and operational guidance
                       draft-dukhovni-dane-ops-00

Abstract

   This memo discusses some operational aspects of publishing and using
   DANE TLSA records.  Server operators need to consider whether the
   intended clients are able to authenticate the server's certificate
   chain via the published TLSA records, some variations of TLSA records
   may not work as expected in all cases.  Clients need to decide which
   variations of TLSA records are sufficiently robust to be usable for
   server authentication.

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 November 20, 2013.

Copyright Notice

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

Dukhovni               Expires November 20, 2013                [Page 1]
Internet-Draft              DANE operations                     May 2013

   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  DANE TLSA record overview . . . . . . . . . . . . . . . . . .   3
   3.  Obligations of TLSA record creator and consumer . . . . . . .   5
   4.  TLSA record usability . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Non-PKIX application protocols  . . . . . . . . . . . . .   6
     4.2.  TLSA records and trust anchor digests . . . . . . . . . .   7
     4.3.  Trust anchor public keys  . . . . . . . . . . . . . . . .   9
   5.  Note on DNSSEC security . . . . . . . . . . . . . . . . . . .  10
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The Domain Name System Security Extensions (DNSSEC) add data origin
   authentication and data integrity to the Domain Name System.  DNSSEC
   is defined in [RFC4033], [RFC4034] and [RFC4035].

   In the context of this memo channel security is assumed to be
   provided by TLS.  The Transport Layer Security (TLS) protocol
   provides communications privacy over the Internet.  Used without
   authentication, TLS provides protection only against eavesdropping.
   With authentication, TLS also provides protection against man-in-the-
   middle (MITM) attacks.  Since the publication of the TLS 1.0
   specification in [RFC2246], two updates to the protocol have been
   published: TLS 1.1 [RFC4346] and TLS 1.2 [RFC5246].

   As described in the introduction of [RFC6698] TLS authentication via
   the existing public CA PKI suffers from an over-abundance of trusted
   certificate authorities capable of issuing certificates for any
   domain of their choice.  DNS-Based Authentication of Named Entities
   (DANE) leverages the DNSSEC infrastructure to publish trusted keys
   and certificates for use with TLS via a new TLSA record type.  DNSSEC
   validated DANE TLSA records yield a new PKI designed to augment or
   replace the trust model of the existing public CA PKI.

   When a client goes to the trouble of authenticating a server it
   should not continue to use the server in case of authentication

Dukhovni               Expires November 20, 2013                [Page 2]
Internet-Draft              DANE operations                     May 2013

   failure, otherwise authentication is pointless.  Consequently, if a
   client cannot reliably authenticate correctly configured legitimate
   servers via a particular combination of TLSA parameters, then the
   client SHOULD treat that combination of parameters as unusable,
   otherwise the client risks routinely dropping connections to legimate
   servers.  Servers publishing TLSA records MUST be configured in a
   manner that allows correctly configured clients to successfully
   authenticate the server.

1.1.  Terminology

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

   This memo is being discussed on the dane@ietf.org mailing list.

2.  DANE TLSA record overview

   [RFC6698] specifies a protocol for publishing TLS server certificate
   associations via DNSSEC.  The DANE TLSA specification defines
   multiple TLSA RR types via combinations of the following 3
   parameters:

   o  The certificate usage field.  Section 2.1.1 of [RFC6698] specifies
      4 values ranging from 0 to 3.

   o  The selector field.  Section 2.1.2 of [RFC6698] specifies 2 values
      ranging from 0 to 1.

   o  The matching type field.  Section 2.1.3 of [RFC6698] specifies 3
      values ranging from 0 to 2.

   We may consider the certificate usage values 0 through 3 to be a
   combination of two one-bit flags.  The low-bit chooses between trust-
   anchor (TA) and end-entity (EE) certificates.  The high bit chooses
   between public PKI issued and domain issued certificates:

   o  When the low bit is set (certificate usages 1 and 3) the TLSA
      record matches an EE (server) certificate.

   o  When the low bit is not set (certificate usages 0 and 2) the TLSA
      record matches a TA, that is a certificate authority that
      ultimately issued the server certificate, possibly through a chain
      if intermediate certificate authorities.  In this context
      [RFC6125] specifies how to match the TLS server name against the
      contents of the leaf certificate (name matching with PKIX is
      rather complex with many application-specific variations).

Dukhovni               Expires November 20, 2013                [Page 3]
Internet-Draft              DANE operations                     May 2013

   o  When the high bit is set (certificate usages 2 and 3) the server
      certificate chain is domain-issued and may be verified without
      reference to the existing public certificate authority PKI, with
      trust entirely based on the content of the TLSA records obtained
      from DNS.

   o  When the high bit is not set (certificate usages 0 and 1) the TLSA
      record publishes a server policy to the effect that the
      certificate chain must pass PKIX validation [RFC5280], with the
      DANE TLSA record used to specify which trusted public CA may be
      used to validate the server certificate chain.

   The selector field specifies whether the TLSA RR matches the whole
   certificate or just its subjectPublicKeyInfo (i.e.  an ASN.1 DER
   encoding of the algorithm, parameters and key data).  In this memo
   the term public key will be an informal short-hand for the
   subjectPublicKeyInfo.  A selector field of "0" specifies the whole
   certificate.  A selector field of "1" specifies just the public key.

   The matching type field specifies how the TLSA RR Certificate
   Association Data field is to be compared with the certificate or
   public key.  A value of "0" means exact match, the DER encoding of
   the certificate or public is given in the TLSA RR.  A non-zero value
   indicates that the content of the TLSA RR is a cryptographic digest
   of the certificate or public key.  In particular "1" means a SHA-256
   digest and "2" means a SHA-512 digest.  Of these, only SHA-256 is
   mandatory to implement.  Clients SHOULD implement SHA-512, but
   servers SHOULD NOT exclusively publish SHA-512 digests.

   In the example TLSA record below:

   _25._tcp.mail.example.com. IN TLSA 3 1 2 (
                                 E8B54E0B4BAA815B06D3462D65FBC7C0
                                 CF556ECCF9F5303EBFBB77D022F834C0
                                 5DC75F17F9963DF8A572A5B9209CF1AB
                                 9DC14CD0C0C8393072D49365017553F8 )

   The certificate usage is "3", the selector is "1" and the matching
   type is "2".  The rest of the record is the certificate association
   data field, which is in this case the SHA-512 digest of the server
   public key.

Dukhovni               Expires November 20, 2013                [Page 4]
Internet-Draft              DANE operations                     May 2013

3.  Obligations of TLSA record creator and consumer

   The party responsible for creating TLSA records for a given service
   MUST ensure that at least one of these TLSA records will match either
   the server's default certificate chain if SNI is not employed on the
   server, or the server's certificate chain when the client signals the
   base domain of the TLSA RRset via SNI with a name type of "host_name"
   (see [RFC3546] Section 3.1).

   When, for example, the TLSA RRset is published at

        _25._tcp.mx1.example.com

   the base domain is mx1.example.com.  At least one of the TLSA records
   in the RRset MUST match the server certificate chain, provided the
   client TLS hanshake included the SNI extension with a host_name of
   mx1.example.com.

   Since the server's ability to respond with the right certificate
   chain may be predicated on the TLS client providing the correct SNI
   information, DANE PKI aware clients SHOULD send the SNI extension
   with a host_name value of the base domain of the TLSA RRset
   (otherwise they risk failure to authenticate the server).  Since SNI
   is not available with SSLv2 or SSLv3, the server MUST support at
   least TLS 1.0; ensuring this is the case is the responsibility of the
   creator of the TLSA records.

   Complications arise when TLSA records for a service are created by
   someone other than the server operator.  In this situation the server
   operator and TLSA record creator must cooperate to ensure that TLSA
   records don't fall out of step with the server certificate
   configuration.

   When the server operator is a hosting provider, ideally the
   application protocol allows the hosted customer to direct clients to
   the hosting provider's servers.  This way, the associated TLSA
   records will be found in the hosting provider's DNSSEC zone, thus
   avoiding the complexity of bilateral coordination of server
   certificate configuration and TLSA record management.

   For example, with SMTP, the customer's MX records can be pointed at
   the provider's MX hosts.  When the customer's DNS zone is signed, the
   hostnames in that domain's MX records can be securely used as the
   base names for TLSA records managed by the hosting provider.

   When the protocol does not support service location indirection via
   MX, SRV or similar DNS records, the service may be redirected via a

Dukhovni               Expires November 20, 2013                [Page 5]
Internet-Draft              DANE operations                     May 2013

   CNAME.  A CNAME is a more blunt instrument for this purpose, since
   unlike an MX or SRV record it remaps the origin host to the target
   host for all protocols.  Also Unlike MX or SRV records CNAME records
   may chain (though clients will generally impose implementation
   dependent maximum nesting depths).

   When CNAMEs are employed the sensible place to seek DANE TLSA records
   is in the providers domain, as that is the party that best knows
   which certificates are deployed on the server.  Therefore, DANE PKI
   clients connecting to a server whose DNS name is a CNAME alias SHOULD
   follow the CNAME hop-by-hop to its ultimate target host (noting at
   each step whether the CNAME is DNSSEC validated) and use the
   resulting target host as the base domain for TLSA lookups.

   If CNAMEs were not followed, to support DANE validation the origin
   domain would have to publish TLSA records that match the server
   certificate chain.  Since the origin domain may not be operationally
   responsible for the server this imposes a complex key management
   burden on the hosting provider and hosted customer even with SNI.

   Accordingly, TLSA records SHOULD NOT be published for a base domain
   that is a CNAME.  Such TLSA records are not operationally robust, and
   SHOULD NOT be used by clients.

   Though CNAMEs are illegal on the right hand side of MX and SRV
   records, they are supported by some implementations.  If the MX or
   SRV host is a CNAME alias from a customer's domain to a server in the
   provider's domain, the client SHOULD follow the CNAME and SHOULD use
   the target hostname as the base domain for TLSA records as well as
   the host_name in SNI.

4.  TLSA record usability

4.1.  Non-PKIX application protocols

   For some application protocols the existing public CA PKI is not
   viable.  For these (non-PKIX) protocols servers SHOULD NOT publish
   TLSA records with certificate usage "0" or "1", as clients cannot be
   expected to perform [RFC5280] PKIX validation or [RFC6125] Identity
   verification.

   Clients using non-PKIX protocols MAY choose to treat any TLSA records
   with certificate usage "0" or "1" as unusable.  They may then choose
   to connect via unauthenticated mandatory TLS if no alternative
   authentication mechanisms are available.

Dukhovni               Expires November 20, 2013                [Page 6]
Internet-Draft              DANE operations                     May 2013

   If despite this recommendation servers for non-PKIX protocols do
   publish TLSA records with certificate usage "0" or "1", clients
   should should make use of these to the fullest extent possible.

4.1.1.  Certificate usage 1

   With certificate usage "1" such clients SHOULD ignore the PKIX
   validation requirement, and authenticate the server per the content
   of the TLSA record alone.  Since some servers may rely on SNI to
   select the correct certificate, the client SHOULD use the SNI
   extension to signal the base domain of the TLSA RRset.

4.1.2.  Certificate usage 0

   With certificate usage "0" the usability of the TLSA records depends
   on its matching type.

   If the matching type is "0" the TLSA record contains the full
   certificate or full public key of the trusted certificate authority.
   In this case the client has all the information it needs to match the
   server trust-chain to the TLSA record.  The client SHOULD in this
   case ignore the PKIX validation requirement, and authenticate the
   server via its DANE TLSA records alone (sending SNI with the base
   domain as usual).  The base domain of the TLSA records will be used
   in name checks.

   If the matching type is not "0", the TLSA record contains only a
   digest of the trust certificate authority certificate or public key.
   The full certificate may not be included in the server's certificate
   chain and the client may not be able to match the server trust chain
   against the TLSA record.  See Section 4.2.1 for a more complete
   discussion of this case.  The client cannot reliably authenticate the
   server in this case and SHOULD treat the TLSA record as unusable.

   If the client is configured with a set of trusted CAs believed to be
   sufficiently complete to authenticate all the servers with which it
   expects to communicate, then it MAY elect to honor certificate usage
   "0" TLSA records that publish digests of the trusted CA certificate
   or public key.

4.2.  TLSA records and trust anchor digests

   With TLSA records that match the EE certificate, the TLS client has
   no difficulty matching the TLS record against the server certificate,
   as this certificate is always present in the TLS server certificate
   chain.  The TLS client can if necessary extract the public key from
   the server certificate, and can if necessary compute the appropriate
   digest.

Dukhovni               Expires November 20, 2013                [Page 7]
Internet-Draft              DANE operations                     May 2013

   With DANE TLSA records that match the digest of TA certificate or
   public key, a complication arises when the TA certificate is omitted
   from the server's certificate chain.  This can happen when the trust-
   anchor is a root certificate authority, as stated in section 7.4.2 of
   [RFC2246]:

        The sender's certificate must come first in the list.
        Each following certificate must directly certify the one
        preceding it.  Because certificate validation requires
        that root keys be distributed independently, the
        self-signed certificate which specifies the root
        certificate authority may optionally be omitted from the
        chain, under the assumption that the remote end must
        already possess it in order to validate it in any case.

   This means that TLSA records that match a TA certificate or public
   key digest are not directly sufficient to validate the peer
   certificate chain.  If no matching certificate is found in the
   server's certificate chain, the chain may be signed by an omitted
   root CA whose digest matches the TLSA record.  We will consider each
   trust-anchor certificate usage in turn.

4.2.1.  Trust anchor digests with certificate usage 0

   In this case, from the server's perspective, the omission of the root
   CA seems reasonable, since in addition to authentication via DANE
   TLSA records the client is expected to to perform [RFC5280] PKIX
   validation of the server's trust chain and thus to already have a
   copy of the omitted root certificate.

   From the client's perspective the situation is more nuanced.  Despite
   the server's indicated preference for PKIX validation the client may
   not posess (or may not fully trust) a complete set of public root
   CAs.  This is especially likely in protocols where the existing
   public CA PKI is not applicable.  If it is likely that a client lacks
   a sufficiently complete list of trusted CAs, and that a non-
   negligible number of servers publish certificate usage 0 TLSA records
   with digests of omitted root CAs, then such a client SHOULD treat
   such TLSA records as "unusable".  Simply ignoring PKIX validation is
   not an option, since the client will also be unable to match the TLSA
   record.  The client will then typically fall back to unauthenticated
   TLS, as by assumption PKIX is also not an option (see
   [I-D.ietf-dane-srv]).

4.2.2.  Trust anchor digests with certificate usage 2

Dukhovni               Expires November 20, 2013                [Page 8]
Internet-Draft              DANE operations                     May 2013

   Here there is no expectation that the client is pre-configured with
   the trust anchor certificate.  With certificate usage "2" clients
   rely on the TLSA records alone, but with a matching type other than
   "0" the TLSA records contain neither the full trust anchor
   certificate nor the full public key.  If the server's certificate
   chain does not contain the trust-anchor certificate, most clients
   will be unable to authenticate the server.

   Therefore, whoever creates TLSA records with certificate usage "2"
   and a non-zero matching type MUST ensure that the corresponding
   server is configured to include the associated trust anchor
   certificate in its TLS handshake certificate chain even if that
   certificate is a self-signed root CA and would have been optional in
   the context of the existing public CA PKI.

   Since servers are expected to always provide usage "2" trust anchor
   certificates (either via DNS or else via the TLS hanshake), clients
   SHOULD fully support this certificate usage.  Clients MAY choose to
   treat it as unusable if experience proves that servers don't
   consistently live up to their obligations.

4.3.  Trust anchor public keys

   TLSA records with certificate usage "0" or "2", selector "1" and a
   matching type of "0" publish the full public key of a trust anchor
   via DNS.  In section 6.1.1 of [RFC5280] the definition of a trust
   anchor consists of the following four parts:

   1.  the trusted issuer name,

   2.  the trusted public key algorithm,

   3.  the trusted public key, and

   4.  optionally, the trusted public key parameters associated with the
       public key.

   Items 2-4 are precisely the contents of the subjectPublicKeyInfo
   published in the TLSA record, but the issuer name is not included in
   the public key.

   With certificate usage "0" when the client is able to perform PKIX
   validation, the client can construct a complete PKIX trust chain and
   thus has access to the trust anchor name.  So in that case the client
   can verify that the server certificate chain is issued by a trust
   anchor that matches the TLSA record.

Dukhovni               Expires November 20, 2013                [Page 9]
Internet-Draft              DANE operations                     May 2013

   With certificate usage "2" or with certificate usage "0" for a non-
   PKIX protocol, the client may not have the missing trust anchor
   certificate, and cannot generally verify whether a particular
   certificate chain is "issued by" the trust anchor described in the
   TLSA record.  If the server certificate chain includes a CA
   certificate whose public key matches the TLSA record, the client can
   match that CA as the intended issuer.  Otherwise, the client can only
   check that the topmost certificate in the server's chain is "signed
   by" by the trust anchor public key in the TLSA record.

   Since trust chain validation via bare public keys rather than trusted
   CA certificates may be difficult to implement in existing TLS
   applications, servers MUST include the trust anchor certificate in
   their certificate chain when the certificate usage is "2".  With non-
   PKIX protocols servers SHOULD avoid publishing TLSA records with
   certificate usage "0", but if they do, they SHOULD include any trust
   anchor certificates in the TLS certificate chain.

   If none of the server's certificate chain elements match a public key
   specified in full in a TLSA record, clients SHOULD attempt to check
   whether the topmost certificate in the chain is signed by the
   provided public key, and if so consider the server trust chain valid,
   with authentication complete if name checks are also successful.

5.  Note on DNSSEC security

   Clearly the security of the DANE TLSA PKI rests on the security of
   the underlying DNSSEC infrastructure.  While this memo is not a guide
   to DNSSEC security a few comments may be helpful to TLSA
   implementors.

   With the existing public CA PKI, name constraints are rarely used,
   and every public root CA can issue certificates for any domain of its
   choice.  With DNSSEC the situation is different.  Only the registrar
   of record can update a domain's DS record in the registry parent
   zone, in some cases of course the registry is the sole registrar.
   With gTLDs for which multiple registrars compete to provide domains
   in a single registry it is important to make sure that rogue
   registrars cannot easily initiate an unauthorized domain transfer,
   and thus take over DNSSEC for the domain.  A registrar lock on one's
   domain may be a reasonable precaution for this reason.

   When the registrar is also the DNS operator for the domain, when
   using DNSSEC one needs to consider whether the registrar will allow
   orderly migration of the domain to another registrar or DNS operator
   in a way that will maintain DNSSEC integrity.  Discuss this with your
   registrar DNS operator before it is an emergency.

Dukhovni               Expires November 20, 2013               [Page 10]
Internet-Draft              DANE operations                     May 2013

   DNSSEC signed RRsets cannot be securely revoked before they expire.
   Plan accordingly and don't generate signatures with excessively long
   duration.  For domains publishing high-value keys, a signature
   lifetime of a few days is reasonable, with the zone resigned every
   day or so.  For more mundane domains a good signature lifetime is a
   couple of weeks to a month, with the zone resigned every week or so.
   Monitoring of the signature lifetime is important.  If the zone is
   not resigned in a timely manner, one risks a major outage with the
   entire domain becoming invalid.

6.  Acknowledgements

   Thanks to Tony Finch who finally prodded me into participating in
   DANE working group discussions.  Thanks to Paul Hoffman who motivated
   me to produce this memo and provided feedback on early drafts.

7.  Security Considerations

   Application protocols that cannot make use of the existing public CA
   PKI (so called non-PKIX protocols), may choose to not implement
   certain PKIX-dependent TLSA record types defined in [RFC6698], or may
   choose to make a best-effort use of such records.  In neither case is
   security compromised, since by assumption PKIX verification is simply
   not an option for these protocols.  When the TLS server is
   authenticated based on the TLSA records alone, the client client is
   as well authenticated as possible, treating the TLSA records as
   unusable would lead to weaker security.

   Therefore, when TLSA records are used with protocols where PKIX does
   not apply, the recommended trade-off is for servers to not publish
   PKIX-dependent TLSA records, and for clients to use them as best they
   can, but otherwise treat them unusable.  Of course when PKIX
   validation is an option clients SHOULD perform PKIX validation per
   [RFC6698].

8.  References

8.1.  Normative References

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

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

Dukhovni               Expires November 20, 2013               [Page 11]
Internet-Draft              DANE operations                     May 2013

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

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

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

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.

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

8.2.  Informative References

   [I-D.ietf-dane-srv]
              Finch, T., "Using DNS-Based Authentication of Named
              Entities (DANE) TLSA records with SRV and MX records.",
              draft-ietf-dane-srv-02 (work in progress), February 2013.

Author's Address

   Viktor Dukhovni
   Unaffiliated

   Email: ietf-dane@dukhovni.org

Dukhovni               Expires November 20, 2013               [Page 12]