One document matched: draft-dukhovni-dane-ops-00.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 RFC2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY RFC3546 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3546.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 RFC6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY RFC6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY I-D.ietf-dane-srv SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dane-srv.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-dukhovni-dane-ops-00" ipr="trust200902" updates="6698">

<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>
<date year="2013" />
<area>sec</area>
<workgroup>DANE</workgroup>
<keyword>DANE</keyword>
<keyword>TLSA</keyword>

<abstract>

<t>
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.
</t>

</abstract>

</front>

<middle>
<section title="Introduction">

<t>
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System.  DNSSEC
is defined in <xref target="RFC4033"/>, <xref target="RFC4034"/> and
<xref target="RFC4035"/>.
</t>

<t>
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 <xref target="RFC2246"/>, two updates to the
protocol have been published: TLS 1.1 <xref target="RFC4346"/> and
TLS 1.2 <xref target="RFC5246"/>.
</t>

<t>
As described in the introduction of <xref target="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.
</t>

<t>
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.
</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>
This memo is being discussed on the dane@ietf.org mailing list.
</t>

</section><!-- Terminology -->

</section><!-- Introduction -->

<section title="DANE TLSA record overview">
<t>
<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 the following 3 parameters:  </t>

<t>
<list style='symbols'>

<t>
The certificate usage field.  Section 2.1.1 of <xref target="RFC6698"/>
specifies 4 values ranging from 0 to 3.
</t>

<t>
The selector field.  Section 2.1.2 of <xref target="RFC6698"/>
specifies 2 values ranging from 0 to 1.
</t>

<t>
The matching type field.  Section 2.1.3 of <xref target="RFC6698"/>
specifies 3 values ranging from 0 to 2.
</t>

</list>
</t>

<t>
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:
</t>

<t>
<list style="symbols">

<t>
When the low bit is set (certificate usages 1 and 3) the TLSA record
matches an EE (server) certificate.
</t>

<t>
When the low bit is not set (certificate usages 0 and 2) the TLSA
record matches a TA, that is a certificate authority that ultimately
issued the server certificate, possibly through a chain if intermediate
certificate authorities.  In this context <xref target="RFC6125"/>
specifies how to match the TLS server name against the contents of
the leaf certificate (name matching with PKIX is rather complex
with many application-specific variations).
</t>

<t>
When the high bit is set (certificate usages 2 and 3) the server
certificate chain is domain-issued and may be verified without
reference to the existing public certificate authority PKI, with
trust entirely based on the content of the TLSA records obtained
from DNS.
</t>

<t>
When the high bit is not set (certificate usages 0 and 1) the TLSA
record publishes a server policy to the effect that the certificate
chain must pass PKIX validation <xref target="RFC5280"/>, with the
DANE TLSA record used to specify which trusted public CA may be
used to validate the server certificate chain.
</t>

</list>
</t>

<t>
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.
</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 "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.
</t>

<t>
In the example TLSA record below:
</t>

<figure>
<artwork>
_25._tcp.mail.example.com. IN TLSA 3 1 2 (
                              E8B54E0B4BAA815B06D3462D65FBC7C0
                              CF556ECCF9F5303EBFBB77D022F834C0
                              5DC75F17F9963DF8A572A5B9209CF1AB
                              9DC14CD0C0C8393072D49365017553F8 )
</artwork>
</figure>

<t>
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.
</t>

</section><!-- DANE TLSA record overview -->

<section title="Obligations of TLSA record creator and consumer">

<t>
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 <xref target="RFC3546"/> Section 3.1).
</t>

<t>
When, for example, the TLSA RRset is published at
</t>
<figure>
<artwork>
        _25._tcp.mx1.example.com
</artwork>
</figure>
<t>
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.
</t>

<t>
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.
</t>

<t>
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.
</t>

<t>
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.
</t>

<t>
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.
</t>

<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 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).
</t>

<t>
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.
</t>

<t>
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.
</t>

<t>
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.
</t>

<t>
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.
</t>

</section><!-- Obligations of TLSA record publisher and consumer -->

<section title="TLSA record usability">

<section title="Non-PKIX application protocols">

<t>
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 <xref target="RFC5280"/> PKIX validation or
<xref target="RFC6125"/> Identity verification.
</t>

<t>
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.
</t>

<t>
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.
</t>

<section title="Certificate usage 1">

<t>
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.
</t>

</section><!-- Certificate usage 1 -->

<section title="Certificate usage 0">

<t>
With certificate usage "0" the usability of the TLSA records depends
on its matching type.
</t>

<t>
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. 
</t>

<t>
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 <xref target="d0"/> 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.
</t>

<t>
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.
</t>

</section><!-- Certificate usage 0 -->

</section><!-- Non-PKIX application protocols -->

<section title="TLSA records and trust anchor digests">

<t>
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.
</t>

<t>
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 <xref target="RFC2246"/>:
</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 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.
</artwork>
</figure>

<t>
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.
</t>

<section anchor="d0" title="Trust anchor digests with certificate usage 0">

<t>
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 <xref target="RFC5280"/>
PKIX validation of the server's trust chain and thus to already
have a copy of the omitted root certificate.
</t>

<t>
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 <xref target="I-D.ietf-dane-srv"/>).
</t>

</section><!-- Trust anchor digests with certificate usage 0 -->

<section title="Trust anchor digests with certificate usage 2">

<t>
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.
</t>

<t>
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.
</t>

<t>
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.
</t>

</section><!-- Trust anchor digests with certificate usage 2 -->

</section><!-- Trust anchor digests -->

<section title="Trust anchor public keys">

<t>
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 <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 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.
</t>

<t>
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.
</t>

<t>
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.
</t>

<t>
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.
</t>

</section><!-- Trust anchor public keys -->

</section><!-- TLSA record usability -->

<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
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.
</t>

<t>
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.
</t>

<t>
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.
</t>

</section>

<section anchor="Acknowledgements" title="Acknowledgements">

<t>
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.
</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 to not implement
certain PKIX-dependent TLSA record types defined in <xref
target="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.
</t>

<t>
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 <xref target="RFC6698"/>.
</t>

</section><!-- Security Considerations -->

</middle>

<back>
<references title="Normative References">
&RFC2119;
&RFC2246;
&RFC3546;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4346;
&RFC5246;
&RFC5280;
&RFC6125;
&RFC6698;
</references>
<references title="Informative References">
&I-D.ietf-dane-srv;
</references>
</back>
</rfc>