One document matched: draft-ietf-dane-ops-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY RFC6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC6962 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6962.xml">
<!ENTITY I-D.ietf-dane-srv SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dane-srv.xml">
<!ENTITY I-D.ietf-dane-smtp-with-dane SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dane-smtp-with-dane.xml">
<!ENTITY I-D.ietf-dane-registry-acronyms SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dane-registry-acronyms.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="bcp" docName="draft-ietf-dane-ops-02" ipr="trust200902">
<front>
<title abbrev="DANE operations">DANE TLSA implementation and operational guidance</title>
<author fullname="Viktor Dukhovni" initials="V." surname="Dukhovni">
<organization>Unaffiliated</organization>
<address>
<email>ietf-dane@dukhovni.org</email>
</address>
</author>
<author initials="W.H." surname="Hardaker" fullname="Wes Hardaker">
<organization>Parsons</organization>
<address>
<postal>
<street>P.O. Box 382</street>
<city>Davis</city>
<region>CA</region>
<code>95617</code>
<country>US</country>
</postal>
<email>ietf@hardakers.net</email>
</address>
</author>
<date month="January" year="2014" />
<area>sec</area>
<workgroup>DANE</workgroup>
<keyword>DANE</keyword>
<keyword>TLSA</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Section 2 of <xref target="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.
</t>
<t>
<xref target="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 (<xref target="RFC6066" />, section 3). This
memo provides operational guidelines intended to maximize interoperability
between DANE TLS clients and servers.
</t>
<t>
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.
</t>
<section title="Terminology">
<t>
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 <xref
target="RFC2119"/>.
</t>
<t>The following terms are used throughout this document:
<list style="hanging">
<t hangText="Service Provider:">
A company or organization that offers to host a service on behalf
of a Customer Domain. The original domain name associated with the
service often remains under the control of the customer. Connecting
applications are directed to the Service Provider via a redirection
resource record. Example redirection records include MX, SRV, and
CNAME. The Service Provider typically provides services for
many customers and must carefully manage any TLS credentials
offered to connecting applications to ensure name matching is
handled easily by the applications.
</t>
<t hangText="Customer Domain:">
Customers that make use of a Service Provider to outsource their
services will be referred to as "Customer Domains".
</t>
<t hangText="TLSA Publisher:">
The entity responsible for publishing a TLSA record within a DNS
zone. This zone will be considered DNSSEC-signed and validatable
to a trust anchor, unless otherwise specified. If the Customer
Domain is not outsourcing their DNS service, the TLSA Publisher
will be the customer themselves. Otherwise the TLSA Publisher may
be the operator of the outsourced DNS service.
</t>
<t hangText="public key:">
The term "public key" will be an informal short-hand for the
subjectPublicKeyInfo component of a PKIX certificate.
</t>
<t hangText="SNI:">
"Server Name Indication", or SNI, describes the TLS protocol
extension by which a TLS client requests to connect to a
particular service name of a TLS server (<xref target="RFC6066"
/>, section 3). Without this TLS extension, a TLS server has no choice
but to offer a PKIX certificate with a default list of server
names, making it difficult to host multiple Customer Domains at
the same TLS service endpoint (secure virtual hosting).
</t>
</list>
</t>
</section><!-- Terminology -->
</section><!-- Introduction -->
<section title="DANE TLSA record overview">
<t>
DANE TLSA <xref target="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 <xref
target="I-D.ietf-dane-registry-acronyms"/>. These parameters
are:
</t>
<t>
<list style='hanging'>
<t hangText="The TLSA Certificate Usage field:"> Section 2.1.1
of <xref target="RFC6698"/> specifies 4 values: PKIX-TA(0),
PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There is an additional
private-use value: PrivCert(255). All other values are reserved
for use by future specifications. </t>
<t hangText="The selector field:"> Section 2.1.2 of <xref
target="RFC6698"/> specifies 2 values: Cert(0), SPKI(1). There
is an additional private-use value: PrivSel(255). All other
values are reserved for use by future specifications. </t>
<t hangText="The matching type field:"> Section 2.1.3 of <xref
target="RFC6698"/> specifies 3 values: Full(0), SHA2-256(1),
SHA2-512(2). There is an additional private-use value:
PrivMatch(255). All other values are reserved for use by future
specifications. </t>
</list>
</t>
<t>
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:
</t>
<t>
<list style="symbols">
<t> When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the
TLSA record matches an EE (commonly referred to as a leaf or
server) certificate. </t>
<t> When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the
TLSA record matches a trust anchor (a certificate authority)
that issued one of the certificates in the server certificate
chain. </t>
<t> When the high bit is set (DANE-TA(2) and DANE-EE(3)), the
server certificate chain is domain-issued and may be verified
without reference to any pre-existing public certificate authority
PKI. Trust is entirely placed on the content of the TLSA records
obtained via DNSSEC. </t>
<t> When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)),
the TLSA record publishes a server policy stating that its
certificate chain must pass PKIX validation <xref target="RFC5280"/>
and the DANE TLSA record is used to constrain the server
certificate chain to contain the referenced CA or EE certificate.
</t>
</list>
</t>
<t>
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.
</t>
<t>
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 <xref
target="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.
</t>
<section title="Example TLSA record">
<t>
In the example TLSA record below:
</t>
<figure>
<artwork>
_25._tcp.mail.example.com. IN TLSA 2 0 1 (
E8B54E0B4BAA815B06D3462D65FBC7C0
CF556ECCF9F5303EBFBB77D022F834C0 )
</artwork>
</figure>
<t>
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.
</t>
</section><!-- Example TLSA record -->
</section><!-- DANE TLSA record overview -->
<section title="General DANE Guidelines">
<t>
These guidelines provide guidance for using or designing protocols
for DANE, regardless of what sort of TLSA record will be used.
</t>
<section title="TLS Requirements">
<t>
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.
</t>
</section>
<section title="DANE DNS Record Size Guidelines">
<t>
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.
</t>
<section title="UDP and TCP Considerations">
<t>
Deployments SHOULD avoid TLSA record sizes that cause UDP
fragmentation.
</t>
<t>
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.
</t>
</section>
<section title= "Packet Size Considerations for TLSA Parameters">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Certificate Name Check Conventions">
<t>
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.
</t>
<t>
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.
</t>
<t>
Except with TLSA Certificate Usage DANE-EE(3), where name
checks are not applicable (see <xref target="type3" />), 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 <xref
target="I-D.ietf-dane-smtp-with-dane"/>).
</t>
<t>
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.
</t>
<t>
Given the DNSSEC validated DNS records below:
</t>
<figure>
<artwork>
example.com. IN MX 0 mail.example.com.
_25._tcp.mail.example.com. IN TLSA 2 0 1 (
E8B54E0B4BAA815B06D3462D65FBC7C0
CF556ECCF9F5303EBFBB77D022F834C0 )
</artwork>
</figure>
<t>
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".
</t>
</section>
<section title="Service Provider and TLSA Publisher Synchronization"
anchor="sync">
<t>
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.
</t>
<t>
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.
</t>
<t>
Even when the TLSA RRset must be published in the Customer
Domain's DNS zone, it is possible to employ CNAME records (see
<xref target="cname"/>) 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):
</t>
<t>
<list style="hanging">
<t hangText="Certificate Usage DANE-EE(3):"> In this case the
Service Provider can publish a single TLSA RRset that matches
the server certificate or public key digest. The same RRset
works for all Customer Domains because name checks do not apply
with DANE-EE(3) TLSA records. A Customer Domain can create a
CNAME record pointing to the TLSA RRset published by the Service
Provider. </t>
<t hangText="Certificate Usage DANE-TA(2):"> When the Service
Provider operates a private certificate authority, the Service
Provider is free to issue a certificate bearing any customer's
domain name. Without DANE, such a certificate would not pass
trust verification, but with DANE, the customer's TLSA RRset
aliased to the provider's TLSA RRset can grant legitimacy to
the provider's CA for the service in question! The Service
Provider can generate appropriate certificates for each customer
and use SNI to select the right certificate chain to present
to each client. </t>
</list>
</t>
<t>
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.
</t>
<figure>
<artwork>
; 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 )
</artwork>
</figure>
<t>
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:
</t>
<figure>
<artwork>
; 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 )
</artwork>
</figure>
<t>
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.
</t>
</section>
<section title="TLSA Base Domain and CNAMEs" anchor="cname">
<t>
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.
</t>
<t>
The complexity of coordinating key rollover is largely
eliminated when DANE TLSA records are found in the Service
Provider's domain, as discussed in <xref target="sync" />.
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.
</t>
<!-- XXX: MAY or SHOULD? -->
<t>
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.
</t>
<t>
Protocol-specific TLSA specifications may provide additional
guidance or restrictions when following CNAME expansions.
</t>
<t>
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.
</t>
</section>
<section title="Interaction with Certificate Transparency">
<t>
<xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
A server operator who wants clients to perform CT checks
should publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1).
</t>
</section>
<section title="Design Considerations for Protocols Using DANE">
<t>
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.
</t>
<t>
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.
</t>
<section title="Design Considerations for non-PKIX Protocols" anchor="nopki">
<t>
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 <xref target="RFC5280"/>
PKIX validation or <xref target="RFC6125"/> identity
verification.
</t>
<t>
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.
</t>
</section><!-- Design Considerations for non-PKIX Protocols -->
</section><!-- Design Considerations for Protocols Using DANE -->
<section title="TLSA Records and Trust Anchor Digests" anchor="tadgst">
<t>
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.
</t>
<t>
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 <xref target="RFC5246"/>:
</t>
<figure>
<artwork>
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.
</artwork>
</figure>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section><!-- Trust anchor digests -->
<section title="Trust anchor public keys">
<t>
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 <xref
target="RFC5280"/> the definition of a trust anchor consists
of the following four parts:
</t>
<t><list style="numbers">
<t>the trusted issuer name,</t>
<t>the trusted public key algorithm,</t>
<t>the trusted public key, and</t>
<t>optionally, the trusted public key parameters associated
with the public key.</t>
</list></t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
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.
</t>
</section><!-- Trust anchor public keys -->
</section>
<section title="Certificate Usage Specific DANE Guidelines">
<section title="Certificate Usage DANE-EE(3) Guidelines" anchor="type3">
<t>
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).
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Certificate Usage DANE-TA(2) Guidelines" anchor="type2">
<t>
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 <xref target="sync"/>).
</t>
<t>
As explained in <xref target="tadgst"/>, 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 <xref target="type3" />, two such TLSA RRs
need to be published to facilitate TA certificate rollover.
</t>
</section>
<section title="Certificate Usage PKIX-EE(1) Guidelines" anchor="type1">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Certificate Usage PKIX-TA(0) Guidelines" anchor="type0">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Note on DNSSEC security">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors would like to thank Phil Pennock for his comments and
advice on this document.
</t>
<t>
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.
</t>
</section><!-- Acknowledgements -->
<section anchor="Security" title="Security Considerations">
<t>
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 <xref
target="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.
</t>
<t>
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 <xref target="RFC6698"/>.
</t>
</section><!-- Security Considerations -->
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4346;
&RFC5246;
&RFC5280;
&RFC6066;
&RFC6125;
&RFC6347;
&RFC6698;
&RFC6962;
</references>
<references title="Informative References">
&I-D.ietf-dane-registry-acronyms;
&I-D.ietf-dane-smtp-with-dane;
&I-D.ietf-dane-srv;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:40 |