| DANE | V. Dukhovni |
| Internet-Draft | Unaffiliated |
| Updates: 6698 (if approved) | May 19, 2013 |
| Intended status: Informational | |
| Expires: November 20, 2013 |
DANE TLSA implementation and operational guidance
draft-dukhovni-dane-ops-00
This memo discusses some operational aspects of publishing and using DANE TLSA records. Server operators need to consider whether the intended clients are able to authenticate the server's certificate chain via the published TLSA records, some variations of TLSA records may not work as expected in all cases. Clients need to decide which variations of TLSA records are sufficiently robust to be usable for server authentication.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 20, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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 Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. DNSSEC is defined in [RFC4033], [RFC4034] and [RFC4035].
In the context of this memo channel security is assumed to be provided by TLS. The Transport Layer Security (TLS) protocol provides communications privacy over the Internet. Used without authentication, TLS provides protection only against eavesdropping. With authentication, TLS also provides protection against man-in-the-middle (MITM) attacks. Since the publication of the TLS 1.0 specification in [RFC2246], two updates to the protocol have been published: TLS 1.1 [RFC4346] and TLS 1.2 [RFC5246].
As described in the introduction of [RFC6698] TLS authentication via the existing public CA PKI suffers from an over-abundance of trusted certificate authorities capable of issuing certificates for any domain of their choice. DNS-Based Authentication of Named Entities (DANE) leverages the DNSSEC infrastructure to publish trusted keys and certificates for use with TLS via a new TLSA record type. DNSSEC validated DANE TLSA records yield a new PKI designed to augment or replace the trust model of the existing public CA PKI.
When a client goes to the trouble of authenticating a server it should not continue to use the server in case of authentication failure, otherwise authentication is pointless. Consequently, if a client cannot reliably authenticate correctly configured legitimate servers via a particular combination of TLSA parameters, then the client SHOULD treat that combination of parameters as unusable, otherwise the client risks routinely dropping connections to legimate servers. Servers publishing TLSA records MUST be configured in a manner that allows correctly configured clients to successfully authenticate the server.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This memo is being discussed on the dane@ietf.org mailing list.
[RFC6698] specifies a protocol for publishing TLS server certificate associations via DNSSEC. The DANE TLSA specification defines multiple TLSA RR types via combinations of the following 3 parameters:
We may consider the certificate usage values 0 through 3 to be a combination of two one-bit flags. The low-bit chooses between trust-anchor (TA) and end-entity (EE) certificates. The high bit chooses between public PKI issued and domain issued certificates:
The selector field specifies whether the TLSA RR matches the whole certificate or just its subjectPublicKeyInfo (i.e. an ASN.1 DER encoding of the algorithm, parameters and key data). In this memo the term public key will be an informal short-hand for the subjectPublicKeyInfo. A selector field of "0" specifies the whole certificate. A selector field of "1" specifies just the public key.
The matching type field specifies how the TLSA RR Certificate Association Data field is to be compared with the certificate or public key. A value of "0" means exact match, the DER encoding of the certificate or public is given in the TLSA RR. A non-zero value indicates that the content of the TLSA RR is a cryptographic digest of the certificate or public key. In particular "1" means a SHA-256 digest and "2" means a SHA-512 digest. Of these, only SHA-256 is mandatory to implement. Clients SHOULD implement SHA-512, but servers SHOULD NOT exclusively publish SHA-512 digests.
In the example TLSA record below:
_25._tcp.mail.example.com. IN TLSA 3 1 2 (
E8B54E0B4BAA815B06D3462D65FBC7C0
CF556ECCF9F5303EBFBB77D022F834C0
5DC75F17F9963DF8A572A5B9209CF1AB
9DC14CD0C0C8393072D49365017553F8 )
The certificate usage is "3", the selector is "1" and the matching type is "2". The rest of the record is the certificate association data field, which is in this case the SHA-512 digest of the server public key.
The party responsible for creating TLSA records for a given service MUST ensure that at least one of these TLSA records will match either the server's default certificate chain if SNI is not employed on the server, or the server's certificate chain when the client signals the base domain of the TLSA RRset via SNI with a name type of "host_name" (see [RFC3546] Section 3.1).
When, for example, the TLSA RRset is published at
_25._tcp.mx1.example.com
the base domain is mx1.example.com. At least one of the TLSA records in the RRset MUST match the server certificate chain, provided the client TLS hanshake included the SNI extension with a host_name of mx1.example.com.
Since the server's ability to respond with the right certificate chain may be predicated on the TLS client providing the correct SNI information, DANE PKI aware clients SHOULD send the SNI extension with a host_name value of the base domain of the TLSA RRset (otherwise they risk failure to authenticate the server). Since SNI is not available with SSLv2 or SSLv3, the server MUST support at least TLS 1.0; ensuring this is the case is the responsibility of the creator of the TLSA records.
Complications arise when TLSA records for a service are created by someone other than the server operator. In this situation the server operator and TLSA record creator must cooperate to ensure that TLSA records don't fall out of step with the server certificate configuration.
When the server operator is a hosting provider, ideally the application protocol allows the hosted customer to direct clients to the hosting provider's servers. This way, the associated TLSA records will be found in the hosting provider's DNSSEC zone, thus avoiding the complexity of bilateral coordination of server certificate configuration and TLSA record management.
For example, with SMTP, the customer's MX records can be pointed at the provider's MX hosts. When the customer's DNS zone is signed, the hostnames in that domain's MX records can be securely used as the base names for TLSA records managed by the hosting provider.
When the protocol does not support service location indirection via MX, SRV or similar DNS records, the service may be redirected via a CNAME. A CNAME is a more blunt instrument for this purpose, since unlike an MX or SRV record it remaps the origin host to the target host for all protocols. Also Unlike MX or SRV records CNAME records may chain (though clients will generally impose implementation dependent maximum nesting depths).
When CNAMEs are employed the sensible place to seek DANE TLSA records is in the providers domain, as that is the party that best knows which certificates are deployed on the server. Therefore, DANE PKI clients connecting to a server whose DNS name is a CNAME alias SHOULD follow the CNAME hop-by-hop to its ultimate target host (noting at each step whether the CNAME is DNSSEC validated) and use the resulting target host as the base domain for TLSA lookups.
If CNAMEs were not followed, to support DANE validation the origin domain would have to publish TLSA records that match the server certificate chain. Since the origin domain may not be operationally responsible for the server this imposes a complex key management burden on the hosting provider and hosted customer even with SNI.
Accordingly, TLSA records SHOULD NOT be published for a base domain that is a CNAME. Such TLSA records are not operationally robust, and SHOULD NOT be used by clients.
Though CNAMEs are illegal on the right hand side of MX and SRV records, they are supported by some implementations. If the MX or SRV host is a CNAME alias from a customer's domain to a server in the provider's domain, the client SHOULD follow the CNAME and SHOULD use the target hostname as the base domain for TLSA records as well as the host_name in SNI.
For some application protocols the existing public CA PKI is not viable. For these (non-PKIX) protocols servers SHOULD NOT publish TLSA records with certificate usage "0" or "1", as clients cannot be expected to perform [RFC5280] PKIX validation or [RFC6125] Identity verification.
Clients using non-PKIX protocols MAY choose to treat any TLSA records with certificate usage "0" or "1" as unusable. They may then choose to connect via unauthenticated mandatory TLS if no alternative authentication mechanisms are available.
If despite this recommendation servers for non-PKIX protocols do publish TLSA records with certificate usage "0" or "1", clients should should make use of these to the fullest extent possible.
With certificate usage "1" such clients SHOULD ignore the PKIX validation requirement, and authenticate the server per the content of the TLSA record alone. Since some servers may rely on SNI to select the correct certificate, the client SHOULD use the SNI extension to signal the base domain of the TLSA RRset.
With certificate usage "0" the usability of the TLSA records depends on its matching type.
If the matching type is "0" the TLSA record contains the full certificate or full public key of the trusted certificate authority. In this case the client has all the information it needs to match the server trust-chain to the TLSA record. The client SHOULD in this case ignore the PKIX validation requirement, and authenticate the server via its DANE TLSA records alone (sending SNI with the base domain as usual). The base domain of the TLSA records will be used in name checks.
If the matching type is not "0", the TLSA record contains only a digest of the trust certificate authority certificate or public key. The full certificate may not be included in the server's certificate chain and the client may not be able to match the server trust chain against the TLSA record. See Section 4.2.1 for a more complete discussion of this case. The client cannot reliably authenticate the server in this case and SHOULD treat the TLSA record as unusable.
If the client is configured with a set of trusted CAs believed to be sufficiently complete to authenticate all the servers with which it expects to communicate, then it MAY elect to honor certificate usage "0" TLSA records that publish digests of the trusted CA certificate or public key.
With TLSA records that match the EE certificate, the TLS client has no difficulty matching the TLS record against the server certificate, as this certificate is always present in the TLS server certificate chain. The TLS client can if necessary extract the public key from the server certificate, and can if necessary compute the appropriate digest.
With DANE TLSA records that match the digest of TA certificate or public key, a complication arises when the TA certificate is omitted from the server's certificate chain. This can happen when the trust-anchor is a root certificate authority, as stated in section 7.4.2 of [RFC2246]:
The sender's certificate must come first in the list.
Each following certificate must directly certify the one
preceding it. Because certificate validation requires
that root keys be distributed independently, the
self-signed certificate which specifies the root
certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must
already possess it in order to validate it in any case.
This means that TLSA records that match a TA certificate or public key digest are not directly sufficient to validate the peer certificate chain. If no matching certificate is found in the server's certificate chain, the chain may be signed by an omitted root CA whose digest matches the TLSA record. We will consider each trust-anchor certificate usage in turn.
In this case, from the server's perspective, the omission of the root CA seems reasonable, since in addition to authentication via DANE TLSA records the client is expected to to perform [RFC5280] PKIX validation of the server's trust chain and thus to already have a copy of the omitted root certificate.
From the client's perspective the situation is more nuanced. Despite the server's indicated preference for PKIX validation the client may not posess (or may not fully trust) a complete set of public root CAs. This is especially likely in protocols where the existing public CA PKI is not applicable. If it is likely that a client lacks a sufficiently complete list of trusted CAs, and that a non-negligible number of servers publish certificate usage 0 TLSA records with digests of omitted root CAs, then such a client SHOULD treat such TLSA records as "unusable". Simply ignoring PKIX validation is not an option, since the client will also be unable to match the TLSA record. The client will then typically fall back to unauthenticated TLS, as by assumption PKIX is also not an option (see [I-D.ietf-dane-srv]).
Here there is no expectation that the client is pre-configured with the trust anchor certificate. With certificate usage "2" clients rely on the TLSA records alone, but with a matching type other than "0" the TLSA records contain neither the full trust anchor certificate nor the full public key. If the server's certificate chain does not contain the trust-anchor certificate, most clients will be unable to authenticate the server.
Therefore, whoever creates TLSA records with certificate usage "2" and a non-zero matching type MUST ensure that the corresponding server is configured to include the associated trust anchor certificate in its TLS handshake certificate chain even if that certificate is a self-signed root CA and would have been optional in the context of the existing public CA PKI.
Since servers are expected to always provide usage "2" trust anchor certificates (either via DNS or else via the TLS hanshake), clients SHOULD fully support this certificate usage. Clients MAY choose to treat it as unusable if experience proves that servers don't consistently live up to their obligations.
TLSA records with certificate usage "0" or "2", selector "1" and a matching type of "0" publish the full public key of a trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition of a trust anchor consists of the following four parts:
Items 2–4 are precisely the contents of the subjectPublicKeyInfo published in the TLSA record, but the issuer name is not included in the public key.
With certificate usage "0" when the client is able to perform PKIX validation, the client can construct a complete PKIX trust chain and thus has access to the trust anchor name. So in that case the client can verify that the server certificate chain is issued by a trust anchor that matches the TLSA record.
With certificate usage "2" or with certificate usage "0" for a non-PKIX protocol, the client may not have the missing trust anchor certificate, and cannot generally verify whether a particular certificate chain is "issued by" the trust anchor described in the TLSA record. If the server certificate chain includes a CA certificate whose public key matches the TLSA record, the client can match that CA as the intended issuer. Otherwise, the client can only check that the topmost certificate in the server's chain is "signed by" by the trust anchor public key in the TLSA record.
Since trust chain validation via bare public keys rather than trusted CA certificates may be difficult to implement in existing TLS applications, servers MUST include the trust anchor certificate in their certificate chain when the certificate usage is "2". With non-PKIX protocols servers SHOULD avoid publishing TLSA records with certificate usage "0", but if they do, they SHOULD include any trust anchor certificates in the TLS certificate chain.
If none of the server's certificate chain elements match a public key specified in full in a TLSA record, clients SHOULD attempt to check whether the topmost certificate in the chain is signed by the provided public key, and if so consider the server trust chain valid, with authentication complete if name checks are also successful.
Clearly the security of the DANE TLSA PKI rests on the security of the underlying DNSSEC infrastructure. While this memo is not a guide to DNSSEC security a few comments may be helpful to TLSA implementors.
With the existing public CA PKI, name constraints are rarely used, and every public root CA can issue certificates for any domain of its choice. With DNSSEC the situation is different. Only the registrar of record can update a domain's DS record in the registry parent zone, in some cases of course the registry is the sole registrar. With gTLDs for which multiple registrars compete to provide domains in a single registry it is important to make sure that rogue registrars cannot easily initiate an unauthorized domain transfer, and thus take over DNSSEC for the domain. A registrar lock on one's domain may be a reasonable precaution for this reason.
When the registrar is also the DNS operator for the domain, when using DNSSEC one needs to consider whether the registrar will allow orderly migration of the domain to another registrar or DNS operator in a way that will maintain DNSSEC integrity. Discuss this with your registrar DNS operator before it is an emergency.
DNSSEC signed RRsets cannot be securely revoked before they expire. Plan accordingly and don't generate signatures with excessively long duration. For domains publishing high-value keys, a signature lifetime of a few days is reasonable, with the zone resigned every day or so. For more mundane domains a good signature lifetime is a couple of weeks to a month, with the zone resigned every week or so. Monitoring of the signature lifetime is important. If the zone is not resigned in a timely manner, one risks a major outage with the entire domain becoming invalid.
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.
Application protocols that cannot make use of the existing public CA PKI (so called non-PKIX protocols), may choose to not implement certain PKIX-dependent TLSA record types defined in [RFC6698], or may choose to make a best-effort use of such records. In neither case is security compromised, since by assumption PKIX verification is simply not an option for these protocols. When the TLS server is authenticated based on the TLSA records alone, the client client is as well authenticated as possible, treating the TLSA records as unusable would lead to weaker security.
Therefore, when TLSA records are used with protocols where PKIX does not apply, the recommended trade-off is for servers to not publish PKIX-dependent TLSA records, and for clients to use them as best they can, but otherwise treat them unusable. Of course when PKIX validation is an option clients SHOULD perform PKIX validation per [RFC6698].
| [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. |