| DANE | V. Dukhovni |
| Internet-Draft | Unaffiliated |
| Intended status: Best Current Practice | W.H. Hardaker |
| Expires: July 19, 2014 | Parsons |
| January 15, 2014 |
DANE TLSA implementation and operational guidance
draft-ietf-dane-ops-02
This memo provides guidance to server operators to help ensure that clients will be able to authenticate a server's certificate chain via published TLSA records. Guidance is also provided to clients for selecting reliable TLSA record parameters and using them for server authentication. Finally, guidance is given to protocol designers who wish to make use of TLSA records when securing protocols using a combination of TLS and TLSA.
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 July 19, 2014.
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.
Section 2 of [RFC6698] specifies a new "TLSA" DNS resource record which associates with a TLS transport endpoint the corresponding trusted leaf or issuing authority certificates or public keys. DNSSEC-validated DANE TLSA records can be used to augment or replace the trust model of the existing public CA PKI.
[RFC6698] defines 24 combinations of TLSA record parameters. Additional complexity arises when the TLS transport endpoint is obtained indirectly via SRV, MX and CNAME records or other mechanisms that map an abstract service domain to a concrete server domain. With service indirection there are multiple potential places for clients to find the relevant TLSA records. Service indirection is often used to implement "virtual hosting", where a single Service Provider transport endpoint simultaneously supports multiple hosted domains. With services that employ TLS, such hosting arrangements may require the Service Provider to employ multiple pairs of private keys and certificates with TLS clients signalling the desired domain via SNI ([RFC6066], section 3). This memo provides operational guidelines intended to maximize interoperability between DANE TLS clients and servers.
In the context of this memo, channel security is assumed to be provided by TLS or DTLS. The Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols provide secured TCP and UDP communication over the Internet Protocol. By convention, "TLS" will be used throughout this document and, unless otherwise specified, the text applies equally well to the DTLS protocol. Used without authentication, TLS provides protection only against eavesdropping. With authentication, TLS also provides protection against man-in-the-middle (MITM) attacks.
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].
The following terms are used throughout this document:
DANE TLSA [RFC6698] specifies a protocol for publishing TLS server certificate associations via DNSSEC. The DANE TLSA specification defines multiple TLSA RR types via combinations of 3 numeric parameters. The numeric values of these parameters were later given symbolic names in [I-D.ietf-dane-registry-acronyms]. These parameters are:
We may think of TLSA Certificate Usage values 0 through 3 as 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:
The selector field specifies whether the TLSA RR matches the whole certificate (Cert(0)) or just its subjectPublicKeyInfo (SPKI(1)). The subjectPublicKeyInfo is an ASN.1 DER encoding of the certificate's algorithm id, any parameters and the public key data.
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 Full(0) means an exact match: the full DER encoding of the certificate or public key is given in the TLSA RR. A value of SHA2-256(1) means that the association data matches the SHA2-256 digest of the certificate or public key, and likewise SHA2-512(2) means a SHA2-512 digest is used. Of the two digest algorithms, for now only SHA2-256(1) is mandatory to implement. Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2) digests. A digest algorithm agility protocol is proposed in section 2.3.3 of [I-D.ietf-dane-smtp-with-dane] that SHOULD be used by clients to decide how to process TLSA RRsets that employ multiple digest algorithms. Server operators MUST publish TLSA RRsets that are compatible with digest algorithm agility.
In the example TLSA record below:
_25._tcp.mail.example.com. IN TLSA 2 0 1 (
E8B54E0B4BAA815B06D3462D65FBC7C0
CF556ECCF9F5303EBFBB77D022F834C0 )
The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and the matching type is SHA2-256(1). The rest of the record is the certificate association data field, which is in this case the SHA2-256 digest of the server certificate.
These guidelines provide guidance for using or designing protocols for DANE, regardless of what sort of TLSA record will be used.
TLS clients that support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support TLS 1.2. TLS clients and servers using DANE SHOULD support the "Server Name Indication" extension of TLS.
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.
Deployments SHOULD avoid TLSA record sizes that cause UDP fragmentation.
Although DNS over TCP would provide the ability to transfer larger DNS records between clients and servers, it is not universally deployed and is still blocked by some firewalls. Clients that request DNS records via UDP typically only use TCP upon receipt of a truncated response in TCP.
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 may need to be published during certificate rollover.
While TLSA records using a TLSA Selector of SPKI(1) and a TLSA Matching Type of Full(0), publishing full public keys without the full X.509 wrapping, are generally more compact, these too should be used with caution as they are still larger than necessary. Rather, servers SHOULD make use of the digest-based TLSA Matching Types within TLSA records. The complete corresponding certificate should, instead, be transmitted to the client in-band during the TLS handshake.
In summary, the use of a TLSA Matching Type of Full(0) is NOT RECOMMENDED and the use of SHA2-256(1) and SHA2-512(2) is strongly preferred.
Certificates presented by a TLS server will generally contain a Common Name (CN) element in the subject distinguished name (DN) and/or a subjectAltName (SAN) extension. The server's DNS hostname should be published within these elements, ideally within the subjectAltName extension as use of the CN field for this purpose is deprecated. Name checks SHOULD NOT consider the subject CN when SAN values of type 'dns' are present.
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.
Except with TLSA Certificate Usage DANE-EE(3), where name checks are not applicable (see Section 4.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. The server name used for this comparison SHOULD be the base domain of the TLSA RRset. Additional acceptable names may be specified by protocol-specific DANE standards. For example, with SMTP both the destination domain name and the MX host name are acceptable names to be found in the server certificate (see [I-D.ietf-dane-smtp-with-dane]).
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 selected based on the SNI information from the client). With certificate usage values other than DANE-EE(3) the server leaf (EE) certificate MUST include the TLSA base domain as one of its names, or else if other acceptable names are specified by a protocol-specific DANE standard, one of those can be used in place of the TLSA base domain.
Given the DNSSEC validated DNS records below:
example.com. IN MX 0 mail.example.com.
_25._tcp.mail.example.com. IN TLSA 2 0 1 (
E8B54E0B4BAA815B06D3462D65FBC7C0
CF556ECCF9F5303EBFBB77D022F834C0 )
the TLSA base domain is "mail.example.com" and this MUST be the HostName in the client's SNI extension. The server certificate chain MUST be signed by a trust anchor with the above certificate SHA2-256 digest. One of the DNS names in the server certificate MUST be either "mail.example.com" or "example.com".
Complications arise when the TLSA Publisher is not the same entity as the Service Provider. In this situation, the TLSA Publisher and the Service Provider must cooperate to ensure that TLSA records published by the TLSA Publisher don't fall out of sync with the server certificate configuration used by the Service Provider.
Whenever possible, the TLSA Publisher and the Service Provider should be the same entity. Otherwise changes in the service certificate chain must be carefully coordinated between the parties involved. Such coordination is difficult and outages will result when the process fails.
Even when the TLSA RRset must be published in the Customer Domain's DNS zone, it is possible to employ CNAME records (see Section 3.5) to delegate the content of the TLSA RRset to a domain operated by the Service Provider. Having the master TLSA record in the Service Provider's zone avoids the complexity of bilateral coordination of server certificate configuration and TLSA record management. Certificate name checks generally constrain the applicability of TLSA CNAMEs across organizational boundaries to Certificate Usages DANE-EE(3) and DANE-TA(2):
Below are example DNS records that illustrate both of of the above cases in the case of an HTTPS service whose clients all support DANE TLS.
; Hosted web service redirected via a CNAME alias.
; Associated TLSA RRset redirected via a CNAME alias.
;
; Single certificate at provider works for all Customer Domains
;
www1.example.com. IN CNAME www311.example.net.
_443._tcp.www3.example.com. IN CNAME _443._tcp.www311.example.net.
_443._tcp.www311.example.net. IN TLSA 3 1 1 (
8A9A70596E869BED72C69D97A8895DFA
D86F300A343FECEFF19E89C27C896BC9 )
;
; CA at provider can issue certificates for each Customer Domain.
;
www2.example.com. IN CNAME www201.example.net.
_443._tcp.www2.example.com. IN CNAME _443._tcp.www201.example.net.
_443._tcp.www201.example.net. IN TLSA 2 0 1 (
C164B2C3F36D068D42A6138E446152F5
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 end-point, rather than the origin domain. With SMTP for example, when 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 domains for TLSA records that are published and managed by the Service Provider. For example:
; Hosted SMTP service
;
example.com. IN MX 0 mx1.example.net.
example.com. IN MX 0 mx2.example.net.
_25._tcp.mx1.example.net. IN TLSA 3 1 1 (
8A9A70596E869BED72C69D97A8895DFA
D86F300A343FECEFF19E89C27C896BC9 )
_25._tcp.mx2.example.net. IN TLSA 3 1 1 (
C164B2C3F36D068D42A6138E446152F5
68615F28C69BD96A73E354CAC88ED00C )
If redirection to the Service Provider's domain (via MX or 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 is 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 must wait for matching TLSA records to be published by its Customer Domains before deploying newly generated keys and certificate chains.
When the 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, since unlike an MX or SRV record, it remaps the origin domain to the target domain for all protocols.
The complexity of coordinating key rollover is largely eliminated when DANE TLSA records are found in the Service Provider's domain, as discussed in Section 3.4. 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 the CNAME is DNSSEC-validated), and use the final target host as the base domain for TLSA lookups.
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 query name.
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. They SHOULD use the target hostname as the preferred TLSA base domain as well as the HostName in SNI, provided the CNAME RR is found to be "secure" at each step in the CNAME expansion.
[RFC6962] Certificate Transparency, or CT for short, defines an approach to mitigate the risk of rogue or compromised public CAs issuing unauthorized certificates. This section clarifies the interaction of CT and DANE. CT is a protocol and auditing system that applies only to public CAs, and only when they are free to issue unauthorized certificates for a domain. If the CA is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the end entity certificate, there is no role for CT, and clients need not apply CT checks.
When a server is authenticated via a DANE TLSA RR with TLSA Certificate Usage DANE-EE(3), the domain owner has directly specified the certificate associated with the given service without reference to any PKIX certificate authority. Therefore, when a TLS client authenticates the TLS server via a TLSA certificate association with usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of the server certificate or public key (digest) in a TLSA record in a DNSSEC signed zone by the domain owner assures the TLS client that the certificate is not an unauthorized certificate issued by a rogue CA without the domain owner's consent.
When a server is authenticated via a DANE TLSA RR with TLSA usage DANE-TA(2) and the server certificate does not chain to a known public root CA, CT cannot apply (CT logs only accept chains that start with a known, public root). Since TLSA Certificate Usage DANE-TA(2) is generally intended to support non-PKIX trust anchors, TLS clients SHOULD NOT perform CT checks with usage DANE-TA(2) using unknown root CAs.
A server operator who wants clients to perform CT checks should publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1).
When a TLS client goes to the trouble of authenticating a certificate chain presented by a TLS server, it should not continue to use that server in the event of authentication failure, or else authentication serves no purpose. 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 associated data, DANE clients cannot authenticate the service certificate chain. When authenticated TLS is dictated by the application, the client SHOULD NOT connect to the associated server. If, on the other hand, the use of TLS is "opportunistic", then the client SHOULD generally use the server via an unauthenticated TLS connection, but if TLS encryption cannot be established, the client MUST NOT use the server. Standards for DANE specific to the particular application protocol may modify the above as appropriate to specify whether the connection should be established anyway without relying on TLS security, with only TLS encryption but not authentication, or whether to refuse to connect entirely. Protocols must choose whether to prioritize security or robustness.
For some application protocols (such as SMTP to MX with opportunistic TLS), the existing public CA PKI is not a viable alternative to DANE. For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280] PKIX validation or [RFC6125] identity verification.
Protocols designed for non-PKIX use SHOULD choose to treat any TLSA records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as unusable. After verifying that the only available TLSA Certificate Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY instruct clients to either refuse to initiate a connection or to connect via unauthenticated TLS if no alternative authentication mechanisms are available.
With TLSA records that match the EE certificate, the TLS client has no difficulty matching TLSA records against the server certificate, as this certificate is always present in the TLS server certificate chain.
With DANE TLSA records that match the digest of a 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 [RFC5246]:
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 that
specifies the root certificate authority MAY 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 entirely 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. With Certificate Usage PKIX-TA(0), this is not a problem, since the client is expected to be pre-configured with the issuing TA certificate.
With TLSA Certificate Usage DANE-TA(2), there is no expectation that the client is pre-configured with the trust anchor certificate. Rather, with TLSA Certificate Usage DANE-TA(2) clients must be able to rely on the TLSA records alone. But, with a digest in the TLSA record, the TLSA record contains neither the full trust anchor certificate nor the full public key. If the TLS server's certificate chain does not contain the trust anchor certificate, DANE clients will be unable to authenticate the server.
TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) with a digest (not Full(0)) matching type MUST ensure that the corresponding server is configured to also include the 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.
TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) and a matching type of Full(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:
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 TLSA Certificate Usage DANE-TA(2), the client may not have the associated 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" 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 using existing TLS libraries, servers SHOULD include the trust anchor certificate in their certificate chains when the TLSA Certificate Usage is DANE-TA(2).
If none of the server's certificate chain elements match a public key specified in full in a TLSA record, clients SHOULD check whether the topmost certificate in the chain is signed by the provided public key and has not expired, and if that is the case, and the rest of the chain passes validation, consider the server authenticated if name checks are also successful.
Authentication via certificate usage "3" TLSA records involves simply checking that the server's leaf certificate matches the TLSA record. Other than extracting the relevant certificate elements for comparison, no other use is made of the certificate content. Authentication via certificate usage "3" TLSA records involves no certificate authority signature checks. It also involves no server name checks, and thus does not impose any new requirements on the names contained in the server certificate (servers don't depend on SNI when the TLSA record matches the server's default certificate).
Two TLSA records will need to be published before updating a server's public key, one matching the currently deployed key and the other matching the new key scheduled to replace it. Once sufficient time has elapsed for all DNS caches to expire the previous TLSA RRset, which contains only the old key, the server may be reconfigured to use the new private key and associated certificate chain. Once the server is using the new key, the TLSA RR that matches the retired key can be removed from DNS, leaving only the RR that matches the new key.
TLSA records for servers SHOULD, when possible, be DANE-EE(3), SPKI(1), SHA2-256(1) records. Such "3 1 1" records specify the SHA2-256 digest of the public key of the server certificate. Since all DANE implementations are required to support SHA2-256, this record works for all clients and need not change across certificate renewals with the same key. With no name checks required, this TLSA record type supports hosting arrangements with a single certificate matching all client domains! It is also the easiest to implement correctly in the client.
Some domains may prefer to reduce the operational complexity of maintaining a distinct TLSA RRset for each TLS service. If the domain employs a common issuing certificate authority to create certificates for multiple TLS services, it may be simpler to publish the issuing authority as a trust anchor (TA) for the certificate chains of all relevant services. The TLSA RRs for each service issued by the same TA may then be CNAMEs to a common TLSA RRset that matches the TA. This certificate usage also allows Service Providers to independently generate appropriate certificates for each Customer Domain (see Section 3.4).
As explained in Section 3.8, servers that employ Certificate Usage DANE-TA(2) TLSA records MUST include the TA certificate as part of the certificate chain presented in the TLS handshake even when it is a self-signed root certificate. TLSA Publishers should publish either "2 1 1" or "2 0 1" TLSA parameters, which specify the SHA2-256 digest of the trust anchor public key or certificate respectively. As with leaf certificate rollover discussed in Section 4.1, two such TLSA RRs need to be published to facilitate TA certificate rollover.
From a TLSA record perspective this certificate usage is similar to DANE-EE(3), but in addition PKIX verification is required. Therefore, name checks, certificate expiration, etc., apply as they would without DANE. An attacker who can compromise DNSSEC can replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his choosing and thus bypass the PKIX verification requirements.
Therefore, in most cases this certificate usage offers only illusory incremental security over usage DANE-EE(3). It provides lower reliability than usage 3 since some clients may not be configured with the required root CA, the server's chain may be incomplete or name checks may fail. It requires more complex coordination between the Customer Domain and the Service Provider in hosting arrangements. This certificate usage is not recommended.
TLSA Certificate Usage PKIX-TA(0) allows a domain to publish constraints on the set of certificate authorities trusted to issue certificates for its TLS servers. Clients must only accept PKIX-verified trust chains which contain a match for one of the published TLSA records.
TLSA Publishers may publish TLSA records for a particular public root CA, expecting that clients will then only accept chains anchored at that root. It is possible, however, that the client's trusted certificate store includes some intermediate CAs, either with or without the corresponding root CA. When a client constructs a trust chain leading from a trusted intermediate CA to the server leaf certificate, such a "truncated" chain might not contain a trusted root published in the server's TLSA records.
If the omitted root is also trusted, the client may erroneously reject the server chain if it fails to determine that the shorter chain it constructed extends to a longer trusted chain that matches the TLSA records. This means that, when matching a usage 0 TLSA record, a client SHOULD NOT always stop extending the chain when the first locally trusted certificate is found. If no TLSA records have matched any of the elements of the chain, it MUST attempt to build a longer chain if the trusted certificate found is not self-issued, in the hope that a certificate closer to the root may in fact match the server's TLSA records.
An attacker who can compromise DNSSEC can replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his choosing and thus bypass the PKIX verification requirements. Therefore, in most cases this certificate usage offers only illusory incremental security over usage DANE-TA(2). It provides lower reliability than usage 2 since some clients may not be configured with the required root CA, and requires more complex coordination between the Customer Domain and the Service Provider in hosting arrangements. This certificate usage is not recommended.
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 a 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, however, 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. DNS Operators SHOULD use a registrar lock of 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 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 SHOULD ensure their registrar publishes a suitable domain transfer policy.
DNSSEC signed RRsets cannot be securely revoked before they expire. Operators should plan accordingly and not generate signatures with excessively long duration. For domains publishing high-value keys, a signature lifetime of a few days is reasonable, and the zone should be resigned every day. For domains with less critical data, a reasonable signature lifetime is a couple of weeks to a month, and the zone should be resigned every week. 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.
The authors would like to thank Phil Pennock for his comments and advice on this document.
Acknowledgments 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 memo and provided feedback on early drafts. Thanks also to Samuel Dukhovni for editorial assistance.
Application protocols that cannot make use of the existing public CA PKI (so called non-PKIX protocols), may choose not to implement certain PKIX-dependent 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 plaintext connection. When TLS is not opportunistic, the client MUST NOT connect to the server.
Therefore, when TLSA records are used with protocols where PKIX does not apply, the recommended policy is for servers to not publish PKIX-dependent TLSA records, and for opportunistic TLS clients to use them to enforce the use of (albeit unauthenticated) TLS, but otherwise treat them as unusable. Of course, when PKIX validation is supported by the application protocol, clients SHOULD perform PKIX validation per [RFC6698].
| [I-D.ietf-dane-registry-acronyms] | Gudmundsson, O., "Adding acronyms to simplify DANE conversations", Internet-Draft draft-ietf-dane-registry-acronyms-03, January 2014. |
| [I-D.ietf-dane-smtp-with-dane] | Dukhovni, V. and W. Hardaker, "SMTP security via opportunistic DANE TLS", Internet-Draft draft-ietf-dane-smtp-with-dane-04, November 2013. |
| [I-D.ietf-dane-srv] | Finch, T., "Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records.", Internet-Draft draft-ietf-dane-srv-02, February 2013. |