draft-ietf-dane-protocol-20.txt   draft-ietf-dane-protocol-21.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Standards Track J. Schlyter Intended status: Standards Track J. Schlyter
Expires: October 31, 2012 Kirei AB Expires: November 18, 2012 Kirei AB
April 29, 2012 May 17, 2012
The DNS-Based Authentication of Named Entities (DANE) Transport Layer The DNS-Based Authentication of Named Entities (DANE) Transport Layer
Security (TLS) Protocol: TLSA Security (TLS) Protocol: TLSA
draft-ietf-dane-protocol-20 draft-ietf-dane-protocol-21
Abstract Abstract
Encrypted communication on the Internet often uses Transport Level Encrypted communication on the Internet often uses Transport Level
Security (TLS), which depends on third parties to certify the keys Security (TLS), which depends on third parties to certify the keys
used. This document improves on that situation by enabling the used. This document improves on that situation by enabling the
administrators of domain names to specify the keys used in that administrators of domain names to specify the keys used in that
domain's TLS servers. This requires matching improvements in TLS domain's TLS servers. This requires matching improvements in TLS
client software, but no change in TLS server software. client software, but no change in TLS server software.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2012. This Internet-Draft will expire on November 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 24 skipping to change at page 2, line 27
2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 8 2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 8
2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 8 2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 8
2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 9 2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 9
2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 10 2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 10
2.1.4. The Certificate Association Data Field . . . . . . . . 10 2.1.4. The Certificate Association Data Field . . . . . . . . 10
2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 10 2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 10
2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 11 2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 11
3. Domain Names for TLSA Certificate Associations . . . . . . . . 11 3. Domain Names for TLSA Certificate Associations . . . . . . . . 11
4. Use of TLSA Records in TLS . . . . . . . . . . . . . . . . . . 12 4. Use of TLSA Records in TLS . . . . . . . . . . . . . . . . . . 12
4.1. Usable Certificate Associations . . . . . . . . . . . . . 12 4.1. Usable Certificate Associations . . . . . . . . . . . . . 12
5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 13 5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 14
6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 15 6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. TLSA Certificate Usages . . . . . . . . . . . . . . . . . 16 7.2. TLSA Certificate Usages . . . . . . . . . . . . . . . . . 16
7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 16 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 17
7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 17 7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Comparing DANE to Public CAs . . . . . . . . . . . . . . . 18 8.1. Comparing DANE to Public CAs . . . . . . . . . . . . . . . 19
8.2. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 19 8.1.1. Risk of Key Compromise . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.2. Impact of Key Compromise . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.3. Detection of Key Compromise . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1.4. Spoofing Hostnames . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. External DNSSEC Validators . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Operational Considerations for Deploying TLSA Appendix A. Operational Considerations for Deploying TLSA
Records . . . . . . . . . . . . . . . . . . . . . . . 22 Records . . . . . . . . . . . . . . . . . . . . . . . 25
A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 22 A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 25
A.1.1. Ambiguities and Corner Cases When TLS Clients A.1.1. Ambiguities and Corner Cases When TLS Clients
Build Trust Chains . . . . . . . . . . . . . . . . . . 22 Build Trust Chains . . . . . . . . . . . . . . . . . . 25
A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 23
A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 25 A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 26
A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 25 A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 28
A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 27 A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 28
A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 28 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 30
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 28 A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 31
B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 29 Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 31
B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 30 B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 32
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 32 B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
1.1. Background and Motivation 1.1. Background and Motivation
Applications that communicate over the Internet often need to prevent Applications that communicate over the Internet often need to prevent
eavesdropping, tampering, or forgery of their communications. The eavesdropping, tampering, or forgery of their communications. The
Transport Layer Security (TLS) protocol provides this kind of Transport Layer Security (TLS) protocol provides this kind of
communications security over the Internet, using channel encryption. communications security over the Internet, using channel encryption.
The security properties of encryption systems depend strongly on the The security properties of encryption systems depend strongly on the
keys that they use. If secret keys are revealed, or if public keys keys that they use. If secret keys are revealed, or if public keys
can be replaced by bogus keys, these systems provide little or no can be replaced by fake keys (that is, a key not corresponding to the
security. entity identified in the certificate), these systems provide little
or no security.
TLS uses certificates to bind keys and names. A certificate combines TLS uses certificates to bind keys and names. A certificate combines
a published key with other information such as the name of the a published key with other information such as the name of the
service that uses the key, and this combination is digitally signed service that uses the key, and this combination is digitally signed
by another key. Having a certificate for a key is only helpful if by another key. Having a certificate for a key is only helpful if
one trusts the other key that signed the certificate. If that other one trusts the other key that signed the certificate. If that other
key was itself revealed or substituted, then its signature is key was itself revealed or substituted, then its signature is
worthless in proving anything about the first key. worthless in proving anything about the first key.
On the Internet, this problem has been solved for years by entities On the Internet, this problem has been solved for years by entities
skipping to change at page 4, line 43 skipping to change at page 4, line 44
that the client receives from TLS servers. Client software typically that the client receives from TLS servers. Client software typically
allows any CA to usefully sign any other certificate. allows any CA to usefully sign any other certificate.
The public CA model upon which TLS has depended is fundamentally The public CA model upon which TLS has depended is fundamentally
vulnerable because it allows any of these CAs to issue a certificate vulnerable because it allows any of these CAs to issue a certificate
for any domain name. A single trusted CA that betrays its trust, for any domain name. A single trusted CA that betrays its trust,
either voluntarily or by providing less-than-vigorous protection for either voluntarily or by providing less-than-vigorous protection for
its secrets and capabilities, can undermine the security offered by its secrets and capabilities, can undermine the security offered by
any certificates employed with TLS. This problem arises because a any certificates employed with TLS. This problem arises because a
compromised CA can issue a replacement certificate that contains a compromised CA can issue a replacement certificate that contains a
bogus key (that is, a key not corresponding to the entity identified fake key. Recent experiences with compromises of CAs or their
in the certificate). Recent experiences with compromises of CAs or trusted partners have led to very serious security problems, such as
their trusted partners have led to very serious security problems, the governments of multiple countries attempting to wiretap and/or
such as the governments of multiple countries attempting to wiretap subvert major TLS-protected web sites trusted by millions of users.
and/or subvert major TLS-protected web sites trusted by millions of
users.
The DNS Security Extensions (DNSSEC) provides a similar model that The DNS Security Extensions (DNSSEC) provides a similar model that
involves trusted keys signing the information for untrusted keys. involves trusted keys signing the information for untrusted keys.
However, DNSSEC provides three significant improvements. Keys are However, DNSSEC provides three significant improvements. Keys are
tied to names in the Domain Name System (DNS), rather than to tied to names in the Domain Name System (DNS), rather than to
arbitrary identifying strings; this is more convenient for Internet arbitrary identifying strings; this is more convenient for Internet
protocols. Signed keys for any domain are accessible online through protocols. Signed keys for any domain are accessible online through
a straightforward query using the standard DNSSEC protocol, so there a straightforward query using the standard DNSSEC protocol, so there
is no problem distributing the signed keys. Most significantly, the is no problem distributing the signed keys. Most significantly, the
keys associated with a domain name can only be signed by a key keys associated with a domain name can only be signed by a key
skipping to change at page 5, line 36 skipping to change at page 5, line 35
made by any entity, consistent with the naming scope imposed by the made by any entity, consistent with the naming scope imposed by the
DNS hierarchy. As a result, DANE embodies the security "principle of DNS hierarchy. As a result, DANE embodies the security "principle of
least privilege" that is lacking in the current public CA model. least privilege" that is lacking in the current public CA model.
1.2. Securing the Association of a Domain Name with a Server's 1.2. Securing the Association of a Domain Name with a Server's
Certificate Certificate
A TLS client begins a connection by exchanging messages with a TLS A TLS client begins a connection by exchanging messages with a TLS
server. For many application protocols, it looks up the server's server. For many application protocols, it looks up the server's
name using the DNS to get an Internet Protocol (IP) address name using the DNS to get an Internet Protocol (IP) address
associated with the name. It then begins a connection to a client- associated with the name. It then begins a connection to a
define port at that address, and sends an initial message there. particular port at that address, and sends an initial message there.
However, the client does not yet know whether an adversary is However, the client does not yet know whether an adversary is
intercepting and/or altering its communication before it reaches the intercepting and/or altering its communication before it reaches the
TLS server. It does not even know whether the real TLS server TLS server. It does not even know whether the real TLS server
associated with that domain name has ever received its initial associated with that domain name has ever received its initial
messages. messages.
The first response from the server in TLS may contain a certificate. The first response from the server in TLS may contain a certificate.
In order for the TLS client to authenticate that it is talking to the In order for the TLS client to authenticate that it is talking to the
expected TLS server, the client must validate that this certificate expected TLS server, the client must validate that this certificate
is associated with the domain name used by the client to get to the is associated with the domain name used by the client to get to the
skipping to change at page 7, line 5 skipping to change at page 7, line 4
certificates of other formats. Later updates to this document might certificates of other formats. Later updates to this document might
specify how to use certificates in other formats. specify how to use certificates in other formats.
This document defines a secure method to associate the certificate This document defines a secure method to associate the certificate
that is obtained from the TLS server with a domain name using DNS; that is obtained from the TLS server with a domain name using DNS;
the DNS information needs to be be protected by DNSSEC. Because the the DNS information needs to be be protected by DNSSEC. Because the
certificate association was retrieved based on a DNS query, the certificate association was retrieved based on a DNS query, the
domain name in the query is by definition associated with the domain name in the query is by definition associated with the
certificate. Note that this document does not cover how to associate certificate. Note that this document does not cover how to associate
certificates with domain names for application protocols that depend certificates with domain names for application protocols that depend
on SRV, NAPTR, and similar DNS resource records; it is expected that on SRV, NAPTR, and similar DNS resource records. It is expected that
later updates to this document might cover methods for making those future documents will cover methods for making those associations,
associations. and those documents may or may not need to update this one.
DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses
cryptographic keys and digital signatures to provide authentication cryptographic keys and digital signatures to provide authentication
of DNS data. Information that is retrieved from the DNS and that is of DNS data. Information that is retrieved from the DNS and that is
validated using DNSSEC is thereby proved to be the authoritative validated using DNSSEC is thereby proved to be the authoritative
data. The DNSSEC signature needs to be validated on all responses data. The DNSSEC signature needs to be validated on all responses
that use DNSSEC in order to assure the proof of origin of the data. that use DNSSEC in order to assure the proof of origin of the data.
This document does not specify how DNSSEC validation occurs because This document does not specify how DNSSEC validation occurs because
there are many different proposals for how a client might get there are many different proposals for how a client might get
skipping to change at page 8, line 35 skipping to change at page 8, line 35
A one-octet value, called "certificate usage", specifies the provided A one-octet value, called "certificate usage", specifies the provided
association that will be used to match the certificate presented in association that will be used to match the certificate presented in
the TLS handshake. This value is defined in a new IANA registry (see the TLS handshake. This value is defined in a new IANA registry (see
Section 7.2) in order to make it easier to add additional certificate Section 7.2) in order to make it easier to add additional certificate
usages in the future. The certificate usages defined in this usages in the future. The certificate usages defined in this
document are: document are:
0 -- Certificate usage 0 is used to specify a CA certificate, or 0 -- Certificate usage 0 is used to specify a CA certificate, or
the public key of such a certificate, that MUST be found in any of the public key of such a certificate, that MUST be found in any of
the PKIX certification paths for the end entity certificate given the PKIX certification paths for the end entity certificate given
by the server in TLS. This certifcate usage is sometimes referred by the server in TLS. This certificate usage is sometimes
to as "CA constraint" because it limits which CA can be used to referred to as "CA constraint" because it limits which CA can be
issue certificates for a given service on a host. The presented used to issue certificates for a given service on a host. The
certificate MUST pass PKIX certification path validation and a CA presented certificate MUST pass PKIX certification path validation
certificate that matches the TLSA record MUST be included as part and a CA certificate that matches the TLSA record MUST be included
of a valid certification path. Because this certifcate usage as part of a valid certification path. Because this certificate
allows both trust anchors and CA certificates, the certificate usage allows both trust anchors and CA certificates, the
might or might not have the basicConstraints extension present. certificate might or might not have the basicConstraints extension
present.
1 -- Certificate usage 1 is used to specify an end entity 1 -- Certificate usage 1 is used to specify an end entity
certificate, or the public key of such a certificate, that must be certificate, or the public key of such a certificate, that must be
matched with the end entity certificate given by the server in matched with the end entity certificate given by the server in
TLS. This certifcate usage is sometimes referred to as "service TLS. This certificate usage is sometimes referred to as "service
certificate constraint" because it limits which end entity certificate constraint" because it limits which end entity
certificate can be used by a given service on a host. The target certificate can be used by a given service on a host. The target
certificate MUST pass PKIX certification path validation and MUST certificate MUST pass PKIX certification path validation and MUST
match the TLSA record. match the TLSA record.
2 -- Certificate usage 2 is used to specify a certificate, or the 2 -- Certificate usage 2 is used to specify a certificate, or the
public key of such a certificate, that must be used as the trust public key of such a certificate, that must be used as the trust
anchor when validating the end entity certificate given by the anchor when validating the end entity certificate given by the
server in TLS. This certifcate usage is sometimes referred to as server in TLS. This certificate usage is sometimes referred to as
"trust anchor assertion" and allows a domain name administrator to "trust anchor assertion" and allows a domain name administrator to
specify a new trust anchor. For example, if the domain issues its specify a new trust anchor. For example, if the domain issues its
own certificates under its own CA that is not expected to be in own certificates under its own CA that is not expected to be in
the end users' collection of trust anchors. The target the end users' collection of trust anchors. The target
certificate MUST pass PKIX certification path validation, with any certificate MUST pass PKIX certification path validation, with any
certificate matching the TLSA record considered to be a trust certificate matching the TLSA record considered to be a trust
anchor for this certification path validation. anchor for this certification path validation.
3 -- Certificate usage 3 is used to specify a certificate, or the 3 -- Certificate usage 3 is used to specify a certificate, or the
public key of such a certificate, that must match the end entity public key of such a certificate, that must match the end entity
certificate given by the server in TLS. This certifcate usage is certificate given by the server in TLS. This certificate usage is
sometimes referred to as "domain-issued certificate" because it sometimes referred to as "domain-issued certificate" because it
allows for a domain name administrator to issue certificates for a allows for a domain name administrator to issue certificates for a
domain without involving a third-party CA. The target certificate domain without involving a third-party CA. The target certificate
MUST match the TLSA record. The difference between certificate MUST match the TLSA record. The difference between certificate
usage 1 and certificate usage 3 is that certificate usage 1 usage 1 and certificate usage 3 is that certificate usage 1
requires that the certificate pass PKIX validation, but PKIX requires that the certificate pass PKIX validation, but PKIX
validation is not tested for certificate usage 3. validation is not tested for certificate usage 3.
The certificate usages defined in this document explicitly only apply The certificate usages defined in this document explicitly only apply
to PKIX-formatted certificates in DER encoding [X.690]. If TLS to PKIX-formatted certificates in DER encoding [X.690]. If TLS
skipping to change at page 10, line 48 skipping to change at page 10, line 48
unsigned decimal integer. unsigned decimal integer.
o The selector field MUST be represented as an 8-bit unsigned o The selector field MUST be represented as an 8-bit unsigned
decimal integer. decimal integer.
o The matching type field MUST be represented as an 8-bit unsigned o The matching type field MUST be represented as an 8-bit unsigned
decimal integer. decimal integer.
o The certificate association data field MUST be represented as a o The certificate association data field MUST be represented as a
string of hexadecimal characters. Whitespace is allowed within string of hexadecimal characters. Whitespace is allowed within
the string of hexadecimal characters. the string of hexadecimal characters, as described in [RFC1035].
2.3. TLSA RR Examples 2.3. TLSA RR Examples
In the following examples, the domain name is formed using the rules In the following examples, the domain name is formed using the rules
in Section 3. in Section 3.
An example of a hashed (SHA-256) association of a PKIX CA An example of a hashed (SHA-256) association of a PKIX CA
certificate: certificate:
_443._tcp.www.example.com. IN TLSA ( _443._tcp.www.example.com. IN TLSA (
skipping to change at page 11, line 49 skipping to change at page 11, line 49
based service is assumed to exist is prepended with an underscore based service is assumed to exist is prepended with an underscore
character ("_") to become the left-most label in the prepared character ("_") to become the left-most label in the prepared
domain name. This number has no leading zeros. domain name. This number has no leading zeros.
2. The protocol name of the transport on which a TLS-based service 2. The protocol name of the transport on which a TLS-based service
is assumed to exist is prepended with an underscore character is assumed to exist is prepended with an underscore character
("_") to become the second left-most label in the prepared domain ("_") to become the second left-most label in the prepared domain
name. The transport names defined for this protocol are "tcp", name. The transport names defined for this protocol are "tcp",
"udp" and "sctp". "udp" and "sctp".
3. The domain name is appended to the result of step 2 to complete 3. The base domain name is appended to the result of step 2 to
the prepared domain name. complete the prepared domain name. The base domain name is the
fully-qualified DNS domain name [RFC1035] of the TLS server, with
the additional restriction that every label must meet the rules
of [RFC0952]. The latter restriction means that, if the query is
for an internationalized domain name, it must use the A-label
form as defined in [RFC5890].
For example, to request a TLSA resource record for an HTTP server For example, to request a TLSA resource record for an HTTP server
running TLS on port 443 at "www.example.com", running TLS on port 443 at "www.example.com",
"_443._tcp.www.example.com" is used in the request. To request a "_443._tcp.www.example.com" is used in the request. To request a
TLSA resource record for an SMTP server running the STARTTLS protocol TLSA resource record for an SMTP server running the STARTTLS protocol
on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
used. used.
4. Use of TLSA Records in TLS 4. Use of TLSA Records in TLS
skipping to change at page 13, line 15 skipping to change at page 13, line 20
o A TLSA RRset whose DNSSEC validation state is indeterminate or o A TLSA RRset whose DNSSEC validation state is indeterminate or
insecure cannot be used for TLS and MUST be considered unusable. insecure cannot be used for TLS and MUST be considered unusable.
Clients which validate the DNSSEC signatures themselves MUST use Clients which validate the DNSSEC signatures themselves MUST use
standard DNSSEC validation procedures. Clients that rely on another standard DNSSEC validation procedures. Clients that rely on another
entity to perform the DNSSEC signature validation MUST use a secure entity to perform the DNSSEC signature validation MUST use a secure
mechanism between themselves and the validator. Examples of secure mechanism between themselves and the validator. Examples of secure
transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931], transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931],
and IPsec [RFC6071]. Note that it is not sufficient to use secure and IPsec [RFC6071]. Note that it is not sufficient to use secure
transport to a DNS resolver that does not do DNSSEC signature transport to a DNS resolver that does not do DNSSEC signature
validation. validation. See Section 8.3 for more security considerations related
to external validators.
If a certificate association contains a certificate usage, selector, If a certificate association contains a certificate usage, selector,
or matching type that is not understood by the TLS client, that or matching type that is not understood by the TLS client, that
certificate association MUST be considered unusable. If the certificate association MUST be considered unusable. If the
comparison data for a certificate is malformed, the certificate comparison data for a certificate is malformed, the certificate
association MUST be considered unusable. association MUST be considered unusable.
If a certificate association contains a matching type or certificate If a certificate association contains a matching type or certificate
association data that uses a cryptographic algorithm that is association data that uses a cryptographic algorithm that is
considered too weak for the TLS client's policy, the certificate considered too weak for the TLS client's policy, the certificate
skipping to change at page 13, line 38 skipping to change at page 13, line 44
If an application receives zero usable certificate associations from If an application receives zero usable certificate associations from
a DNS request or from its cache, it processes TLS in the normal a DNS request or from its cache, it processes TLS in the normal
fashion without any input from the TLSA records. If an application fashion without any input from the TLSA records. If an application
receives one or more usable certificate associations, it attempts to receives one or more usable certificate associations, it attempts to
match each certificate association with the TLS server's end entity match each certificate association with the TLS server's end entity
certificate until a successful match is found. During the TLS certificate until a successful match is found. During the TLS
handshake, if none of the certificate associations matches the handshake, if none of the certificate associations matches the
certificate given by the TLS server, the TLS client MUST abort the certificate given by the TLS server, the TLS client MUST abort the
handshake. handshake.
An attacker who is able to divert a user to a server under his
control is also likely to be able to block DNS requests from the user
or DNS responses being sent to the user. Thus, in order to achieve
any security benefit from certificate usage 0 or 1, an application
that sends a request for TLSA records needs to get either a valid
signed response containing TLSA records or verification that the
domain is insecure or indeterminate. If a request for a TLSA record
does not meet one of those two criteria but the application continues
with the TLS handshake anyway, the application has gotten no benefit
from TLSA and should not make any internal or external indication
that TLSA was applied. If an application has a configuration setting
for turning on TLSA use, or has any indication that TLSA is in use
(regardless of whether or not this is configurable), that application
MUST not start a TLS connection or abort a TLS handshake if either of
the two criteria above are not met.
The application can perform the TLSA lookup before initiating the TLS The application can perform the TLSA lookup before initiating the TLS
handshake, or do it during the TLS handshake: the choice is up to the handshake, or do it during the TLS handshake: the choice is up to the
client. client.
5. TLSA and DANE Use Cases and Requirements 5. TLSA and DANE Use Cases and Requirements
The different types of certificate associations defined in TLSA are The different types of certificate associations defined in TLSA are
matched with various sections of [RFC6394]. The use cases from matched with various sections of [RFC6394]. The use cases from
Section 3 of [RFC6394] are covered in this document as follows: Section 3 of [RFC6394] are covered in this document as follows:
skipping to change at page 16, line 6 skipping to change at page 16, line 24
defined. At that time, this specification will be updated. defined. At that time, this specification will be updated.
7. IANA Considerations 7. IANA Considerations
IANA is requested to make the assignments in this section. IANA IANA is requested to make the assignments in this section. IANA
might also consider making a "DANE" section in the main IANA registry might also consider making a "DANE" section in the main IANA registry
to help developers find related registries that might be created in to help developers find related registries that might be created in
the future. the future.
In the following sections, "RFC Required" was chosen for TLSA In the following sections, "RFC Required" was chosen for TLSA
certficate usages and "Specification Required" for selectors and certificate usages and "Specification Required" for selectors and
matching types because of the amount of detail that is likely to be matching types because of the amount of detail that is likely to be
needed for implementers to correctly implement new certificate usages needed for implementers to correctly implement new certificate usages
as compared to new selectors and matching types. as compared to new selectors and matching types.
7.1. TLSA RRtype 7.1. TLSA RRtype
This document uses a new DNS RR type, TLSA, whose value (52) was This document uses a new DNS RR type, TLSA, whose value (52) was
allocated by IANA from the Resource Record (RR) TYPEs subregistry of allocated by IANA from the Resource Record (RR) TYPEs subregistry of
the Domain Name System (DNS) Parameters registry. the Domain Name System (DNS) Parameters registry.
skipping to change at page 18, line 15 skipping to change at page 18, line 33
uses with the client. The client, seeing the proxy's new certificate uses with the client. The client, seeing the proxy's new certificate
for the supposed destination will not set up a TLS session. for the supposed destination will not set up a TLS session.
Client treatment of any information included in the certificate trust Client treatment of any information included in the certificate trust
anchor is a matter of local policy. This specification does not anchor is a matter of local policy. This specification does not
mandate that such information be inspected or validated by the mandate that such information be inspected or validated by the
server's domain name administrator. server's domain name administrator.
If a server's certificate is revoked, or if an intermediate CA in a If a server's certificate is revoked, or if an intermediate CA in a
chain between the end entity and a trust anchor has its certificate chain between the end entity and a trust anchor has its certificate
revoked, a TLSA record with a certificate type of 2 that matches the revoked, a TLSA record with a certificate usage of 2 that matches the
revoked certificate would in essence override the revocation because revoked certificate would in essence override the revocation because
the client would treat that revoked certificate as a trust anchor and the client would treat that revoked certificate as a trust anchor and
thus not check its revocation status. Because of this, domain thus not check its revocation status. Because of this, domain
administrators need to be responsible for being sure that the key or administrators need to be responsible for being sure that the key or
certificate used in TLSA records with a certificate type of 2 are in certificate used in TLSA records with a certificate usage of 2 are in
fact able to be used as reliable trust anchors. fact able to be used as reliable trust anchors.
Certificates that are delivered in TLSA with certificate usage 2 Certificates that are delivered in TLSA with certificate usage 2
fundamentally change the way the TLS server's end entity certificate fundamentally change the way the TLS server's end entity certificate
is evaluated. For example, the server's certificate might chain to is evaluated. For example, the server's certificate might chain to
an existing CA through an intermediate CA that has certain policy an existing CA through an intermediate CA that has certain policy
restrictions, and the certificate would not pass those restrictions restrictions, and the certificate would not pass those restrictions
and thus normally be rejected. That intermediate CA could issue and thus normally be rejected. That intermediate CA could issue
itself a new certificate without the policy restrictions and tell its itself a new certificate without the policy restrictions and tell its
customers to use that certificate with certificate usage 2. This in customers to use that certificate with certificate usage 2. This in
essence allows an intermediate CA to be come a trust anchor for essence allows an intermediate CA to be come a trust anchor for
certificates that the end user might have expected to chain to an certificates that the end user might have expected to chain to an
existing trust anchor. existing trust anchor.
If an administrator wishes to stop using a TLSA record, the If an administrator wishes to stop using a TLSA record, the
administrator can simply remove it from the DNS. Normal clients will administrator can simply remove it from the DNS. Normal clients will
stop using the TLSA record after the TTL has expired. Replay attacks stop using the TLSA record after the TTL has expired. Replay attacks
against the TLSA record are not possible after the expiration date on against the TLSA record are not possible after the expiration date on
the RRsig of the TLSA record that was removed. the RRsig of the TLSA record that was removed.
The client's full trust of a certificate retrieved from a TLSA record Generators of TLSA records should be aware that the client's full
with a certificate usage of 2 or 3 may be a matter of local policy. trust of a certificate association retrieved from a TLSA record may
While such trust is limited to the specific domain name for which the be a matter of local policy. While such trust is limited to the
TLSA query was made, local policy may deny the trust or further specific domain name, protocol, and port for which the TLSA query was
restrict the conditions under which that trust is permitted. made, local policy may deny to trust the certificate (such as due to
weak cryptography), the same as it is with PKIX trust anchors.
8.1. Comparing DANE to Public CAs 8.1. Comparing DANE to Public CAs
Comparing the risk for current common TLS clients against the risk As stated above, the security of the DNS RRtype described in this
for DANE clients using external DNSSEC validators is difficult. The document relies on the security of DNSSEC to verify that the TLSA
common model for TLS clients is that they trust a large number of record has not been altered. This section describes where the
commercial CAs who can issue certificates for any domain name. A security of public CAs and the security of TLSA are similar and
DANE-aware TLS client that that is trusting an external DNSSEC different. This section applies equally to other security-related
validator is as vulnerable as a DANE-unaware TLS client because any DNS RRtypes such as keys for IPsec and SSH.
CA or any external validator can assert any key for any domain.
If it is less likely that a user will hear about its trusted DNSSEC DNSSEC forms certificates (the binding of an identity to a key) by
validators being compromised that it is of a public CA being combining a DNSKEY, DS, or DLV resource record with an associated
compromised, a client with an external validator could be worse off RRSIG record. These records then form a signing chain extending from
than a current TLS client that is depending on the current public the client's trust anchors to the RR of interest.
CAs. A counter-argument to this is a single external DNSSEC
validator is a much less interesting target than a public CA,
particularly if many clients use their own DNSSEC validators or
validators that reside on the computer on which they are running.
Current public CAs are assumed to have better defenses than current Although the DNSSEC protocol does not enforce it, DNSKEYs are often
DNSSEC validators, but that perception cannot be proven one way or marked with a SEP flag indicating whether the key is a Zone Signing
another. Similarly, if DNSSEC validation becomes more common after Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the
the release of this document, it cannot be predicted whether or not zone (including DS and DLV records), and KSKs protect ZSK DNSKEY
that will increase the level of security of DNSSEC validators more or records. This allows KSKs to be stored offline.
less than the security of public CAs. Thus, it is difficult to
foresee which system has a higher risk. The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to
authenticate keys wrapped in PKIX certificates for a particular host
name, protocol, and port.
With the exception of the DLV RRtype, all of these certificates
constrain the keys they identify to names that are within the zone
signing the certificate. In order for a domain's DLV resource
records to be honored, the domain must be configured as a DLV domain,
and the domain's DNSKEYs must be configured as trust anchors or be
authentic [RFC5074].
8.1.1. Risk of Key Compromise
The risk that a given certificate that has a valid signing chain is
fake is related to the number of keys that can contribute to the
validation of the certificate, the quality of protection each key
receives, the value of each key to an attacker, and the value of
falsifying the certificate.
DNSSEC allows any set of domains to be configured as trust anchors
and/or DLVs, but most clients are likely to use the root zone as its
only trust anchor. Also, because a given DNSKEY can only sign
resource records for that zone, the number of keys capable of
compromising a given TLSA resource record is limited to the number of
zones between the TLSA resource record and the nearest trust anchor,
plus any configured DLV domains. Typically, this will be six keys,
half of which will be KSKs.
PKIX only describes how to validate a certificate based on a client-
chosen set of trust anchors, but says nothing about how many trust
anchors to use or how they should be constrained. As currently
deployed, most PKIX clients use a large number of trust anchors
provided with the client or operating system software. These trust
anchors are selected carefully, but with a desire for broad
interoperability. The trust anchors and CA certificates for public
CAs rarely have name constraints applied.
A combination of technical protections, process controls, and
personnel experience contribute to the quality of security that keys
receive.
o The security surrounding DNSSEC DNSKEYs varies significantly. The
KSK/ZSK split allows the KSK to be stored offline and protected
more carefully than the ZSK, but not all domains do so. The
security applied to a zone's DNSKEYs should be proportional to the
value of the domain, but that is difficult to estimate. For
example, the root DNSKEY has protections and controls comparable
to or exceeding that of public CAs. On the other end of the
spectrum, small domains might provide no more protection to their
keys than they do to their other data.
o The security surrounding public CAs also varies. However, due to
financial incentives and standards imposed by clients for
acceptance into their trust anchor stores, CAs generally employ
security experts and protect their keys carefully, though highly-
public compromises have occurred.
8.1.2. Impact of Key Compromise
The impact of a key compromise differs significantly between the two
models.
o DNSKEYs are inherently limited in what they can sign, so a
compromise of the DNSKEY for "example.com" provides no avenue of
attack against "example.org". Even the impact of a compromise of
.com's DNSKEY, while considerable, would be limited to .com
domains. Only the compromise of the root DNSKEY would have the
equivalent impact of an unconstrained public CA.
o Public CAs are not typically constrained in what names they can
sign, and therefore a compromise of even one CA allows the
attacker to generate a certificate for any name in the DNS. A
domain holder can get a certificate from any willing CA, or even
multiple CAs simultaneously, making it impossible for a client to
determine whether the certificate it is validating is legitimate
or fraudulent.
Because a TLS certificate association is constrained to its
associated name, protocol, and port, the PKIX certificate is
similarly constrained, even if its public CAs signing the certificate
(if any) are not.
8.1.3. Detection of Key Compromise
If a key is compromised, rapid and reliable detection is important in
order to limit the impact of the compromise. In this regard, neither
model prevents an attacker from near-invisibly attacking their
victim, provided that the necessary keys are compromised.
If a public CA is compromised, only the victim will see the
fraudulent certificate, as there is typically no publicly-accessible
directory of all the certificates issued by a CA that can be
inspected. DNS resource records are typically published publicly.
However, the attacker could also allow the uncompromised records to
be published to the Internet as usual but provide a compromised DNS
view to the victim to achieve the same effect.
8.1.4. Spoofing Hostnames
Some CAs implement technical controls to ensure that certificates are
not issued to domains that with names similar to popular & prone-to-
attack domains. Of course, an attacker can attempt to circumvent
this restriction by finding a CA willing to issue the certificate
anyway. However, by using DNSSEC and TLSA, the attacker can
circumvent this check completely.
8.2. DNS Caching 8.2. DNS Caching
Implementations of this protocol rely heavily on the DNS, and are Implementations of this protocol rely heavily on the DNS, and are
thus prone to security attacks based on the deliberate mis- thus prone to security attacks based on the deliberate mis-
association of TLSA records and DNS names. Implementations need to association of TLSA records and DNS names. Implementations need to
be cautious in assuming the continuing validity of an assocation be cautious in assuming the continuing validity of an association
between a TLSA record and a DNS name. between a TLSA record and a DNS name.
In particular, implementations SHOULD rely on their DNS resolver for In particular, implementations SHOULD rely on their DNS resolver for
confirmation of an association between a TLSA record and a DNS name, confirmation of an association between a TLSA record and a DNS name,
rather than caching the result of previous domain name lookups. Many rather than caching the result of previous domain name lookups. Many
platforms already can cache domain name lookups locally when platforms already can cache domain name lookups locally when
appropriate, and they SHOULD be configured to do so. It is proper appropriate, and they SHOULD be configured to do so. It is proper
for these lookups to be cached, however, only when the TTL (Time To for these lookups to be cached, however, only when the TTL (Time To
Live) information reported by the DNS makes it likely that the cached Live) information reported by the DNS makes it likely that the cached
information will remain useful. information will remain useful.
If implementations cache the results of domain name lookups in order If implementations cache the results of domain name lookups in order
to achieve a performance improvement, they MUST observe the TTL to achieve a performance improvement, they MUST observe the TTL
information reported by DNS. Implementations that fail to follow information reported by DNS. Implementations that fail to follow
this rule could be spoofed or have access denied when a previously- this rule could be spoofed or have access denied when a previously-
accessed server's TLSA record changes, such as during a certificate accessed server's TLSA record changes, such as during a certificate
rollover. rollover.
8.3. External DNSSEC Validators
Due to a lack of DNSSEC support in the most commonly-deployed stub
resolvers today, some ISPs have begun checking DNSSEC in the
recursive resolvers they provide to their customers, setting the AD
flag as appropriate. DNSSEC-aware clients could use that data,
ignoring the fact that the DNSSEC data has been validated externally.
Because there is typically no authentication of the recursive
resolver or integrity protection of the the data and AD flag between
the client and the recursive resolver, this can be trivially spoofed
by an attacker.
However, even with secure communications between a host and the
external validating resolver, there is a risk that the external
validator could become compromised. Nothing prevents a compromised
external DNSSEC validator from claiming that all the records it
provides are secure, even if the data is falsified, unless the client
checks the DNSSEC data itself (rendering the the external validator
unnecessary).
For this reason, it is RECOMMENDED that DNSSEC validation always be
performed on-host, even when a secure path to an external validator
is available.
9. Acknowledgements 9. Acknowledgements
Many of the ideas in this document have been discussed over many Many of the ideas in this document have been discussed over many
years. More recently, the ideas have been discussed by the authors years. More recently, the ideas have been discussed by the authors
and others in a more focused fashion. In particular, some of the and others in a more focused fashion. In particular, some of the
ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff
Hodges, Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Hodges, Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam
Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit, Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit,
Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh
Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John
skipping to change at page 21, line 13 skipping to change at page 24, line 10
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[STD13] Mockapetris, P., "Domain Name System", STD 13, [STD13] Mockapetris, P., "Domain Name System", STD 13,
November 1987. November 1987.
10.2. Informative References 10.2. Informative References
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
skipping to change at page 21, line 39 skipping to change at page 24, line 39
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
January 2006. January 2006.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006. RFC 4641, September 2006.
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
November 2007.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
February 2011. February 2011.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
 End of changes. 32 change blocks. 
85 lines changed or deleted 247 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/