| DANE | V. Dukhovni |
| Internet-Draft | Unaffiliated |
| Intended status: Standards Track | W. Hardaker |
| Expires: November 28, 2015 | Parsons |
| May 27, 2015 |
Updates to and Operational Guidance for the DANE Protocol
draft-ietf-dane-ops-09
This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records.
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 28, 2015.
Copyright (c) 2015 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.
The DANE TLSA specification ([RFC6698]) introduces the DNS "TLSA" resource record type. TLSA records associate a certificate or a public key of an end-entity or a trusted issuing authority with the corresponding TLS transport endpoint. DNSSEC validated DANE TLSA records can be used to augment or replace the use of trusted public Certification Authorities (CAs).
[RFC6698] defines three TLSA record fields with respectively 4, 2 and 3 currently specified values. These yield 24 distinct combinations of TLSA record types. This document recommends a smaller set of best-practice combinations of these fields to simplify protocol design, implementation and deployment.
Implementation complexity also arises from the fact that the TLS transport endpoint is often specified indirectly via Service Records (SRV), Mail Exchange (MX) records, 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 domain names. With services that employ TLS, such hosting arrangements may require the Service Provider to deploy multiple pairs of private keys and certificates. The TLS clients, then, signal the desired domain to the TLSA server via the Server Name Indication (SNI) extension ([RFC6066], section 3). This document provides operational guidelines intended to maximize interoperability between DANE TLS clients and servers.
In the context of this document, channel security is assumed to be provided by TLS or DTLS. The Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] protocols provide secured TCP and UDP communication, respectively, over IP. By convention, "TLS" will be used throughout this document and, unless otherwise specified, the text applies equally well to the DTLS over UDP protocol. Used without authentication, TLS provides protection only against eavesdropping through its use of encryption. With authentication, TLS also provides integrity protection and authentication, which protects the transport against man-in-the-middle (MITM) attacks.
Other related documents that build on [RFC6698] are [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane].
In Section 12 we summarize the normative updates this document makes to [RFC6698].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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 [RFC4033] [RFC4034] [RFC4035]. The DANE TLSA specification defines multiple TLSA RR types via combinations of numeric values of the first three fields of the TLSA record (i.e. the "TLSA parameters"). The numeric values of these parameters were later given symbolic names in [RFC7218]. 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 PKIX (public PKI issued) and DANE (domain-issued) trust anchors:
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. The digest algorithm agility protocol defined in Section 9 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 last field is the Certificate Association Data Field, which in this case contains the SHA2-256 digest of the server certificate.
[RFC6698] does not discuss what versions of TLS are required when using DANE records. This document specifies that 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" (SNI) extension of TLS.
As mentioned in Section 2, the TLSA certificate usage field takes one of four possible values. With PKIX-TA(0) and PKIX-EE(1), the validation of peer certificate chains requires additional pre-configured CA trust anchors that are mutually trusted by the operators of the TLS server and client. With DANE-TA(2) and DANE-EE(3), no pre-configured CA trust anchors are required and the published DANE TLSA records are sufficient to verify the peer's certificate chain.
Protocol designers should carefully consider which set of DANE certificate usages to support. Simultaneous support for all four usages is NOT RECOMMENDED for DANE clients. Protocol designers should either use the PKIX-TA(0) and PKIX-EE(1) certificate usages, or use the DANE-TA(2) and DANE-EE(3) usages. If all four usages are deployed together, an attacker capable of compromising the integrity of DNSSEC needs only to replace server's TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2) records, effectively bypassing the PKIX required checks. In other words, when all four usages are supported, PKIX-TA(2) and PKIX-EE(1) offer only illusory incremental security.
This document recommends that clients should generally support just the DANE-TA(2) and DANE-EE(3) certificate usages. With DANE-TA(2) and DANE-EE(3) clients don't need to track a large changing list of X.509 trust-anchors. Supporting PKIX-TA(0) or PKIX-EE(1) decreases the operational reliability of DANE-based authentication.
The DNSSEC TLSA records for servers MAY include both sets of usages if the server needs to support a mixture of clients; some supporting one pair of usages and some the other.
When the client's protocol design is based on Opportunistic Security (OS, [RFC7435]), and the use of authentication is based on the presence of server TLSA records, it is especially important to avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages. Since the presence and data integrity of TLSA records relies on DNSSEC, PKIX-TA(0) and PKIX-EE(1) TLSA records do not provide additional security. With the PKIX-TA(0) and PKIX-EE(1) usages offering no more security, but being more prone to failure, they are a poor fit for opportunistic security and SHOULD NOT be used in that context.
Certificate Transparency (CT) [RFC6962] 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.
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 public certification authority. Therefore, when a TLS client authenticates the TLS server via a TLSA record 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 record 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-public trust anchors, TLS clients SHOULD NOT perform CT checks with usage DANE-TA(2).
The choice of preferred certificate usages may need to change as a protocol evolves. When transitioning between PKIX-TA/PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the new certificate usage values. If the new preferred certificate usages are PKIX-TA/EE this requires installing and managing the appropriate set of CA trust anchors. During this time servers will publish both types of TLSA records. At some later time when the vast majority of servers have published the new preferred TLSA records, clients can stop supporting the legacy certificate usages. Similarly, servers can stop publishing legacy TLSA records once the vast majority of clients support the new certificate usages.
The four Certificate Usage values from the TLSA record, DANE-EE(3), DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below.
In this section the meaning of DANE-EE(3) is updated from [RFC6698] to specify that peer identity matching and that validity period enforcement is based solely on the TLSA RRset properties. We also extend [RFC6698] to cover the use of DANE authentication of raw public keys [RFC7250] via TLSA records with Certificate Usage DANE-EE(3) and selector SPKI(1).
Authentication via certificate usage DANE-EE(3) TLSA records involves simply checking that the server's leaf certificate matches the TLSA record. In particular, the binding of the server public key to its name is based entirely on the TLSA record association. The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server.
Similarly, with DANE-EE(3), the expiration date of the server certificate MUST be ignored. The validity period of the TLSA record key binding is determined by the validity period of the TLSA record DNSSEC signatures.
With DANE-EE(3) servers that know all the connecting clients are making use of DANE, they need not employ SNI (i.e., the may ignore the client's SNI message) even when the server is known under multiple domain names that would otherwise require separate certificates. It is instead sufficient for the TLSA RRsets for all the domain names in question to match the server's primary certificate. For application protocols where the server name is obtained indirectly via SRV, MX or similar records, it is simplest to publish a single hostname as the target server name for all the hosted domains.
In organizations where it is practical to make coordinated changes in DNS TLSA records before server key rotation, it is generally best to publish end-entity DANE-EE(3) certificate associations in preference to other choices of certificate usage. DANE-EE(3) TLSA records support multiple server names without SNI, don't suddenly stop working when leaf or intermediate certificates expire, and don't fail when a server operator neglects to include all the required issuer certificates in the server certificate chain.
TLSA records published for DANE servers SHOULD, as a best practice, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE implementations are required to support SHA2-256, this record type works for all clients and need not change across certificate renewals with the same key. This TLSA record type easily supports hosting arrangements with a single certificate matching all hosted domains. It is also the easiest to implement correctly in the client.
Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching type) TLSA records is that they are compatible with the raw public key TLS extension specified in [RFC7250]. DANE clients that support this extension can use the TLSA record to authenticate servers that negotiate the use of raw public keys in place of X.509 certificate chains. Provided the server adheres to the requirements of Section 8, the fact that raw public keys are not compatible with any other TLSA record types will not get in the way of successful authentication. Clients that employ DANE to authenticate the peer server SHOULD NOT negotiate the use of raw public keys unless the server's TLSA RRset includes compatible TLSA records.
While it is, in principle, also possible to authenticate raw public keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the public key from the certificate in DNS, this is in conflict with the indicated selector and requires extra logic on clients that not all implementations are expected to provide. Servers SHOULD NOT rely on "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication data for raw public keys.
This section updates [RFC6698] by specifying a new operational requirement for servers publishing TLSA records with a usage of DANE-TA(2): such servers MUST include the trust-anchor certificate in their TLS server certificate message.
Some domains may prefer to avoid the operational complexity of publishing unique TLSA RRs for each TLS service. If the domain employs a common issuing Certification 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 query domain (TLSA base domain with port and protocol prefix labels) for each service issued by the same TA may then be set to a CNAME alias that points to a common TLSA RRset that matches the TA. For example:
www1.example.com. IN A 192.0.2.1
www2.example.com. IN A 192.0.2.2
_443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com.
_443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com.
tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
With usage DANE-TA(2) the server certificates will need to have names that match one of the client's reference identifiers (see [RFC6125]). The server SHOULD employ SNI to select the appropriate certificate to present to the client.
TLSA records with matching type Full(0) are NOT RECOMMENDED. While these potentially obviate the need to transmit the TA certificate in the TLS server certificate message, client implementations may not be able to augment the server certificate chain with the data obtained from DNS, especially when the TLSA record supplies a bare key (selector SPKI(1)). Since the server will need to transmit the TA certificate in any case, server operators SHOULD publish TLSA records with a matching type other than Full(0) and avoid potential DNS interoperability issues with large TLSA records containing full certificates or keys (see Section 10.1.1).
TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0). Such TLSA records are associated with the whole trust anchor certificate, not just with the trust anchor public key. In particular, the client SHOULD then apply any relevant constraints from the trust anchor certificate, such as, for example, path length constraints.
While a selector of SPKI(1) may also be employed, the resulting TLSA record will not specify the full trust anchor certificate content, and elements of the trust anchor certificate other than the public key become mutable. This may, for example, enable a subsidiary CA to issue a chain that violates the trust anchor's path length or name constraints.
With DANE-TA(2), a complication arises when the TA certificate is omitted from the server's certificate chain, perhaps on the basis of 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 certification 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.
With TLSA Certificate Usage DANE-TA(2), there is no expectation that the client is pre-configured with the trust anchor certificate. In fact, client implementations are free to ignore all locally configured trust anchors when processing usage DANE-TA(2) TLSA records and may rely exclusively on the certificates provided in the server's certificate chain. 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) associations with a selector of SPKI(1) or using a digest-based matching type (not Full(0)) 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) will 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. The issuer name is not included in the subjectPublicKeyInfo.
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.
When 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's public key in the TLSA record. Such a check may be difficult to implement, and cannot be expected to be supported by all clients.
Thus, servers should not rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA records to be sufficient to authenticate chains issued by the associated public key in the absence of a corresponding certificate in the server's TLS certificate message. Servers SHOULD include the TA certificate in their certificate chain.
If none of the server's certificate chain elements match a public key specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) Full(0)" TLSA record is available, clients are encouraged to check whether the topmost certificate in the chain is signed by the provided public key and has not expired, and in that case consider the server authenticated, provided the rest of the chain passes validation including leaf certificate name checks.
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.
This section updates [RFC6698] by specifying new client implementation requirements. Clients that trust intermediate certificates MUST be prepared to construct longer PKIX chains than would be required for PKIX alone.
TLSA Certificate Usage PKIX-TA(0) allows a domain to publish constraints on the set of PKIX certification authorities trusted to issue certificates for its TLS servers. This TLSA record matches PKIX-verified trust chains which contain an issuer certificate (root or intermediate) that matches its association data field (typically a certificate or digest).
PKIX-TA(0) also requires more complex coordination between the Customer Domain and the Service Provider in hosting arrangements. Thus, this certificate usage is NOT RECOMMENDED when the Service Provider is not also the TLSA Publisher.
TLSA Publishers who publish TLSA records for a particular public root CA, will expect that clients will 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 the trusted root published in the server's TLSA record.
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 record. Thus, when matching a usage PKIX-TA(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, and the trusted certificate found is not self-issued, the client MUST attempt to build a longer chain in the hope that a certificate closer to the root may in fact match the server's TLSA record.
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 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 service outages will result when coordination fails.
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. Even when the TLSA RRset must 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. 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 (assumed "secure" and shown without the associated DNSSEC information, such as record signatures) that illustrate both of 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.
;
; A single certificate at the provider works for all Customer
; Domains due to the use of the DANE-EE(3) Certificate Usage.
;
www1.example.com. IN CNAME w1.example.net.
_443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
_443._tcp.w1.example.net. IN TLSA 3 1 1 (
8A9A70596E869BED72C69D97A8895DFA
D86F300A343FECEFF19E89C27C896BC9 )
;
; A CA at the provider can also issue certificates for each Customer
; Domain, and use the DANE-TA(2) Certificate Usage type to
; indicate a trust anchor.
;
www2.example.com. IN CNAME w2.example.net.
_443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net.
_443._tcp.w2.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 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 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
;
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 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 must wait for matching TLSA records to be published by its Customer Domains before deploying newly generated keys and certificate chains. In Section 7 below, we describe an approach that employs CNAME "chasing" to avoid the difficulties of coordinating key management across organization boundaries.
For further information about combining DANE and SRV, please see [I-D.ietf-dane-srv].
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, since 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 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.
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 SNI, and MUST be the primary reference identifier for peer certificate matching with certificate usages other than DANE-EE(3).
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, use the CNAME expanded domain also in SNI and certificate name checks).
This section updates [RFC6698] by specifying a requirement on the TLSA Publisher to ensure that each combination of Certificate Usage, selector and matching type in the server's TLSA RRset MUST include 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 never be the only records published for any given combination of usage, selector and matching type. We describe a TLSA record update algorithm that ensures 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 may 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).
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 the above requirement is met.
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 TTLs or longer before the 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 no longer active chain:
; The initial TLSA RRset
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
; The transitional TLSA RRset published at least 2*TTL seconds
; before the actual key change
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; The final TLSA RRset after the key change
;
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
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
;
_443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
; New TLSA RRset, same key re-published as DANE-EE(3)
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
A more complex involves switching to a trust-anchor or PKIX usage from a chain that is either self-signed, or issued by a private CA and thus not compatible with PKIX. Here the process is to first add TLSA records matching the future chain that is issued by the desired future CA (private or PKIX), but initially with the same parameters as the legacy chain. Then, after deploying the new keys, switch to the new TLSA parameter combination.
; The initial TLSA RRset
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
; A transitional TLSA RRset, published at least 2*TTL before the
; actual key change. The new keys are issued by a DANE-TA(2) CA,
; but for now specified via a DANE-EE(3) association.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; The final TLSA RRset after the key change. Now that the old
; self-signed EE keys are not an impediment, specify the issuing
; TA of the new keys.
;
_443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
When employing a new digest algorithm in the TLSA RRset, for compatibility with digest agility specified in Section 9 below, administrators should publish the new digest algorithm with each combinations 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).
; The initial TLSA RRset with EE SHA2-256 associations for two keys.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; The new TLSA RRset also with SHA2-512 associations for each key
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
_443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
In summary, server operators updating TLSA records should make one change at a time. The individual safe changes are:
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. No combination of Certificate Usage, selector and matching type in a server's TLSA RRset should ever 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.
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 which SHOULD be avoided when possible. We specify such a protocol 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 DANE matching type Full(0), as these do not employ a digest algorithm that might some day be weakened by cryptanalysis.
Client implementations SHOULD implement a default order of digest algorithms by strength. This order SHOULD be configurable by the MTA administrator. 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 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.
_25._tcp.mail.example.com. IN TLSA 3 1 1 (
3FE246A848798236DD2AB78D39F0651D
6B6E7CA8E2984012EB0A2E1AC8A87B72 )
_25._tcp.mail.example.com. IN TLSA 3 1 2 (
D4F5AF015B46C5057B841C7E7BAB759C
BF029526D29520C5BE6A32C67475439E
54AB3A945D80C743347C9BD4DADC9D8D
57FAB78EAA835362F3CA07CCC19A3214 )
_25._tcp.mail.example.com. IN TLSA 3 1 0 (
3059301306072A8648CE3D020106082A
8648CE3D0301070342000471CB1F504F
9E4B33971376C005445DACD33CD79A28
81C3DED1981F18E7AAA76609DD0E4EF2
8265C82703030AD60C5DBA6FB8A9397A
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 SHOULD not accept keys that match only the weaker "3 1 1" record.
These guidelines provide guidance for using or designing protocols for DANE.
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 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 TC bit alone will be insufficient if the response containing the TC bit is itself fragmented.
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 without the overhead of a containing X.509 certificate) are generally more compact, these too should be used with caution as they are still larger than necessary. Rather, servers SHOULD publish digest-based TLSA Matching Types in their TLSA records. The complete corresponding certificate should, instead, be transmitted to the client in-band during the TLS handshake, which can be easily verified using the digest value.
In summary, the use of a TLSA Matching Type of Full(0) is NOT RECOMMENDED and the use of a digest-based matching type, such as SHA2-256(1) SHOULD be used.
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 subjectAltName extension. (The use of the CN field for this purpose is deprecated.)
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 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. 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 the certificate that was selected based on the SNI information provided by the client).
Given the DNSSEC validated DNS records below:
example.com. IN MX 0 mail.example.com.
mail.example.com. IN A 192.0.2.1
_25._tcp.mail.example.com. IN TLSA 2 0 1 (
E8B54E0B4BAA815B06D3462D65FBC7C0
CF556ECCF9F5303EBFBB77D022F834C0 )
The TLSA base domain is "mail.example.com" and is required to be the HostName in the client's SNI extension. The server certificate chain is required to be be signed by a trust anchor with the above certificate SHA2-256 digest. Finally, one of the DNS names in the server certificate is required to be be either "mail.example.com" or "example.com" (this additional name is a concession to compatibility with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details).
The semantics of wildcards in server certificates are left to individual application protocol specifications.
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 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 requirements, as appropriate, to specify whether the connection should be established anyway without relying on TLS security, with only encryption but not authentication, or whether to refuse to connect entirely. Application protocols need to specify when to prioritize security over the ability to connect under adverse conditions.
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 implementers.
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, under the Registry/Registrar/Registrant model, 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 many 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 periods. For domains publishing high-value keys, a signature lifetime of a few days is reasonable, and the zone should be resigned daily. For domains with less critical data, a reasonable signature lifetime is a couple of weeks to a month, and the zone should be resigned weekly. Monitoring of the signature lifetime is important. If the zone is not resigned in a timely manner, one risks a major outage and the entire domain will become bogus.
Authors note: is this section needed? Or is it sufficiently clear above that we don't need to restate things here?
The DNS time-to-live (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. TLSA RRsets should have TTLs that are short enough to limit unplanned service disruption to an acceptable duration.
The signature validity period for TLSA records should also 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. See Section 4.4.1 of [RFC6781].
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].
This specification requires no support from IANA.
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 document and provided feedback on early drafts. Thanks also to Samuel Dukhovni for editorial assistance.
| [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-17, May 2015. |
| [I-D.ietf-dane-srv] | Finch, T., Miller, M. and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", Internet-Draft draft-ietf-dane-srv-14, April 2015. |
| [RFC6781] | Kolkman, O., Mekking, W. and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, December 2012. |
| [RFC6962] | Laurie, B., Langley, A. and E. Kasper, "Certificate Transparency", RFC 6962, June 2013. |
| [RFC7250] | Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S. and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, June 2014. |
| [RFC7435] | Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, December 2014. |