Appendix A. Operational Considerations for Deploying TLSA Records

A.1. Creating TLSA Records

When creating TLSA records, care must be taken to avoid misconfigurations. Section 4 of this document states that a TLSA RRSet whose validation state is secure MUST be used. This means that the existence of such a RRSet effectively disables other forms of name and path validation. A misconfigured TLSA RRSet will effectively disable access to the TLS server for all conforming clients, and this document does not provide any means of making a gradual transition to using TLSA.

When creating TLSA records with certificate usage 0 (CA certificate) or usage 2 (trust anchor), one needs to understand the implications when choosing between selector type 0 (Full certificate) and 1 (SubjectPublicKeyInfo). A careful choice is required because different methods for building trust chains are used by different TLS clients. The following outlines the cases that one ought to be aware of and discusses the implications of the choice of selector type.

Certificate usage 2 is not affected by the different types of chain building when the end entity certificate is the same as the trust anchor certificate.

A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains

TLS clients can implement their own chain-building code rather than rely on the chain presented by the TLS server. This means that, except for the end entity certificate, any certificate presented in the suggested chain might or might not be present in the final chain built by the client.

Certificates that the client can use to replace certificates from the original chain include:

• Client's trust anchors

• Certificates cached locally

• Certificates retrieved from a URI listed in an Authority Information Access X.509v3 extension

CAs frequently reissue certificates with different validity periods, signature algorithms (such as a different hash algorithm in the signature algorithm), CA key pairs (such as for a cross-certificate), or PKIX extensions where the public key and subject remain the same. These reissued certificates are the certificates that the TLS client can use in place of an original certificate.

Clients are known to exchange or remove certificates that could cause TLSA certificate associations that rely on the full certificate to fail. For example:

• The client considers the signature algorithm of a certificate to no longer be sufficiently secure.

• The client might not have an associated root certificate in its trust store and instead uses a cross-certificate with an identical subject and public key.

A.1.2. Choosing a Selector Type

In this section, "false-negative failure" means that a client will not accept the TLSA certificate association for a certificate designated by the DNS administrator. Also, "false-positive acceptance" means that the client accepts a TLSA association for a certificate that is not designated by the DNS administrator.

A.1.2.1. Selector Type 0 (Full Certificate)

The "Full certificate" selector provides the most precise specification of a TLSA certificate association, capturing all fields of the PKIX certificate. For a DNS administrator, the best course to avoid false-negative failures in the client when using this selector is:

1. If a CA issued a replacement certificate, don't associate to CA certificates that have a signature algorithm with a hash that is considered weak by local policy.

2. Determine how common client applications process the TLSA certificate association using a fresh client installation -- that is, with the local certificate cache empty.

A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo)

A SubjectPublicKeyInfo selector gives greater flexibility in avoiding some false-negative failures caused by trust-chain-building algorithms used in clients.

One specific use case ought to be noted: creating a TLSA certificate association to CA certificate I1 that directly signed end entity certificate S1 of the server. The case can be illustrated by the following graph:

        +----+                      +----+
        | I1 |                      | I2 |
        +----+                      +----+
           |                           |
           v                           v
        +----+                      +----+
        | S1 |                      | S1 |
        +----+                      +----+
Certificate chain sent by    A different validation path
server in TLS handshake      built by the TLS client

I2 is a reissued version of CA certificate I1 (that is, it has a different hash in its signature algorithm).

In the above scenario, both certificates I1 and I2 that sign S1 need to have identical SubjectPublicKeyInfo fields because the key used to sign S1 is fixed. An association to SubjectPublicKeyInfo (selector type 1) will always succeed in such a case, but an association with a full certificate (selector type 0) might not work due to a false-negative failure.

The attack surface is a bit broader compared to the "Full certificate" selector: the DNS administrator might unintentionally specify an association that would lead to false-positive acceptance.

• The administrator must know or trust that the CA does not engage in bad practices, such as not sharing the key of I1 for unrelated CA certificates (which would lead to trust-chain redirection). If possible, the administrator ought to review all CA certificates that have the same SubjectPublicKeyInfo field.

• The administrator ought to understand whether some PKIX extension may adversely affect security of the association. If possible, administrators ought to review all CA certificates that share the SubjectPublicKeyInfo.

• The administrator ought to understand that any CA could, in the future, issue a certificate that contains the same SubjectPublicKeyInfo. Therefore, new chains can crop up in the future without any warning.

Using the SubjectPublicKeyInfo selector for association with a certificate in a chain above I1 needs to be decided on a case-by-case basis: there are too many possibilities based on the issuing CA's practices. Unless the full implications of such an association are understood by the administrator, using selector type 0 is a better option from a security perspective.

A.2. Provisioning TLSA Records in DNS

A.2.1. Provisioning TLSA Records with Aliases

The TLSA resource record is not special in the DNS; it acts exactly like any other RRtype where the queried name has one or more labels prefixed to the base name, such as the SRV RRtype [RFC2782]. This affects the way that the TLSA resource record is used when aliasing in the DNS.

Note that the IETF sometimes adds new types of aliasing in the DNS. If that happens in the future, those aliases might affect TLSA records, hopefully in a good way.

A.2.1.1. Provisioning TLSA Records with CNAME Records

Using CNAME to alias in DNS only aliases from the exact name given, not any zones below the given name. For example, assume that a zone file has only the following:

sub1.example.com.          IN CNAME sub2.example.com.

In this case, a request for the A record at "bottom.sub1.example.com" would not return any records because the CNAME given only aliases the name given. Assume, instead, the zone file has the following:

sub3.example.com.          IN CNAME sub4.example.com.
bottom.sub3.example.com.   IN CNAME bottom.sub4.example.com.

In this case, a request for the A record at bottom.sub3.example.com would in fact return whatever value for the A record exists at bottom.sub4.example.com.

Application implementations and full-service resolvers request DNS records using libraries that automatically follow CNAME (and DNAME) aliasing. This allows hosts to put TLSA records in their own zones or to use CNAME to do redirection.

If the owner of the original domain wants a TLSA record for the same, they simply enter it under the defined prefix:

; No TLSA record in target domain
;
sub5.example.com.            IN CNAME sub6.example.com.
_443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com.            IN A 192.0.2.1
sub6.example.com.            IN AAAA 2001:db8::1

If the owner of the original domain wants to have the target domain host the TLSA record, the original domain uses a CNAME record:

; TLSA record for original domain has CNAME to target domain
;
sub5.example.com.            IN CNAME sub6.example.com.
_443._tcp.sub5.example.com.  IN CNAME _443._tcp.sub6.example.com.
sub6.example.com.            IN A 192.0.2.1
sub6.example.com.            IN AAAA 2001:db8::1
_443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...

Note that it is acceptable for both the original domain and the target domain to have TLSA records, but the two records are unrelated. Consider the following:

; TLSA record in both the original and target domain
;
sub5.example.com.            IN CNAME sub6.example.com.
_443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com.            IN A 192.0.2.1
sub6.example.com.            IN AAAA 2001:db8::1
_443._tcp.sub6.example.com.  IN TLSA 1 1 1 ac49d9ba4570ac49...

In this example, someone looking for the TLSA record for sub5.example.com would always get the record whose value starts with "308202c5308201ab"; the TLSA record whose value starts with "ac49d9ba4570ac49" would only be sought by someone who is looking for the TLSA record for sub6.example.com, and never for sub5.example.com. Note that deploying different certificates for multiple services located at a shared TLS listener often requires the use of TLS SNI (Server Name Indication) [RFC6066].

Note that these methods use the normal method for DNS aliasing using CNAME: the DNS client requests the record type that they actually want.

A.2.1.2. Provisioning TLSA Records with DNAME Records

Using DNAME records allows a zone owner to alias an entire subtree of names below the name that has the DNAME. This allows the wholesale aliasing of prefixed records such as those used by TLSA, SRV, and so on without aliasing the name itself. However, because DNAME can only be used for subtrees of a base name, it is rarely used to alias individual hosts that might also be running TLS.

; TLSA record in target domain, visible in original domain via DNAME
;
sub5.example.com.            IN CNAME sub6.example.com.
_tcp.sub5.example.com.       IN DNAME _tcp.sub6.example.com.
sub6.example.com.            IN A 192.0.2.1
sub6.example.com.            IN AAAA 2001:db8::1
_443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...

A.2.1.3. Provisioning TLSA Records with Wildcards

Wildcards are generally not terribly useful for RRtypes that require prefixing because one can only wildcard at a layer below the host name. For example, if one wants to have the same TLSA record for every TCP port for www.example.com, the result might be:

*._tcp.www.example.com.    IN TLSA 1 1 1 5c1502a6549c423b...

This is possibly useful in some scenarios where the same service is offered on many ports or the same certificate and/or key is used for all services on a host. Note that the domain being searched for is not necessarily related to the domain name found in the certificate, so a certificate with a wildcard in it is not searched for using a wildcard in the search request.

A.3. Securing the Last Hop

As described in Section 4, an application processing TLSA records must know the DNSSEC validity of those records. There are many ways for the application to determine this securely, and this specification does not mandate any single method.

Some common methods for an application to know the DNSSEC validity of TLSA records include:

• The application can have its own DNS resolver and DNSSEC validation stack.

• The application can communicate through a trusted channel (such as requests to the operating system under which the application is running) to a local DNS resolver that does DNSSEC validation.

• The application can communicate through a secured channel (such as requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local DNS resolver that does DNSSEC validation.

• The application can communicate through a secured channel (such as requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local DNS resolver that does not do DNSSEC validation, but gets responses through a secured channel from a different DNS resolver that does DNSSEC validation.

A.4. Handling Certificate Rollover

Certificate rollover is handled in much the same way as for rolling DNSSEC zone signing keys using the pre-publish key rollover method [RFC4641]. Suppose example.com has a single TLSA record for a TLS service on TCP port 990:

_990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...

To start the rollover process, obtain or generate the new certificate or SubjectPublicKeyInfo to be used after the rollover and generate the new TLSA record. Add that record alongside the old one:

_990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
_990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...

After the new records have propagated to the authoritative nameservers and the TTL of the old record has expired, switch to the new certificate on the TLS server. Once this has occurred, the old TLSA record can be removed:

_990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...

This completes the certificate rollover.