Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: DANE

RFC 7671

The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance

Pages: 33
Proposed STD
Updates:  6698
Part 2 of 2 – Pages 16 to 33
First   Prev   None

Top   ToC   Page 16   prevText
6.  Service Provider and TLSA Publisher Synchronization

   Whenever possible, the TLSA Publisher and the Service Provider should
   be the same entity.  Otherwise, they need to coordinate changes to
   ensure that TLSA records published by the TLSA Publisher don't fall
   out of sync with the server certificate used by the Service Provider.
   Such coordination is difficult, and service outages will result when
   coordination fails.

   Publishing the TLSA record in the Service Provider's zone avoids the
   complexity of bilateral coordination of server certificate
   configuration and TLSA record management.  Even when the TLSA RRset
   has to be published in the Customer Domain's DNS zone (perhaps the
   client application does not "chase" CNAMEs to the TLSA base domain),
   it is possible to employ CNAME records to delegate the content of the
   TLSA RRset to a domain operated by the Service Provider.

   Only certificate usages DANE-EE(3) and DANE-TA(2) work well with TLSA
   CNAMEs across organizational boundaries.  With PKIX-TA(0) or
   PKIX-EE(1), the Service Provider would need to obtain certificates in
   the name of the Customer Domain from a suitable public CA (securely
   impersonate the customer), or the customer would need to provision
   the relevant private keys and certificates at the Service Provider's

   Certificate Usage DANE-EE(3):  In this case, the Service Provider can
      publish a single TLSA RRset that matches the server certificate or
      public key digest.  The same RRset works for all Customer Domains
      because name checks do not apply with DANE-EE(3) TLSA records (see
      Section 5.1).  A Customer Domain can create a CNAME record
      pointing to the TLSA RRset published by the Service Provider.

   Certificate Usage DANE-TA(2):  When the Service Provider operates a
      private CA, the Service Provider is free to issue a certificate
      bearing any customer's domain name.  Without DANE, such a
      certificate would not pass trust verification, but with DANE, the
      customer's TLSA RRset that is aliased to the provider's TLSA RRset
      can delegate authority to the provider's CA for the corresponding
      service.  The Service Provider can generate appropriate
Top   ToC   Page 17
      certificates for each customer and use the SNI information
      provided by clients to select the right certificate chain to
      present to each client.

   Below are example DNS records (assumed "secure" and shown without the
   associated DNSSEC information, such as record signatures) that
   illustrate both of the above models in the case of an HTTPS service
   whose clients all support DANE TLS.  These examples work even with
   clients that don't "chase" CNAMEs when constructing the TLSA base
   domain (see Section 7 below).

   ; The hosted web service is redirected via a CNAME alias.
   ; The associated TLSA RRset is also redirected via a CNAME alias.
   ; Certificate usage DANE-EE(3) makes it possible to deploy
   ; a single provider certificate for all Customer Domains.
   ;            IN CNAME  IN CNAME    IN TLSA 3 1 1 (
                                   D86F300A343FECEFF19E89C27C896BC9 )

   ; A CA at the provider can also issue certificates for each Customer
   ; Domain and employ the DANE-TA(2) certificate usage to
   ; designate the provider's CA as a TA.
   ;            IN CNAME  IN CNAME    IN TLSA 2 0 1 (
                                   68615F28C69BD96A73E354CAC88ED00C )

   With protocols that support explicit transport redirection via DNS MX
   records, SRV records, or other similar records, the TLSA base domain
   is based on the redirected transport endpoint rather than the origin
   domain.  With SMTP, for example, when an email service is hosted by a
   Service Provider, the Customer Domain's MX hostnames will point at
   the Service Provider's SMTP hosts.  When the Customer Domain's DNS
   zone is signed, the MX hostnames can be securely used as the base
Top   ToC   Page 18
   domains for TLSA records that are published and managed by the
   Service Provider.  For example (without the required DNSSEC
   information, such as record signatures):

   ; Hosted SMTP service.
   ;               IN MX 0               IN MX 0  IN TLSA 3 1 1 (
                                 D86F300A343FECEFF19E89C27C896BC9 )  IN TLSA 3 1 1 (
                                 68615F28C69BD96A73E354CAC88ED00C )

   If redirection to the Service Provider's domain (via MX records, SRV
   records, or any similar mechanism) is not possible and aliasing of
   the TLSA record is not an option, then more complex coordination
   between the Customer Domain and Service Provider will be required.
   Either the Customer Domain periodically provides private keys and a
   corresponding certificate chain to the provider (after making
   appropriate changes in its TLSA records), or the Service Provider
   periodically generates the keys and certificates and needs to wait
   for matching TLSA records to be published by its Customer Domains
   before deploying newly generated keys and certificate chains.
   Section 7 below describes an approach that employs CNAME "chasing" to
   avoid the difficulties of coordinating key management across
   organizational boundaries.

   For further information about combining DANE and SRV, please see

7.  TLSA Base Domain and CNAMEs

   When the application protocol does not support service location
   indirection via MX, SRV, or similar DNS records, the service may be
   redirected via a CNAME.  A CNAME is a more blunt instrument for this
   purpose because, unlike an MX or SRV record, it remaps the entire
   origin domain to the target domain for all protocols.

   The complexity of coordinating key management is largely eliminated
   when DANE TLSA records are found in the Service Provider's domain, as
   discussed in Section 6.  Therefore, DANE TLS clients connecting to a
   server whose domain name is a CNAME alias SHOULD follow the CNAME
   "hop by hop" to its ultimate target host (noting at each step whether
   or not the CNAME is DNSSEC validated).  If at each stage of CNAME
   expansion the DNSSEC validation status is "secure", the final target
   name SHOULD be the preferred base domain for TLSA lookups.
Top   ToC   Page 19
   Implementations failing to find a TLSA record using a base name of
   the final target of a CNAME expansion SHOULD issue a TLSA query using
   the original destination name.  That is, the preferred TLSA base
   domain SHOULD be derived from the fully expanded name and, failing
   that, SHOULD be the initial domain name.

   When the TLSA base domain is the result of "secure" CNAME expansion,
   the resulting domain name MUST be used as the HostName in the
   client's SNI extension and MUST be the primary reference identifier
   for peer certificate matching with certificate usages other than

   Protocol-specific TLSA specifications may provide additional guidance
   or restrictions when following CNAME expansions.

   Though CNAMEs are illegal on the right-hand side of most indirection
   records, such as MX and SRV records, they are supported by some
   implementations.  For example, if the MX or SRV host is a CNAME
   alias, some implementations may "chase" the CNAME.  If they do, they
   SHOULD use the target hostname as the preferred TLSA base domain as
   described above (and, if the TLSA records are found there, also use
   the CNAME-expanded domain in SNI and certificate name checks).

8.  TLSA Publisher Requirements

   This section updates [RFC6698] by specifying that the TLSA Publisher
   MUST ensure that each combination of certificate usage, selector, and
   matching type in the server's TLSA RRset includes at least one record
   that matches the server's current certificate chain.  TLSA records
   that match recently retired or yet-to-be-deployed certificate chains
   will be present during key rollover.  Such past or future records
   MUST NOT at any time be the only records published for any given
   combination of usage, selector, and matching type.  The TLSA record
   update process described below ensures that this requirement is met.

   While a server is to be considered authenticated when its certificate
   chain is matched by any of the published TLSA records, not all
   clients support all combinations of TLSA record parameters.  Some
   clients may not support some digest algorithms; others may either not
   support or exclusively support the PKIX certificate usages.  Some
   clients may prefer to negotiate [RFC7250] raw public keys, which are
   only compatible with TLSA records whose certificate usage is
   DANE-EE(3) with selector SPKI(1).  The only other TLSA record type
   that is potentially compatible with raw public keys is "DANE-EE(3)
   Cert(0) Full(0)", but support for raw public keys with that TLSA
   record type is not expected to be broadly implemented.
Top   ToC   Page 20
   A consequence of the above uncertainty as to which TLSA parameters
   are supported by any given client is that servers need to ensure that
   each and every parameter combination that appears in the TLSA RRset
   is, on its own, sufficient to match the server's current certificate
   chain.  In particular, when deploying new keys or new parameter
   combinations, some care is required to not generate parameter
   combinations that only match past or future certificate chains (or
   raw public keys).  The rest of this section explains how to update
   the TLSA RRset in a manner that ensures that the above requirement
   is met.

8.1.  Key Rollover with Fixed TLSA Parameters

   The simplest case is key rollover while retaining the same set of
   published parameter combinations.  In this case, TLSA records
   matching the existing server certificate chain (or raw public keys)
   are first augmented with corresponding records matching the future
   keys, at least two Times to Live (TTLs) or longer before the new
   chain is deployed.  This allows the obsolete RRset to age out of
   client caches before the new chain is used in TLS handshakes.  Once
   sufficient time has elapsed and all clients performing DNS lookups
   are retrieving the updated TLSA records, the server administrator may
   deploy the new certificate chain, verify that it works, and then
   remove any obsolete records matching the chain that is no longer

   ; Initial TLSA RRset.
   ; IN TLSA 3 1 1 01d09d19c2139a46...

   ; Transitional TLSA RRset published at least two TTLs before
   ; the actual key change.
   ; IN TLSA 3 1 1 01d09d19c2139a46... IN TLSA 3 1 1 7aa7a5359173d05b...

   ; Final TLSA RRset after the key change.
   ; IN TLSA 3 1 1 7aa7a5359173d05b...
Top   ToC   Page 21
   The next case to consider is adding or switching to a new combination
   of TLSA parameters.  In this case, publish the new parameter
   combinations for the server's existing certificate chain first, and
   only then deploy new keys if desired:

   ; Initial TLSA RRset.
   ; IN TLSA 1 1 1 01d09d19c2139a46...

   ; New TLSA RRset, same key re-published as DANE-EE(3).
   ; IN TLSA 3 1 1 01d09d19c2139a46...

8.2.  Switching to DANE-TA(2) from DANE-EE(3)

   This section explains how to migrate to a new certificate chain and
   TLSA record with usage DANE-TA(2) from a self-signed server
   certificate and a "DANE-EE(3) SPKI(1) SHA2-256(1)" TLSA record.  This
   example assumes that a new private key is generated in conjunction
   with transitioning to a new certificate issued by the desired TA.

   The original "3 1 1" TLSA record supports [RFC7250] raw public keys,
   and clients may choose to negotiate their use.  The use of raw public
   keys rules out the possibility of certificate chain verification.
   Therefore, the transitional TLSA record for the planned DANE-TA(2)
   certificate chain is a "3 1 1" record that works even when raw public
   keys are used.  The TLSA RRset is updated to use DANE-TA(2) only
   after the new chain is deployed and the "3 1 1" record matching the
   original key is dropped.

   This process follows the requirement that each combination of
   parameters present in the RRset is always sufficient to validate the
   server.  It avoids publishing a transitional TLSA RRset in which
   "3 1 1" matches only the current key and "2 0 1" matches only the
   future certificate chain, because these might not work reliably
   during the initial deployment of the new keys.
Top   ToC   Page 22
   ; Initial TLSA RRset.
   ; IN TLSA 3 1 1 01d09d19c2139a46...

   ; Transitional TLSA RRset, published at least two TTLs before the
   ; actual key change.  The new keys are issued by a DANE-TA(2) CA
   ; but are initially specified via a DANE-EE(3) association.
   ; IN TLSA 3 1 1 01d09d19c2139a46... IN TLSA 3 1 1 7aa7a5359173d05b...

   ; The final TLSA RRset after the key change.  Now that the old
   ; self-signed EE key is out of the picture, publish the issuing
   ; TA of the new chain.
   ; IN TLSA 2 0 1 c57bce38455d9e3d...

8.3.  Switching to New TLSA Parameters

   When employing a new digest algorithm in the TLSA RRset, for
   compatibility with digest algorithm agility as specified in Section 9
   below, administrators SHOULD publish the new digest algorithm with
   each combination of certificate usage and selector for each
   associated key or chain used with any other digest algorithm.  When
   removing an algorithm, remove it entirely.  Each digest algorithm
   employed SHOULD match the same set of chains (or raw public keys).

   ; Initial TLSA RRset with "DANE-EE(3) SHA2-256(1)" associations
   ; for two keys.
   ; IN TLSA 3 1 1 01d09d19c2139a46... IN TLSA 3 1 1 7aa7a5359173d05b...

   ; New TLSA RRset, also with SHA2-512(2) associations
   ; for each key.
   ; IN TLSA 3 1 1 01d09d19c2139a46... IN TLSA 3 1 2 d9947c35089310bc... IN TLSA 3 1 1 7aa7a5359173d05b... IN TLSA 3 1 2 89a7486a4b6ae714...
Top   ToC   Page 23
8.4.  TLSA Publisher Requirements: Summary

   In summary, server operators updating TLSA records should make one
   change at a time.  The individual safe changes are as follows:

   o  Pre-publish new certificate associations that employ the same TLSA
      parameters (usage, selector, and matching type) as existing TLSA
      records, but match certificate chains that will be deployed in the
      near future.

   o  Wait for stale TLSA RRsets to expire from DNS caches before
      configuring servers to use the new certificate chain.

   o  Remove TLSA records matching any certificate chains that are no
      longer deployed.

   o  Publish TLSA RRsets in which all parameter combinations
      (certificate usage, selector, and matching type) present in the
      RRset match the same set of current and planned certificate

   The above steps are intended to ensure that at all times, and for
   each combination of usage, selector, and matching type, at least one
   TLSA record corresponds to the server's current certificate chain.
   Each combination of certificate usage, selector, and matching type in
   a server's TLSA RRset SHOULD NOT at any time (including unexpired
   RRsets in client caches) match only some combination of future or
   past certificate chains.  As a result, no matter what combinations of
   usage, selector, and matching type may be supported by a given
   client, they will be sufficient to authenticate the server.

9.  Digest Algorithm Agility

   While [RFC6698] specifies multiple digest algorithms, it does not
   specify a protocol by which the client and TLSA record publisher can
   agree on the strongest shared algorithm.  Such a protocol would allow
   the client and server to avoid exposure to deprecated weaker
   algorithms that are published for compatibility with less capable
   clients but that SHOULD be avoided when possible.  Such a protocol is
   specified below.

   This section defines a protocol for avoiding deprecated digest
   algorithms when these are published in a peer's TLSA RRset alongside
   stronger digest algorithms.  Note that this protocol never avoids RRs
   with a DANE matching type of Full(0), as these do not employ a digest
   algorithm that might someday be weakened by cryptanalysis.
Top   ToC   Page 24
   Client implementations SHOULD implement a default order of digest
   algorithms by strength.  This order SHOULD be configurable by the
   administrator or user of the client software.  If possible, a
   configurable mapping from numeric DANE TLSA matching types to
   underlying digest algorithms provided by the cryptographic library
   SHOULD be implemented to allow new matching types to be used with
   software that predates their introduction.  Configurable ordering of
   digest algorithms SHOULD be extensible to any new digest algorithms.

   To make digest algorithm agility possible, all published DANE TLSA
   RRsets MUST conform to the requirements of Section 8.  Clients SHOULD
   use digest algorithm agility when processing the peer's DANE TLSA
   records.  Algorithm agility is to be applied after first discarding
   any unusable or malformed records (unsupported digest algorithm, or
   incorrect digest length).  For each usage and selector, the client
   SHOULD process only any usable records with a matching type of
   Full(0) and the usable records whose digest algorithm is considered
   by the client to be the strongest among usable records with the given
   usage and selector.

   Example: a client implements digest algorithm agility and prefers
   SHA2-512(2) over SHA2-256(1), while the server publishes an RRset
   that employs both digest algorithms as well as a Full(0) record. IN TLSA 3 1 1 (
                                 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) IN TLSA 3 1 2 (
                                 57FAB78EAA835362F3CA07CCC19A3214 ) IN TLSA 3 1 0 (
                                 C0FCF06D424C885D484887 )

   In this case, the client SHOULD accept a server public key that
   matches either the "3 1 0" record or the "3 1 2" record, but it
   SHOULD NOT accept keys that match only the weaker "3 1 1" record.
Top   ToC   Page 25
10.  General DANE Guidelines

   These guidelines provide guidance for using or designing protocols
   for DANE.

10.1.  DANE DNS Record Size Guidelines

   Selecting a combination of TLSA parameters to use requires careful
   thought.  One important consideration to take into account is the
   size of the resulting TLSA record after its parameters are selected.

10.1.1.  UDP and TCP Considerations

   Deployments SHOULD avoid TLSA record sizes that cause UDP

   Although DNS over TCP would provide the ability to more easily
   transfer larger DNS records between clients and servers, it is not
   universally deployed and is still prohibited by some firewalls.
   Clients that request DNS records via UDP typically only use TCP upon
   receipt of a truncated response in the DNS response message sent over
   UDP.  Setting the Truncation (TC) bit (Section 4.1.1 of [RFC1035])
   alone will be insufficient if the response containing the TC bit is
   itself fragmented.

10.1.2.  Packet Size Considerations for TLSA Parameters

   Server operators SHOULD NOT publish TLSA records using both a TLSA
   selector of Cert(0) and a TLSA matching type of Full(0), as even a
   single certificate is generally too large to be reliably delivered
   via DNS over UDP.  Furthermore, two TLSA records containing full
   certificates will need to be published simultaneously during a
   certificate rollover, as discussed in Section 8.1.

   While TLSA records using a TLSA selector of SPKI(1) and a TLSA
   matching type of Full(0) (which publish the bare public keys, i.e.,
   without the overhead of encapsulating the keys in an X.509
   certificate) are generally more compact, these are also best avoided
   when significantly larger than their digests.  Rather, servers SHOULD
   publish digest-based TLSA matching types in their TLSA records, in
   which case the complete corresponding certificate MUST be transmitted
   to the client in-band during the TLS handshake.  The certificate (or
   raw public key) can be easily verified using the digest value.

   In summary, the use of a TLSA matching type of Full(0) is
   NOT RECOMMENDED, and a digest-based matching type, such as
   SHA2-256(1), SHOULD be used instead.
Top   ToC   Page 26
10.2.  Certificate Name Check Conventions

   Certificates presented by a TLS server will generally contain a
   subjectAltName (SAN) extension or a Common Name (CN) element within
   the subject Distinguished Name (DN).  The TLS server's DNS domain
   name is normally published within these elements, ideally within the
   SAN extension.  (The use of the CN field for this purpose is

   When a server hosts multiple domains at the same transport endpoint,
   the server's ability to respond with the right certificate chain is
   predicated on correct SNI information from the client.  DANE clients
   MUST send the SNI extension with a HostName value of the base domain
   of the TLSA RRset.

   With the exception of TLSA certificate usage DANE-EE(3), where name
   checks are not applicable (see Section 5.1), DANE clients MUST verify
   that the client has reached the correct server by checking that the
   server name is listed in the server certificate's SAN or CN (when
   still supported).  The primary server name used for this comparison
   MUST be the TLSA base domain; however, additional acceptable names
   may be specified by protocol-specific DANE standards.  For example,
   with SMTP, both the destination domain name and the MX hostname are
   acceptable names to be found in the server certificate (see

   It is the responsibility of the service operator, in coordination
   with the TLSA Publisher, to ensure that at least one of the TLSA
   records published for the service will match the server's certificate
   chain (either the default chain or the certificate that was selected
   based on the SNI information provided by the client).

   Given the DNSSEC-validated DNS records below:               IN MX 0          IN A IN TLSA 2 0 1 (
                                 CF556ECCF9F5303EBFBB77D022F834C0 )

   The TLSA base domain is "" and is required to be the
   HostName in the client's SNI extension.  The server certificate chain
   is required to be signed by a TA with the above certificate SHA2-256
   digest.  Finally, one of the DNS names in the server certificate is
   required to be either "" or "" (this
   additional name is a concession to compatibility with prior practice;
   see [RFC7672] for details).
Top   ToC   Page 27
   [RFC6125] specifies the semantics of wildcards in server certificates
   for various application protocols.  DANE does not change how
   wildcards are treated by any given application.

10.3.  Design Considerations for Protocols Using DANE

   When a TLS client goes to the trouble of authenticating a certificate
   chain presented by a TLS server, it will typically not continue to
   use that server in the event of authentication failure, or else
   authentication serves no purpose.  Some clients may, at times,
   operate in an "audit" mode, where authentication failure is reported
   to the user or in logs as a potential problem, but the connection
   proceeds despite the failure.  Nevertheless, servers publishing TLSA
   records MUST be configured to allow correctly configured clients to
   successfully authenticate their TLS certificate chains.

   A service with DNSSEC-validated TLSA records implicitly promises TLS
   support.  When all the TLSA records for a service are found
   "unusable" due to unsupported parameter combinations or malformed
   certificate association data, DANE clients cannot authenticate the
   service certificate chain.  When authenticated TLS is mandatory, the
   client MUST NOT connect to the associated server.

   If, on the other hand, the use of TLS and DANE is "opportunistic"
   [RFC7435], then when all TLSA records are unusable, the client SHOULD
   connect to the server via an unauthenticated TLS connection, and if
   TLS encryption cannot be established, the client MUST NOT connect to
   the server.

   Standards for opportunistic DANE TLS specific to a particular
   application protocol may modify the above requirements.  The key
   consideration is whether or not mandating the use of
   (unauthenticated) TLS even with unusable TLSA records is asking for
   more security than one can realistically expect.  If expecting TLS
   support when unusable TLSA records are published is realistic for the
   application in question, then the application MUST avoid cleartext.
   If not realistic, then mandating TLS would cause clients (even in the
   absence of active attacks) to run into problems with various peers
   that do not interoperate "securely enough".  That would create strong
   incentives to just disable Opportunistic Security and stick with
Top   ToC   Page 28
11.  Note on DNSSEC Security

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

   With the existing public CA Web PKI, name constraints are rarely
   used, and a public root CA can issue certificates for any domain of
   its choice.  With DNSSEC, under the Registry/Registrar/Registrant
   model, the situation is different: only the registrar of record can
   update a domain's DS record [RFC4034] in the registry parent zone (in
   some cases, however, the registry is the sole registrar).  With many
   Generic Top-Level Domains (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.  DNS operators are advised to set a registrar lock on their
   domains to offer some protection against this possibility.

   When the registrar is also the DNS operator for the domain, one needs
   to consider whether or not the registrar will allow orderly migration
   of the domain to another registrar or DNS operator in a way that will
   maintain DNSSEC integrity.  TLSA Publishers are advised to seek out a
   DNS hosting registrar that makes it possible to transfer domains to
   another hosting provider without disabling DNSSEC.

   DNSSEC-signed RRsets cannot be securely revoked before they expire.
   Operators need to plan accordingly and not generate signatures of
   excessively long duration.  For domains publishing high-value keys, a
   signature lifetime (length of the "signature validity period" as
   described in Section 8.1 of [RFC4033]) of a few days is reasonable,
   and the zone can be re-signed daily.  For domains with less critical
   data, a reasonable signature lifetime is a couple of weeks to a
   month, and the zone can be re-signed weekly.

   Short signature lifetimes require tighter synchronization of primary
   and secondary nameservers, to make sure that secondary servers never
   serve records with expired signatures.  They also limit the maximum
   time for which a primary server that signs the zone can be down.
   Therefore, short signature lifetimes are more appropriate for sites
   with dedicated operations staff, who can restore service quickly in
   case of a problem.

   Monitoring is important.  If a DNS zone is not re-signed in a timely
   manner, a major outage is likely, as the entire domain and all its
   sub-domains become "bogus".
Top   ToC   Page 29
12.  Summary of Updates to RFC 6698

   o  Section 3 updates [RFC6698] to specify a requirement for clients
      to support at least TLS 1.0 and to support SNI.

   o  Section 4 explains that application support for all four
      certificate usages is NOT RECOMMENDED.  The recommended design is
      to support just DANE-EE(3) and DANE-TA(2).

   o  Section 5.1 updates [RFC6698] to specify that peer identity
      matching and validity period enforcement are based solely on the
      TLSA RRset properties.  It also specifies DANE authentication of
      raw public keys [RFC7250] via TLSA records with certificate usage
      DANE-EE(3) and selector SPKI(1).

   o  Section 5.2 updates [RFC6698] to require that servers publishing
      digest TLSA records with a usage of DANE-TA(2) MUST include the
      TA certificate in their TLS server certificate message.  This
      extends to the case of "2 1 0" TLSA records that publish a full
      public key.

   o  Section 5.4 observes that with usage PKIX-TA(0), clients may need
      to process extended trust chains beyond the first trusted issuer
      when that issuer is not self-signed.

   o  Section 7 recommends that DANE application protocols specify that,
      when possible, securely CNAME-expanded names be used to derive the
      TLSA base domain.

   o  Section 8 specifies a strategy for managing TLSA records that
      interoperates with DANE clients regardless of what subset of the
      possible TLSA record types (combinations of TLSA parameters) is
      supported by the client.

   o  Section 9 specifies a digest algorithm agility protocol.

   o  Section 10.1 recommends against the use of Full(0) TLSA records,
      as digest records are generally much more compact.

13.  Operational Considerations

   The DNS TTL of TLSA records needs to be chosen with care.  When an
   unplanned change in the server's certificate chain and TLSA RRset is
   required, such as when keys are compromised or lost, clients that
   cache stale TLSA records will fail to validate the certificate chain
   of the updated server.  Publish TLSA RRsets with TTLs that are short
   enough to limit unplanned service disruption to an acceptable
Top   ToC   Page 30
   The signature lifetime (length of the signature validity period) for
   TLSA records SHOULD NOT be too long.  Signed DNSSEC records can be
   replayed by an MITM attacker, provided the signatures have not yet
   expired.  Shorter signature validity periods allow for faster
   invalidation of compromised keys.  Zone refresh and expiration times
   for secondary nameservers often imply a lower bound on the signature
   validity period (Section 11).  See Section 4.4.1 of [RFC6781].

14.  Security Considerations

   Application protocols that cannot use the existing public CA Web PKI
   may choose to not implement certain TLSA record types defined in
   [RFC6698].  If such records are published despite not being supported
   by the application protocol, they are treated as "unusable".  When
   TLS is opportunistic, the client MAY proceed to use the server with
   mandatory unauthenticated TLS.  This is stronger than opportunistic
   TLS without DANE, since in that case the client may also proceed with
   a cleartext connection.  When TLS is not opportunistic, the client
   MUST NOT connect to the server.

   Thus, when TLSA records are used with opportunistic protocols where
   PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol
   design is for servers to not publish such TLSA records, and for
   opportunistic TLS clients to use them to only enforce the use of
   (albeit unauthenticated) TLS but otherwise treat them as unusable.
   Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the
   application protocol, clients MUST implement these certificate usages
   as described in [RFC6698] and this document.

15.  References

15.1.  Normative References

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

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

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
Top   ToC   Page 31
   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, 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, DOI 10.17487/RFC5280, May 2008,

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,

   [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, DOI 10.17487/RFC6125,
              March 2011, <>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <>.

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

   [RFC7218]  Gudmundsson, O., "Adding Acronyms to Simplify
              Conversations about DNS-Based Authentication of Named
              Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218,
              April 2014, <>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <>.
Top   ToC   Page 32
15.2.  Informative References

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

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
              December 2014, <>.

   [RFC7672]  Dukhovni, V. and W. Hardaker, "SMTP Security via
              Opportunistic DNS-Based Authentication of Named Entities
              (DANE) Transport Layer Security (TLS)", RFC 7672,
              DOI 10.17487/RFC7672, October 2015,

   [RFC7673]  Finch, T., Miller, M., and P. Saint-Andre, "Using
              DNS-Based Authentication of Named Entities (DANE) TLSA
              Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673,
              October 2015, <>.
Top   ToC   Page 33

   The authors would like to thank Phil Pennock for his comments and
   advice on this document.

   Acknowledgements from Viktor: 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 document and
   provided feedback on early draft versions of it.  Thanks also to
   Samuel Dukhovni for editorial assistance.

Authors' Addresses

   Viktor Dukhovni
   Two Sigma


   Wes Hardaker
   P.O. Box 382
   Davis, CA  95617
   United States