draft-ietf-dane-protocol-18.txt   draft-ietf-dane-protocol-19.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: September 10, 2012 Kirei AB Expires: October 13, 2012 Kirei AB
March 9, 2012 April 11, 2012
The DNS-Based Authentication of Named Entities (DANE) Protocol for The DNS-Based Authentication of Named Entities (DANE) Protocol for
Transport Layer Security (TLS) Transport Layer Security (TLS)
draft-ietf-dane-protocol-18 draft-ietf-dane-protocol-19
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
administrator of a domain name to certify 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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 10, 2012. This Internet-Draft will expire on October 13, 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 2, line 14 skipping to change at page 2, line 14
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background of the Problem . . . . . . . . . . . . . . . . 4 1.1. Background of the Problem . . . . . . . . . . . . . . . . 4
1.2. Securing the Association with a Server's Certificate . . . 5 1.2. Securing the Association with a Server's Certificate . . . 5
1.3. Method For Securing Certificate Associations . . . . . . . 6 1.3. Method For Securing Certificate Associations . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 7 2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 7
2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 7 2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 7
2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 7 2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 8
2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 8 2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 9
2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 9 2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 9
2.1.4. The Certificate Association Data Field . . . . . . . . 9 2.1.4. The Certificate Association Data Field . . . . . . . . 10
2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 9 2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 10
2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 10 2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 10
3. Domain Names for TLS Certificate Associations . . . . . . . . 10 3. Domain Names for TLS Certificate Associations . . . . . . . . 11
4. Use of TLSA Records in TLS . . . . . . . . . . . . . . . . . . 11 4. Use of TLSA Records in TLS . . . . . . . . . . . . . . . . . . 11
5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 12 5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 13
6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 14 6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 15 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 16
7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 15 7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Comparing DANE to Public CAs . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Operational Considerations for Deploying TLSA Appendix A. Operational Considerations for Deploying TLSA
Records . . . . . . . . . . . . . . . . . . . . . . . 19 Records . . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 20 A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 21
A.1.1. Ambiguities and Corner Cases When TLS Clients A.1.1. Ambiguities and Corner Cases When TLS Clients
Build Trust Chains . . . . . . . . . . . . . . . . . . 20 Build Trust Chains . . . . . . . . . . . . . . . . . . 22
A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 21 A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 23
A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 23 A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 24
A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 23 A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 24
A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 25 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 27
A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 26 A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 27
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 26 Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 28
B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 26 B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 28
B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 28 B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 29
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 31
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
1.1. Background of the Problem 1.1. Background of the Problem
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 privacy over the Internet, using encryption. communications security over the Internet, using 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 published keys that they use. If secret keys are revealed, or if public keys
keys can be replaced by bogus keys, these systems provide little or can be replaced by bogus keys, these systems provide little or no
no security. 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 the key is used by, and this combination is digitally service that uses the key, and this combination is digitally signed
signed by another key. Having a certificate for a key is only by another key. Having a certificate for a key is only helpful if
helpful if you trust the other key that signed the certificate. If one trusts the other key that signed the certificate. If that other
that other key was itself revealed or substituted, then its signature key was itself revealed or substituted, then its signature is
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
called "Certification Authorities" (CAs). CAs protect their secret called "Certification Authorities" (CAs). CAs protect their secret
key vigorously, while supplying their public key to the software key vigorously, while supplying their public key to the software
vendors who build TLS clients. They then sign certificates, and vendors who build TLS clients. They then sign certificates, and
supply those to TLS servers. TLS client software uses a set of these supply those to TLS servers. TLS client software uses a set of these
CA keys as "trust anchors" to validate the signatures on certificates CA keys as "trust anchors" to validate the signatures on certificates
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.
This solution has gradually broken down because some CAs have become The public CA model upon which TLS has depended is fundamentally
untrustworthy. A single trusted CA that betrays its trust, either vulnerable because it allows any of these CAs to issue a certificate
voluntarily or by providing less-than-vigorous protection for its for any domain name. A single trusted CA that betrays its trust,
secrets and capabilities, can compromise any other certificate that either voluntarily or by providing less-than-vigorous protection for
TLS uses by signing a replacement certificate that contains a bogus its secrets and capabilities, can compromise any other certificate
key. Several real-world occurrances that have exploited such CAs for that TLS uses, by signing a replacement certificate that contains a
subversion of major web sites (presumably to abet wiretapping and bogus key. Recent experiences with compromises of CAs or their
large-scale fraud) have brought TLS's CA model into disrepute. trusted partners have lead to very serious security problems, such as
the subversion of major 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
associated with the parent of that domain name; for example, the keys associated with the parent of that domain name; for example, the keys
for "example.com" can only be signed by the keys for "com", and the for "example.com" can only be signed by the keys for "com", and the
keys for "com" can only be signed by the DNS root. This prevents an keys for "com" can only be signed by the DNS root. This prevents an
untrustworthy signer from compromising anyone's keys except those in untrustworthy signer from compromising anyone's keys except those in
their own subdomains. Like TLS, DNSSEC relies on public keys that their own subdomains. Like TLS, DNSSEC relies on public keys that
come built into the DNSSEC client software, but these keys come only come built into the DNSSEC client software, but these keys come only
from a single root domain rather than from a multiplicity of CAs. from a single root domain rather than from a multiplicity of CAs.
DNS-Based Authentication of Named Entities (DANE) offers the option
to use the DNSSEC infrastructure to store and sign keys and
certificates that are used by TLS. DANE is envisioned as a
preferable basis for binding public keys to DNS names, because the
entities that vouch for the binding of public key data to DNS names
are the same entities responsible for managing the DNS names in
question. While the resulting system still has residual security
vulnerabilities, it restricts the scope of assertions that can be
made by any entity, consistent with the naming scope imposed by the
DNS hierarchy. As a result, DANE embodies the security "principle of
least privilege" that is lacking in the current public CA model.
1.2. Securing the Association with a Server's Certificate 1.2. Securing the Association with a Server's 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. It looks up the server's name using the DNS to get Internet server. It looks up the server's name using the DNS to get an
Protocol (IP) address associated with the name. It then begins a Internet Protocol (IP) address associated with the name. It then
connection to a client-chosen port at that address, and sends an begins a connection to a client-chosen port at that address, and
initial message there. However, the client does not yet know whether sends an initial message there. However, the client does not yet
an adversary is intercepting and/or altering its communication before know whether an adversary is intercepting and/or altering its
it reaches the TLS server. It does not even know whether the real communication before it reaches the TLS server. It does not even
TLS server associated with that domain name has ever received its know whether the real TLS server associated with that domain name has
initial messages. ever received its initial 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
server. Currently, the client must extract the domain name from the server. Currently, the client must extract the domain name from the
certificate and must successfully validate the certificate, including certificate and must successfully validate the certificate, including
chaining to a trust anchor. chaining to a trust anchor.
There is a different way to authenticate the association of the There is a different way to authenticate the association of the
server's certificate with the intended domain name without trusting server's certificate with the intended domain name without trusting
an external CA. Given that the DNS administrator for a domain name an external CA. Given that the DNS administrator for a domain name
is authorized to give identifying information about the zone, it is authorized to give identifying information about the zone, it
makes sense to allow that administrator to also make an authoritative makes sense to allow that administrator to also make an authoritative
binding between the domain name and a certificate that might be used binding between the domain name and a certificate that might be used
by a host at that domain name. The easiest way to do this is to use by a host at that domain name. The easiest way to do this is to use
the DNS, securing the binding with DNSSEC. the DNS, securing the binding with DNSSEC.
There are many use cases for such functionality. [RFC6394] lists the There are many use cases for such functionality. [RFC6394] lists the
ones that the DNS RRtype in this document are meant to apply. ones to which the DNS RRtype in this document apply. [RFC6394] also
[RFC6394] also lists many requirements, most of which this document lists many requirements, most of which this document is believed to
is believed to meet. Section 5 covers the applicability of this meet. Section 5 covers the applicability of this document to the use
document to the use cases in detail. cases in detail.
This document applies to both TLS [RFC5246] and DTLS [RFC6347]. In This document applies to both TLS [RFC5246] and DTLS [RFC6347]. In
order to make the document more readable, it mostly only talks about order to make the document more readable, it mostly only talks about
"TLS", but in all cases, it means "TLS or DTLS". This document only "TLS", but in all cases, it means "TLS or DTLS". This document only
relates to securely associating certificates for TLS and DTLS with relates to securely associating certificates for TLS and DTLS with
host names; other security protocols and other forms of host names; other security protocols and other forms of
identification of TLS servers (such as IP addresses) are handled in identification of TLS servers (such as IP addresses) are handled in
other documents. For example, keys for IPsec are covered in other documents. For example, keys for IPsec are covered in
[RFC4025] and keys for SSH are covered in [RFC4255]. [RFC4025] and keys for SSH are covered in [RFC4255].
1.3. Method For Securing Certificate Associations 1.3. Method For Securing Certificate Associations
A certificate association is formed from a piece of information A certificate association is formed from a piece of information
identifying a certificate (such as the contents of the certificate or identifying a certificate and the domain name where the data is
a trust anchor to which the certificate chains) and the domain name found. The combination of a trust anchor and a domain name can also
where the data is found. This document only applies to PKIX be a certificate association.
[RFC5280] certificates, not certificates of other formats.
A DNS query can return multiple certificate associations, such as in A DNS query can return multiple certificate associations, such as in
the case of different server software on a single host using the case of a server is changing from one certificate to another.
different certificates, or in the case that a server is changing from
one certificate to another. This document only applies to PKIX [RFC5280] certificates, not
certificates of 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. certificate.
DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses
[RFC4034], and [RFC4035]), uses cryptographic keys and digital cryptographic keys and digital signatures to provide authentication
signatures to provide authentication of DNS data. Information that of DNS data. Information that is retrieved from the DNS and that is
is retrieved from the DNS and that is validated using DNSSEC is validated using DNSSEC is thereby proved to be the authoritative
thereby proved to be the authoritative data. The DNSSEC signature data. The DNSSEC signature needs to be validated on all responses
MUST be validated on all responses that use DNSSEC in order to assure that use DNSSEC in order to assure the proof of origin of the data.
the proof of origin of the data. This document does not specify how
DNSSEC validation occurs because there are many different proposals
for how a client might get validated DNSSEC results.
This document only relates to securely getting the DNS information This document does not specify how DNSSEC validation occurs because
for the certificate association using DNSSEC; other secure DNS there are many different proposals for how a client might get
validated DNSSEC results, such as from a DNSSEC-aware resolver that
is coded in the application, from a trusted DNSSEC resolver on the
machine on which the application is running, or from a trusted DNSSEC
resolver with which the application is communicating over an
authenticated and integrity-protected channel or network. This is
described in more detail in Section 7 of [RFC4033].
This document only relates to getting the DNS information for the
certificate association securely using DNSSEC; other secure DNS
mechanisms are out of scope. mechanisms are out of scope.
1.4. Terminology 1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document also makes use of standard PKIX, DNSSEC, and TLS This document also makes use of standard PKIX, DNSSEC, TLS, and DNS
terminology. See [RFC5280], [RFC4033], and [RFC5246] respectively, terminology. See [RFC5280], [RFC4033], [RFC5246], and [STD13]
for these terms. In addition, terms related to TLS-protected respectively, for these terms. In addition, terms related to TLS-
application services and DNS names are taken from [RFC6125]. protected application services and DNS names are taken from
[RFC6125].
2. The TLSA Resource Record 2. The TLSA Resource Record
The TLSA DNS resource record (RR) is used to associate a certificate The TLSA DNS resource record (RR) is used to associate a certificate
with the domain name where the record is found. The semantics of how with the domain name where the record is found. The semantics of how
the TLSA RR is interpreted are given later in this document. the TLSA RR is interpreted are given later in this document.
The type value for the TLSA RR type is TBD. The type value for the TLSA RR type is defined in Section 7.1.
The TLSA RR is class independent. The TLSA RR is class independent.
The TLSA RR has no special TTL requirements. The TLSA RR has no special TTL requirements.
2.1. TLSA RDATA Wire Format 2.1. TLSA RDATA Wire Format
The RDATA for a TLSA RR consists of a one octet usage type field, a The RDATA for a TLSA RR consists of a one octet usage type field, a
one octet selector field, a one octet matching type field and the one octet selector field, a one octet matching type field and the
certificate association data field. certificate association data field.
skipping to change at page 7, line 37 skipping to change at page 8, line 18
| Usage | Selector | Matching Type | / | Usage | Selector | Matching Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ / / /
/ Certificate Association Data / / Certificate Association Data /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1. The Certificate Usage Field 2.1.1. The Certificate Usage Field
A one-octet value, called "certificate usage" or just "usage", A one-octet value, called "certificate usage" or just "usage",
specifying the provided association that will be used to match the specifies the provided association that will be used to match the
target certificate from the TLS handshake. This value is defined in target certificate from the TLS handshake. This value is defined in
a new IANA registry (see Section 7.2) in order to make it easier to a new IANA registry (see Section 7.2) in order to make it easier to
add additional certificate usages in the future. The usages defined add additional certificate usages in the future. The usages defined
in this document are: in this 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 usage is sometimes referred to as "CA by the server in TLS. This usage is sometimes referred to as "CA
constraint" because it limits which CA can be used to issue constraint" because it limits which CA can be used to issue
certificates for a given service on a host. The target certificates for a given service on a host. The target
certificate MUST pass PKIX certification path validation and a CA certificate MUST pass PKIX certification path validation and a CA
certificate that matches the TLSA record MUST be included as part certificate that matches the TLSA record MUST be included as part
of a valid certification path. of a valid certification path. Because this usage allows both
trust anchors and CA certificates, the 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 usage is sometimes referred to as "service certificate TLS. This usage is sometimes referred to as "service certificate
constraint" because it limits which end entity certificate may be constraint" because it limits which end entity certificate can be
used by a given service on a host. The target certificate MUST used by a given service on a host. The target certificate MUST
pass PKIX certification path validation and MUST match the TLSA pass PKIX certification path validation and MUST match the TLSA
record. 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 usage is sometimes referred to as "trust server in TLS. This usage is sometimes referred to as "trust
anchor assertion" and allows a domain name administrator to 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 usage is sometimes certificate given by the server in TLS. This usage is sometimes
referred to as "domain-issued certificate" because it allows for a referred to as "domain-issued certificate" because it allows for a
skipping to change at page 8, line 46 skipping to change at page 9, line 27
tested for certificate usage 3. 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. If TLS allows other to PKIX-formatted certificates in DER encoding. If TLS allows other
formats later, or if extensions to this RRtype are made that accept formats later, or if extensions to this RRtype are made that accept
other formats for certificates, those certificates will need their other formats for certificates, those certificates will need their
own certificate usage values. own certificate usage values.
2.1.2. The Selector Field 2.1.2. The Selector Field
A one-octet value, called "selector", specifying which part of the A one-octet value, called "selector", specifies which part of the TLS
TLS certificate presented by the server will be matched against the certificate presented by the server will be matched against the
association data. This value is defined in a new IANA registry (see association data. This value is defined in a new IANA registry (see
Section 7.3. The selectors defined in this document are: Section 7.3. The selectors defined in this document are:
0 -- Full certificate 0 -- Full certificate
1 -- SubjectPublicKeyInfo 1 -- SubjectPublicKeyInfo
The SubjectPublicKeyInfo is a binary structure defined in [RFC5280].
(Note that the use of "selector" in this document is completely
unrelated to the use of "selector" in DKIM [RFC6376].)
2.1.3. The Matching Type Field 2.1.3. The Matching Type Field
A one-octet value, called "matching type", specifying how the A one-octet value, called "matching type", specifies how the
certificate association is presented. This value is defined in a new certificate association is presented. This value is defined in a new
IANA registry (see Section 7.4). The types defined in this document IANA registry (see Section 7.4). The types defined in this document
are: are:
0 -- Exact match on selected content 0 -- Exact match on selected content
1 -- SHA-256 hash of selected content [RFC6234] 1 -- SHA-256 hash of selected content [RFC6234]
2 -- SHA-512 hash of selected content [RFC6234] 2 -- SHA-512 hash of selected content [RFC6234]
If the TLSA record's matching type is a hash, the record SHOULD use If the TLSA record's matching type is a hash, having the record use
the same hash algorithm that was used in the signature in the the same hash algorithm that was used in the signature in the
certificate. This will assist clients that support a small number of certificate (if possible) will assist clients that support a small
hash algorithms. number of hash algorithms.
2.1.4. The Certificate Association Data Field 2.1.4. The Certificate Association Data Field
The "certificate association data" to be matched. This field The "certificate association data" to be matched. This field
contains the data to be matched. These bytes are either raw data contains the data to be matched. These bytes are either raw data
(that is, the full certificate or its SubjectPublicKeyInfo, depending (that is, the full certificate or its SubjectPublicKeyInfo, depending
on the selector) for matching type 0, or the hash of the raw data for on the selector) for matching type 0, or the hash of the raw data for
matching types 1 and 2. The data refers to the certificate in the matching types 1 and 2. The data refers to the certificate in the
association, not to the TLS ASN.1 Certificate object. association, not to the TLS ASN.1 Certificate object.
2.2. TLSA RR Presentation Format 2.2. TLSA RR Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
o The certificate usage field MUST be represented as an unsigned o The certificate usage field MUST be represented as an 8-bit
decimal integer. unsigned decimal integer.
o The selector field MUST be represented as an unsigned decimal o The selector field MUST be represented as an 8-bit unsigned
integer. decimal integer.
o The matching type field MUST be represented as an unsigned decimal o The matching type field MUST be represented as an 8-bit unsigned
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.
2.3. TLSA RR Examples 2.3. TLSA RR Examples
In the following examples, the domain name is formed using the rules
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 (
0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
7983a1d16e8a410e4561cb106618e971 ) 7983a1d16e8a410e4561cb106618e971 )
An example of a hashed (SHA-512) subject public key association of a An example of a hashed (SHA-512) subject public key association of a
PKIX end entity certificate: PKIX end entity certificate:
skipping to change at page 10, line 50 skipping to change at page 11, line 38
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 domain name is appended to the result of step 2 to complete
the prepared domain name. the prepared domain name.
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", you would use running TLS on port 443 at "www.example.com",
"_443._tcp.www.example.com" in the request. To request a TLSA "_443._tcp.www.example.com" is used in the request. To request a
resource record for an SMTP server running the STARTTLS protocol on TLSA resource record for an SMTP server running the STARTTLS protocol
port 25 at "mail.example.com", you would use on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
"_25._tcp.mail.example.com". used.
4. Use of TLSA Records in TLS 4. Use of TLSA Records in TLS
Section 2.1 of this document defines the mandatory matching rules for Section 2.1 of this document defines the mandatory matching rules for
the data from the TLSA certificate associations and the certificates the data from the TLSA certificate associations and the certificates
received from the TLS server. received from the TLS server.
The TLS session that is to be set up MUST be for the specific port The TLS session that is to be set up MUST be for the specific port
number and transport name that was given in the TLSA query. number and transport name that was given in the TLSA query.
Some specifications for applications that run under TLS, such as Some specifications for applications that run over TLS, such as
[RFC2818] for HTTP, require the server's certificate to have a domain [RFC2818] for HTTP, require the server's certificate to have a domain
name that matches the host name expected by the client. Some name that matches the host name expected by the client. Some
specifications such as [RFC6125] detail how to match the identity specifications such as [RFC6125] detail how to match the identity
given in a PKIX certificate with those expected by the user. given in a PKIX certificate with those expected by the user.
An implementation of this protocol makes a DNS query for TLSA An implementation of this protocol makes a DNS query for TLSA
records, validates these records using DNSSEC, and uses the resulting records, validates these records using DNSSEC, and uses the resulting
TLSA records and validation status to modify its responses to the TLS TLSA records and validation status to modify its responses to the TLS
server. server.
If a host is using TLSA usage type 2 for its certifcate, the If a TLSA record has usage type 2 for the certifcate, the
corresponding TLS server SHOULD send the certificate that is corresponding TLS server SHOULD send the certificate that is
referenced just like it currently sends intermediate certificates. referenced just like it currently sends intermediate certificates.
Determining whether a TLSA RRset can be used depends on the DNSSEC Determining whether a TLSA RRset can be used MUST be based on the
validation state (as defined in [RFC4033]). DNSSEC validation state (as defined in [RFC4033]).
o A TLSA RRset whose DNSSEC validation state is secure MUST be used o A TLSA RRset whose DNSSEC validation state is secure MUST be used
as a certificate association for TLS unless a local policy would as a certificate association for TLS unless a local policy would
prohibit the use of the specific certificate association in the prohibit the use of the specific certificate association in the
secure TLSA RRset. secure TLSA RRset.
o If the DNSSEC validation state on the response to the request for o If the DNSSEC validation state on the response to the request for
the TLSA RRset is bogus, this MUST cause TLS not to be started or, the TLSA RRset is bogus, this MUST cause TLS not to be started or,
if the TLS negotiation is already in progress, MUST cause the if the TLS negotiation is already in progress, MUST cause the
connection to be aborted. connection to be aborted.
skipping to change at page 12, line 19 skipping to change at page 13, line 8
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
association MUST be marked as unusable. association MUST be considered unusable.
If an application receives zero usable certificate associations, it If an application receives zero usable certificate associations from
processes TLS in the normal fashion without any input from the TLSA a DNS request or from its cache, it processes TLS in the normal
records. If an application receives one or more usable certificate fashion without any input from the TLSA records. If an application
associations, it attempts to match each certificate association with receives one or more usable certificate associations, it attempts to
the TLS server's end entity certificate until a successful match is match each certificate association with the TLS server's end entity
found. certificate until a successful match is found. During the TLS
handshake, if none of the certificate associations matches the
certificate given by the TLS server, the TLS client MUST abort the
handshake.
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:
3.1 CA Constraints -- Implemented using certificate usage 0. 3.1 CA Constraints -- Implemented using certificate usage 0.
3.2 Certificate Constraints -- Implemented using certificate usage 3.2 Certificate Constraints -- Implemented using certificate usage
skipping to change at page 13, line 12 skipping to change at page 14, line 5
service name and port number prefixed to the host name (see service name and port number prefixed to the host name (see
Section 3). Section 3).
No Downgrade -- Section 4 specifies the conditions under which a No Downgrade -- Section 4 specifies the conditions under which a
client can process and act upon TLSA records. Specifically, if client can process and act upon TLSA records. Specifically, if
the DNSSEC status for the TLSA resource record set is determined the DNSSEC status for the TLSA resource record set is determined
to be bogus, the TLS connection (if started) will fail. to be bogus, the TLS connection (if started) will fail.
Encapsulation -- Covered in the TLSA response semantics. Encapsulation -- Covered in the TLSA response semantics.
Predictability -- The appendixes of this specification provide Predictability -- The appendices of this specification provide
operational considerations and implementation guidance in order to operational considerations and implementation guidance in order to
enable application developers to form a consistent interpretation enable application developers to form a consistent interpretation
of the recommended DANE client behavior. of the recommended DANE client behavior.
Opportunistic Security -- If a client conformant to this Opportunistic Security -- If a client conformant to this
specification can reliably determine the presence of a TLSA specification can reliably determine the presence of a TLSA
record, it will attempt to use this information. Conversely, if a record, it will attempt to use this information. Conversely, if a
client can reliably determine the absence of any TLSA record, it client can reliably determine the absence of any TLSA record, it
will fall back to processing TLS in the normal fashion. This is will fall back to processing TLS in the normal fashion. This is
discussed in Section 4. discussed in Section 4.
skipping to change at page 14, line 7 skipping to change at page 14, line 45
Minimal Dependencies -- This specification relies on DNSSEC to Minimal Dependencies -- This specification relies on DNSSEC to
protect the origin authenticity and integrity of the TLSA resource protect the origin authenticity and integrity of the TLSA resource
record set. Additionally, if DNSSEC validation is not performed record set. Additionally, if DNSSEC validation is not performed
on the system that wishes to use TLSA certificate bindings, this on the system that wishes to use TLSA certificate bindings, this
specification requires that the "last mile" be over a secure specification requires that the "last mile" be over a secure
transport. There are no other deployment dependencies for this transport. There are no other deployment dependencies for this
approach. approach.
Minimal Options -- The operating modes map precisely to the DANE use Minimal Options -- The operating modes map precisely to the DANE use
cases and requirements. DNSSEC use is mandatory in that this cases and requirements. DNSSEC use is mandatory in that this
specification encourages applications to use TLSA records that are specification encourages applications to use only those TLSA
only shown to be validated. records that are shown to be validated.
Wild Cards -- Covered in a limited manner in the TLSA request Wild Cards -- Covered in a limited manner in the TLSA request
syntax; see Appendix A. syntax; see Appendix A.
Redirection -- Covered in the TLSA request syntax; see Appendix A. Redirection -- Covered in the TLSA request syntax; see Appendix A.
6. Mandatory-to-Implement Features 6. Mandatory-to-Implement Features
TLS clients conforming to this specification MUST be able to TLS clients conforming to this specification MUST be able to
correctly interpret TLSA records with certificate usages 0, 1, 2, and correctly interpret TLSA records with certificate usages 0, 1, 2, and
3. TLS clients conforming to this specification MUST be able to 3. TLS clients conforming to this specification MUST be able to
compare a certificate association with a certificate from the TLS compare a certificate association with a certificate from the TLS
handshake using selectors type 0 and 1, and matching type 0 (no hash handshake using selector types 0 and 1, and matching type 0 (no hash
used) and matching type 1 (SHA-256), and SHOULD be able to make such used) and matching type 1 (SHA-256), and SHOULD be able to make such
comparisons with matching type 2 (SHA-512). comparisons with matching type 2 (SHA-512).
At the time this is written, it is expected that there will be a new At the time this is written, it is expected that there will be a new
family of hash algorithms called SHA-3 within the next few years. It family of hash algorithms called SHA-3 within the next few years. It
is expected that some of the SHA-3 algorithms will be mandatory is expected that some of the SHA-3 algorithms will be mandatory
and/or recommended for TLSA records after the algorithms are fully and/or recommended for TLSA records after the algorithms are fully
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
might also consider making a "DANE" section in the main IANA registry
to help developers find related registries that might be created in
the future.
In the following sections, "RFC Required" was chosen for TLSA usages In the following sections, "RFC Required" was chosen for TLSA usages
and "Specification Required" for selectors and matching types because and "Specification Required" for selectors and matching types because
of the amount of detail that is likely to be needed for implementers of the amount of detail that is likely to be needed for implementers
to correctly implement new usages as compared to new selectors and to correctly implement new usages as compared to new selectors and
matching types. matching types.
7.1. TLSA RRtype 7.1. TLSA RRtype
This document uses a new DNS RR type, TLSA, whose value is TBD. A This document uses a new DNS RR type, TLSA, whose value is TBD. A
separate request for the RR type will be submitted to the expert separate request for the RR type will be submitted to the expert
skipping to change at page 16, line 16 skipping to change at page 17, line 16
The security of the DNS RRtype described in this document relies on The security of the DNS RRtype described in this document relies on
the security of DNSSEC as used by the client requesting A/AAAA and the security of DNSSEC as used by the client requesting A/AAAA and
TLSA records. TLSA records.
A DNS administrator who goes rogue and changes both the A/AAAA and A DNS administrator who goes rogue and changes both the A/AAAA and
TLSA records for a domain name can cause the user to go to an TLSA records for a domain name can cause the user to go to an
unauthorized server that will appear authorized, unless the client unauthorized server that will appear authorized, unless the client
performs PKIX certification path validation and rejects the performs PKIX certification path validation and rejects the
certificate. That administrator could probably get a certificate certificate. That administrator could probably get a certificate
issued anyway, so this is not an additional threat. issued by some CA anyway, so this is not an additional threat.
If the authentication mechanism for adding or changing TLSA data in a If the authentication mechanism for adding or changing TLSA data in a
zone is weaker than the authentication mechanism for changing the zone is weaker than the authentication mechanism for changing the
A/AAAA records, a man-in-the-middle who can redirect traffic to their A/AAAA records, a man-in-the-middle who can redirect traffic to their
site may be able to impersonate the attacked host in TLS if they can site may be able to impersonate the attacked host in TLS if they can
use the weaker authentication mechanism. A better design for use the weaker authentication mechanism. A better design for
authenticating DNS would be to have the same level of authentication authenticating DNS would be to have the same level of authentication
used for all DNS additions and changes for a particular domain name. used for all DNS additions and changes for a particular domain name.
SSL proxies can sometimes act as a man-in-the-middle for TLS clients. SSL proxies can sometimes act as a man-in-the-middle for TLS clients.
skipping to change at page 17, line 25 skipping to change at page 18, line 25
anchor. 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 The client's full trust of a certificate retrieved from a TLSA record
with a certificate usage type of 2 or 3 may be a matter of local with a certificate usage type of 2 or 3 may be a matter of local
policy. While such trust is limited to the specific domain nane for policy. While such trust is limited to the specific domain name for
which the TLSA query was made, local policy may deny the trust or which the TLSA query was made, local policy may deny the trust or
further restrict the conditions under which that trust is permitted. further restrict the conditions under which that trust is permitted.
8.1. DNS Caching 8.1. Comparing DANE to Public CAs
Comparing the risk for current common TLS clients against the risk
for DANE clients using external DNSSEC validators is difficult. The
common model for TLS clients is that they trust a large number of
commercial CAs who can issue certificates for any domain name. A
DANE client trusting an external DNSSEC validator is as vulnerable as
such a TLS client in that any 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
validators being hacked that it is of a public CA being compromised,
a DANE client with an external validator could be worse off than a
current TLS client that is depending on the current public 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
DANE 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
DNSSEC validators, but that perception cannot be proven one way or
another. Similarly, if DNSSEC validation becomes more common after
the release of this document, it cannot be predicted whether or not
that will increase the level of security of DNSSEC validators more or
less than the security of public CAs. Thus, it is difficult to
foresee which system has a higher risk.
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 assocation
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
skipping to change at page 18, line 14 skipping to change at page 19, line 40
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 and Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John
John Gilmore. Gilmore, and Murray Kucherawy.
This document has also been greatly helped by many active This document has also been greatly helped by many active
participants of the DANE Working Group. participants of the DANE Working Group.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
skipping to change at page 19, line 8 skipping to change at page 20, line 38
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
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,
November 1987.
10.2. Informative References 10.2. Informative References
[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.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
skipping to change at page 19, line 43 skipping to change at page 21, line 28
[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.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376,
September 2011.
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
Authentication of Named Entities (DANE)", RFC 6394, Authentication of Named Entities (DANE)", RFC 6394,
October 2011. October 2011.
Appendix A. Operational Considerations for Deploying TLSA Records Appendix A. Operational Considerations for Deploying TLSA Records
A.1. Creating TLSA Records A.1. Creating TLSA Records
When creating TLSA records care must be taken to avoid When creating TLSA records, care must be taken to avoid
misconfigurations. Section 4 of this document states that a TLSA misconfigurations. Section 4 of this document states that a TLSA
RRset whose validation state is secure MUST be used. This means that RRset whose validation state is secure MUST be used. This means that
the existence of such a RRset effectively disables other forms of the existence of such a RRset effectively disables other forms of
name and path validation. A misconfigured TLSA RRset will name and path validation. A misconfigured TLSA RRset will
effectively disable access to the TLS server for all conforming effectively disable access to the TLS server for all conforming
clients, and this document does not provide any means of making a clients, and this document does not provide any means of making a
gradual transition to using TLSA. gradual transition to using TLSA.
When creating TLSA records with certificate usage type 0 (CA When creating TLSA records with certificate usage type 0 (CA
Certificate) or type 2 (Trust Anchor), one needs to understand the Certificate) or type 2 (Trust Anchor), one needs to understand the
implications when choosing between selector type 0 (full certificate) implications when choosing between selector type 0 (full certificate)
and 1 (SubjectPublicKeyInfo). A careful choice is required because and 1 (SubjectPublicKeyInfo). A careful choice is required because
different methods for building trust chains are used by different TLS different methods for building trust chains are used by different TLS
clients. The following outlines the cases that one should be aware clients. The following outlines the cases that one ought to be aware
of and discusses the implications of the choice of selector type. of and discusses the implications of the choice of selector type.
Certificate usage 2 is not affected by the different types of chain Certificate usage 2 is not affected by the different types of chain
building when the end entity certificate is the same as the trust building when the end entity certificate is the same as the trust
anchor certificate. anchor certificate.
A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains
TLS clients may implement their own chain-building code rather than TLS clients can implement their own chain-building code rather than
rely on the chain presented by the TLS server. This means that, rely on the chain presented by the TLS server. This means that,
except for the end entity certificate, any certificate presented in except for the end entity certificate, any certificate presented in
the suggested chain might or might not be present in the final chain the suggested chain might or might not be present in the final chain
built by the client. built by the client.
Certificates that the client can use to replace certificates from Certificates that the client can use to replace certificates from the
original chain include: original chain include:
o Client's trust anchors o Client's trust anchors
o Certificates cached locally o Certificates cached locally
o Certificates retrieved from a URI listed in an Authority o Certificates retrieved from a URI listed in an Authority
Information Access X.509v3 extension Information Access X.509v3 extension
CAs frequently reissue certificates with different validity period, CAs frequently reissue certificates with different validity periods,
signature algorithm (such as an different hash algorithm in the signature algorithms (such as an different hash algorithm in the
signature algorithm), CA key pair (such as for a cross-certificate), signature algorithm), CA key pairs (such as for a cross-certificate),
or PKIX extensions where the public key and subject remain the same. or PKIX extensions where the public key and subject remain the same.
These reissued certificates are the certificates TLS client can use These reissued certificates are the certificates TLS client can use
in place of an original certificate. in place of an original certificate.
Clients are known to exchange or remove certificates that could cause Clients are known to exchange or remove certificates that could cause
TLSA association that rely on the full certificate to fail. For TLSA associations that rely on the full certificate to fail. For
example: example:
o The client considers the signature algorithm of a certificate to o The client considers the signature algorithm of a certificate to
no longer be sufficiently secure no longer be sufficiently secure
o The client might not have an associated root certificate in its o The client might not have an associated root certificate in its
trust store and instead uses a cross-certificate with an identical trust store and instead uses a cross-certificate with an identical
subject and public key. subject and public key.
A.1.2. Choosing a Selector Type A.1.2. Choosing a Selector Type
In this section, "false-negative failure" means that a client will In this section, "false-negative failure" means that a client will
not accept the TLSA association for certificate designated by DNS not accept the TLSA association for a certificate designated by DNS
administrator. Also, "false-positive acceptance" means that the administrator. Also, "false-positive acceptance" means that the
client accepts a TLSA association for a certificate that is not client accepts a TLSA association for a certificate that is not
designated by the DNS administrator. designated by the DNS administrator.
A.1.2.1. Selector Type 0 (Full Certificate) A.1.2.1. Selector Type 0 (Full Certificate)
The "Full certificate" selector provides the most precise The "Full certificate" selector provides the most precise
specification of a TLS certificate association, capturing all fields specification of a TLS certificate association, capturing all fields
of the PKIX certificate. For a DNS administrator, the best course to of the PKIX certificate. For a DNS administrator, the best course to
avoid false-negative failures in the client when using this selector avoid false-negative failures in the client when using this selector
are: is:
o If a CA issued a replacement certificate, don't associate to CA 1. If a CA issued a replacement certificate, don't associate to CA
certificates that have a signature algorithm with a hash that is certificates that have a signature algorithm with a hash that is
considered weak (such as MD2 and MD5). considered weak by local policy.
o Determine how common client applications process the TLSA 2. Determine how common client applications process the TLSA
association using a fresh client installation, that is, with the association using a fresh client installation, that is, with the
local certificate cache empty. local certificate cache empty.
A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo) A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo)
A SubjectPublicKeyInfo selector gives greater flexibility in avoiding A SubjectPublicKeyInfo selector gives greater flexibility in avoiding
some false-negative failures caused by trust-chain-building some false-negative failures caused by trust-chain-building
algorithms used in clients. algorithms used in clients.
One specific use-case should be noted: creating a TLSA association to One specific use-case ought to be noted: creating a TLSA association
CA certificate I1 that directly signed end entity certificate S1 of to CA certificate I1 that directly signed end entity certificate S1
the server. The case can be illustrated by following graph: of the server. The case can be illustrated by following graph:
+----+ +----+ +----+ +----+
| I1 | | I2 | | I1 | | I2 |
+----+ +----+ +----+ +----+
| | | |
v v v v
+----+ +----+ +----+ +----+
| S1 | | S1 | | S1 | | S1 |
+----+ +----+ +----+ +----+
Certificate chain sent by A different validation path Certificate chain sent by A different validation path
skipping to change at page 22, line 31 skipping to change at page 24, line 17
S1 is fixed. An association to SubjectPublicKeyInfo (selector type S1 is fixed. An association to SubjectPublicKeyInfo (selector type
1) will always succeed in such a case, but an association with a full 1) will always succeed in such a case, but an association with a full
certificate (selector type 0) might not work due to a false-negative certificate (selector type 0) might not work due to a false-negative
failure. failure.
The attack surface is a bit broader compared to "full certificate" The attack surface is a bit broader compared to "full certificate"
selector: the DNS administrator might unintentionally specify an selector: the DNS administrator might unintentionally specify an
association that would lead to false-positive acceptance. association that would lead to false-positive acceptance.
o The administrator must know or trust that the CA does not engage o The administrator must know or trust that the CA does not engage
in bad practices, such as not sharing key of I1 for unrelated CA in bad practices, such as not sharing the key of I1 for unrelated
certificates leading to trust-chain redirect. If possible, the CA certificates leading to trust-chain redirect. If possible, the
administrator should review all CA certificates that have the same administrator ought to review all CA certificates that have the
SPKI. same SPKI.
o The administrator should understand whether some PKIX extension o The administrator ought to understand whether some PKIX extension
may adversely affect security of the association. If possible, may adversely affect security of the association. If possible,
administrators should review all CA certificates that share the administrators ought to review all CA certificates that share the
SubjectPublicKeyInfo. SubjectPublicKeyInfo.
o The administrator should understand that any CA could, in the o The administrator ought to understand that any CA could, in the
future, issue a certificate that contains the same future, issue a certificate that contains the same
SubjectPublicKeyInfo. Therefore, new chains can crop up in the SubjectPublicKeyInfo. Therefore, new chains can crop up in the
future without any warning. future without any warning.
Using the SubjectPublicKeyInfo selector for association with a Using the SubjectPublicKeyInfo selector for association with a
certificate in a chain above I1 needs to be decided on a case-by-case certificate in a chain above I1 needs to be decided on a case-by-case
basis: there are too many possibilities based on the issuing CA's basis: there are too many possibilities based on the issuing CA's
practices. Unless the full implications of such an association are practices. Unless the full implications of such an association are
understood by the administrator, using selector type 0 is a better understood by the administrator, using selector type 0 is a better
option from a security perspective. option from a security perspective.
skipping to change at page 24, line 32 skipping to change at page 26, line 18
_443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN A 192.0.2.1
sub6.example.com. IN AAAA 2001:db8::1 sub6.example.com. IN AAAA 2001:db8::1
_443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...
In this example, someone looking for the TLSA record for In this example, someone looking for the TLSA record for
sub5.example.com would always get the record whose value starts sub5.example.com would always get the record whose value starts
"308202c5308201ab"; the TLSA record whose value starts "308202c5308201ab"; the TLSA record whose value starts
"ac49d9ba4570ac49" would only be sought by someone who is looking for "ac49d9ba4570ac49" would only be sought by someone who is looking for
the TLSA record for sub6.example.com, and never for sub5.example.com. the TLSA record for sub6.example.com, and never for sub5.example.com.
One should note that deploying different certificates for multiple Note that deploying different certificates for multiple services
services located at a shared TLS listener often requires the use of located at a shared TLS listener often requires the use of TLS SNI
TLS SNI (Server Name Indication) [RFC6066]. (Server Name Indication) [RFC6066].
Note that these methods use the normal method for DNS aliasing using Note that these methods use the normal method for DNS aliasing using
CNAME: the DNS client requests the record type that they actually CNAME: the DNS client requests the record type that they actually
want. want.
A.2.1.2. Provisioning TLSA Records with DNAME Records A.2.1.2. Provisioning TLSA Records with DNAME Records
Using DNAME records allows a zone owner to alias an entire subtree of Using DNAME records allows a zone owner to alias an entire subtree of
names below the name that has the DNAME. This allows the wholesale names below the name that has the DNAME. This allows the wholesale
aliasing of prefixed records such as those used by TLSA, SRV, and so aliasing of prefixed records such as those used by TLSA, SRV, and so
skipping to change at page 25, line 16 skipping to change at page 26, line 46
; ;
sub5.example.com. IN CNAME sub6.example.com. sub5.example.com. IN CNAME sub6.example.com.
_tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com. _tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com.
sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN A 192.0.2.1
sub6.example.com. IN AAAA 2001:db8::1 sub6.example.com. IN AAAA 2001:db8::1
_443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4... _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
A.2.1.3. Provisioning TLSA Records with Wildcards A.2.1.3. Provisioning TLSA Records with Wildcards
Wildcards are generally not terribly useful for RRtypes that require Wildcards are generally not terribly useful for RRtypes that require
prefixing because you can only wildcard at a layer below the host prefixing because one can only wildcard at a layer below the host
name. For example, if you want to have the same TLSA record for name. For example, if one wants to have the same TLSA record for
every TCP port for www.example.com, you might have every TCP port for www.example.com, the result might be:
*._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b... *._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b...
This is possibly useful in some scenarios where the same service is This is possibly useful in some scenarios where the same service is
offered on many ports. offered on many ports or the same certificate and/or key is used for
all services on a host. Note that the domain being searched for is
not necessarily related to the domain name found in the certificate,
so a certificate with a wildcard in it is not searched for using a
wildcard in the search request.
A.3. Securing the Last Hop A.3. Securing the Last Hop
As described in Section 4, an application processing TLSA records As described in Section 4, an application processing TLSA records
must know the DNSSEC validity of those records. There are many ways must know the DNSSEC validity of those records. There are many ways
for the application to securely find this out, and this specification for the application to determine this securely, and this
does not mandate any single method. specification does not mandate any single method.
Some common methods for an application to know the DNSSEC validity of Some common methods for an application to know the DNSSEC validity of
TLSA records include: TLSA records include:
o The application can have its own DNS resolver and DNSSEC o The application can have its own DNS resolver and DNSSEC
validation stack. validation stack.
o The application can communicate through a trusted channel (such as o The application can communicate through a trusted channel (such as
requests to the operating system under which the application is requests to the operating system under which the application is
running) to a local DNS resolver that does DNSSEC validation. running) to a local DNS resolver that does DNSSEC validation.
skipping to change at page 26, line 33 skipping to change at page 28, line 17
new certificate on the TLS server. Once this has occurred, the old new certificate on the TLS server. Once this has occurred, the old
TLSA record can be removed: TLSA record can be removed:
_990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30... _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
This completes the certificate rollover. This completes the certificate rollover.
Appendix B. Pseudocode for Using TLSA Appendix B. Pseudocode for Using TLSA
This appendix describes the interactions given earlier in this This appendix describes the interactions given earlier in this
specification in pseudocode format. This appendix is non-normative. specification in pseudocode format. If the steps below disagree with
If the steps below disagree with the text earlier in the document, the text earlier in the document, the steps earlier in the document
the steps earlier in the document should be considered correct and ought to be considered correct and this text incorrect.
this text incorrect.
Note that this pseudocode is more strict than the normative text. Note that this pseudocode is more strict than the normative text.
For instance, it forces an order on the evaluation of criteria which For instance, it forces an order on the evaluation of criteria which
is not mandatory from the normative text. is not mandatory from the normative text.
B.1. Helper Functions B.1. Helper Functions
// implement the function for exiting // implement the function for exiting
function Finish (F) = { function Finish (F) = {
if (F == ABORT_TLS) { if (F == ABORT_TLS) {
skipping to change at page 29, line 21 skipping to change at page 31, line 4
// pass PKIX certificate validation and match EE cert from TLSA // pass PKIX certificate validation and match EE cert from TLSA
if (R.certUsage == 1) { if (R.certUsage == 1) {
for each PKIX certification path H { for each PKIX certification path H {
if ((C passes PKIX certificate validation in H) and if ((C passes PKIX certificate validation in H) and
Match(R.matchingType, Select(R.selectorType, C), Match(R.matchingType, Select(R.selectorType, C),
R.cert)) { R.cert)) {
Finish(ACCEPT) Finish(ACCEPT)
} }
} }
} }
// pass PKIX certification validation using TLSA record as the // pass PKIX certification validation using TLSA record as the
// trust anchor // trust anchor
if (R.certUsage == 2) { if (R.certUsage == 2) {
for each PKIX certification path H that has R as the // the following assert() is merely a formalization of the
trust anchor { // "trust anchor" condition for a certificate D matching R
if (C passes PKIX certification validation in H) and assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))
Match(R.matchingType, Select(R.selectorType, C),
R.cert)) { for each PKIX certification path H that has certificate D
Finish(ACCEPT) matching R as the trust anchor {
if (C passes PKIX validation in H) {
Finish(ACCEPT);
} }
} }
} }
// match the TLSA record and the TLS certificate // match the TLSA record and the TLS certificate
if (R.certUsage == 3) { if (R.certUsage == 3) {
if Match(R.matchingType, Select(R.selectorType, C), R.cert) if Match(R.matchingType, Select(R.selectorType, C), R.cert)
Finish(ACCEPT) Finish(ACCEPT)
} }
} }
 End of changes. 79 change blocks. 
179 lines changed or deleted 256 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/