draft-ietf-dane-protocol-21.txt   draft-ietf-dane-protocol-22.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: November 18, 2012 Kirei AB Expires: December 16, 2012 Kirei AB
May 17, 2012 June 14, 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-21 draft-ietf-dane-protocol-22
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 November 18, 2012. This Internet-Draft will expire on December 16, 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 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . 14 5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 14
6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 15 6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . 17 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . 19 8.1. Comparing DANE to Public CAs . . . . . . . . . . . . . . . 19
8.1.1. Risk of Key Compromise . . . . . . . . . . . . . . . . 19 8.1.1. Risk of Key Compromise . . . . . . . . . . . . . . . . 19
8.1.2. Impact of Key Compromise . . . . . . . . . . . . . . . 20 8.1.2. Impact of Key Compromise . . . . . . . . . . . . . . . 20
8.1.3. Detection of Key Compromise . . . . . . . . . . . . . 21 8.1.3. Detection of Key Compromise . . . . . . . . . . . . . 21
8.1.4. Spoofing Hostnames . . . . . . . . . . . . . . . . . . 21 8.1.4. Spoofing Hostnames . . . . . . . . . . . . . . . . . . 21
8.2. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. External DNSSEC Validators . . . . . . . . . . . . . . . . 22 8.3. External DNSSEC Validators . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Operational Considerations for Deploying TLSA Appendix A. Operational Considerations for Deploying TLSA
Records . . . . . . . . . . . . . . . . . . . . . . . 25 Records . . . . . . . . . . . . . . . . . . . . . . . 25
A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . 25 Build Trust Chains . . . . . . . . . . . . . . . . . . 25
A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 26 A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 26
A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 28 A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 28
A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 28 A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 28
A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 30 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 30
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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 fake keys (that is, a key not corresponding to the can be replaced by fake keys (that is, a key not corresponding to the
entity identified in the certificate), these systems provide little entity identified in the certificate), these systems provide little
or no security. 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 key in a certificate is only helpful if one
one trusts the other key that signed the certificate. If that other trusts the other key that signed the certificate. If that other key
key was itself revealed or substituted, then its signature is was itself revealed or substituted, then its signature is worthless
worthless in proving anything about the first key. 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.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
There are many use cases for such functionality. [RFC6394] lists the There are many use cases for such functionality. [RFC6394] lists the
ones to which the DNS RRtype in this document apply. [RFC6394] also ones to which the DNS RRtype in this document apply. [RFC6394] also
lists many requirements, most of which this document is believed to lists many requirements, most of which this document is believed to
meet. Section 5 covers the applicability of this document to the use meet. Section 5 covers the applicability of this document to the use
cases in detail. The protocol in this document can generally be cases in detail. The protocol in this document can generally be
referred to as the "DANE TLSA" protocol. ("TLSA" does not stand for referred to as the "DANE TLSA" protocol. ("TLSA" does not stand for
anything; it is just the name of the RRtype.) anything; it is just the name of the RRtype.)
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". Although the
relates to securely associating certificates for TLS and DTLS with references in this paragraph are to TLS and DTLS version 1.2, the
host names; other security protocols are handled in other documents. DANE TLSA protocol can also be used with earlier versions of TLS and
For example, keys for IPsec are covered in [RFC4025] and keys for SSH DTLS.
are covered in [RFC4255]. Although the references in this paragraph
are to TLS and DTLS version 1.2, the DANE TLSA protocol can also be This document only relates to securely associating certificates for
used with earlier versions of TLS and DTLS. TLS and DTLS with host names; retrieving certificates from DNS for
other protocols is handled in other documents. For example, keys for
IPsec are covered in [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 and the domain name where the server identifying a certificate and the domain name where the server
application runs. The combination of a trust anchor and a domain application runs. The combination of a trust anchor and a domain
name can also be a certificate association. name can also be a certificate association.
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 a server that is changing from one certificate to another the case of a server that is changing from one certificate to another
(described in more detail in Appendix A.4). (described in more detail in Appendix A.4).
This document only applies to PKIX [RFC5280] certificates, not This document only applies to PKIX [RFC5280] certificates, not
certificates of other formats. Later updates to this document might certificates of 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
future documents will cover methods for making those associations, future documents will cover methods for making those associations,
skipping to change at page 7, line 44 skipping to change at page 7, line 46
This document also makes use of standard PKIX, DNSSEC, TLS, and DNS This document also makes use of standard PKIX, DNSSEC, TLS, and DNS
terminology. See [RFC5280], [RFC4033], [RFC5246], and [STD13] terminology. See [RFC5280], [RFC4033], [RFC5246], and [STD13]
respectively, for these terms. In addition, terms related to TLS- respectively, for these terms. In addition, terms related to TLS-
protected application services and DNS names are taken from protected application services and DNS names are taken from
[RFC6125]. [RFC6125].
2. The TLSA Resource Record 2. The TLSA Resource Record
The TLSA DNS resource record (RR) is used to associate a TLS server The TLSA DNS resource record (RR) is used to associate a TLS server
certificate or public key with the domain name where the record is certificate or public key with the domain name where the record is
found, thus forming a "TLS certificate association". The semantics found, thus forming a "TLSA certificate association". The semantics
of how the TLSA RR is interpreted are given later in this document. of how the TLSA RR is interpreted are given later in this document.
The type value for the TLSA RR type is defined in Section 7.1. 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
skipping to change at page 8, line 46 skipping to change at page 8, line 48
referred to as "CA constraint" because it limits which CA can be referred to as "CA constraint" because it limits which CA can be
used to issue certificates for a given service on a host. The used to issue certificates for a given service on a host. The
presented certificate MUST pass PKIX certification path validation presented certificate MUST pass PKIX certification path validation
and a CA certificate that matches the TLSA record MUST be included and a CA certificate that matches the TLSA record MUST be included
as part of a valid certification path. Because this certificate as part of a valid certification path. Because this certificate
usage allows both trust anchors and CA certificates, the usage allows both trust anchors and CA certificates, the
certificate might or might not have the basicConstraints extension certificate might or might not have the basicConstraints extension
present. 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 certificate 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 certificate 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 certificate 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
skipping to change at page 9, line 41 skipping to change at page 9, line 43
that accept other formats for certificates, those certificates will that accept other formats for certificates, those certificates will
need their own certificate usage values. need their own certificate usage values.
2.1.2. The Selector Field 2.1.2. The Selector Field
A one-octet value, called "selector", specifies which part of the TLS A one-octet value, called "selector", specifies which part of the 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; the Certificate binary structure defined in
[RFC5280]
1 -- SubjectPublicKeyInfo
The SubjectPublicKeyInfo is a binary structure defined in [RFC5280]. 1 -- SubjectPublicKeyInfo; DER-encoded binary structure defined in
[RFC5280]
(Note that the use of "selector" in this document is completely (Note that the use of "selector" in this document is completely
unrelated to the use of "selector" in DKIM [RFC6376].) 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", specifies 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:
skipping to change at page 10, line 38 skipping to change at page 10, line 38
or the hash of the raw data for matching types 1 and 2. The data or the hash of the raw data for matching types 1 and 2. The data
refers to the certificate in the association, not to the TLS ASN.1 refers to the certificate in the association, not to the TLS ASN.1
Certificate object. Certificate object.
2.2. TLSA RR Presentation Format 2.2. TLSA RR Presentation Format
The presentation format of the RDATA portion (as defined in The presentation format of the RDATA portion (as defined in
[RFC1035]) is as follows: [RFC1035]) is as follows:
o The certificate usage field MUST be represented as an 8-bit o The certificate usage field MUST be represented as an 8-bit
unsigned decimal integer. 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. 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. 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, as described in [RFC1035]. 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.
skipping to change at page 12, line 4 skipping to change at page 12, line 4
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 base domain name is appended to the result of step 2 to 3. The base domain name is appended to the result of step 2 to
complete the prepared domain name. The base domain name is the complete the prepared domain name. The base domain name is the
fully-qualified DNS domain name [RFC1035] of the TLS server, with fully-qualified DNS domain name [RFC1035] of the TLS server, with
the additional restriction that every label must meet the rules the additional restriction that every label MUST meet the rules
of [RFC0952]. The latter restriction means that, if the query is of [RFC0952]. The latter restriction means that, if the query is
for an internationalized domain name, it must use the A-label for an internationalized domain name, it MUST use the A-label
form as defined in [RFC5890]. 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 14, line 4 skipping to change at page 14, line 4
An attacker who is able to divert a user to a server under his 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 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 or DNS responses being sent to the user. Thus, in order to achieve
any security benefit from certificate usage 0 or 1, an application any security benefit from certificate usage 0 or 1, an application
that sends a request for TLSA records needs to get either a valid that sends a request for TLSA records needs to get either a valid
signed response containing TLSA records or verification that the signed response containing TLSA records or verification that the
domain is insecure or indeterminate. If a request for a TLSA record domain is insecure or indeterminate. If a request for a TLSA record
does not meet one of those two criteria but the application continues does not meet one of those two criteria but the application continues
with the TLS handshake anyway, the application has gotten no benefit with the TLS handshake anyway, the application has gotten no benefit
from TLSA and should not make any internal or external indication from TLSA and SHOULD NOT make any internal or external indication
that TLSA was applied. If an application has a configuration setting 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 that has turned on TLSA use, or has any indication that TLSA is in
(regardless of whether or not this is configurable), that application use (regardless of whether or not this is configurable), that
MUST not start a TLS connection or abort a TLS handshake if either of application either MUST NOT start a TLS connection or it MUST abort a
the two criteria above are not met. TLS handshake if both 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 10 skipping to change at page 16, line 10
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 selector types 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
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
and/or recommended for TLSA records after the algorithms are fully
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
certificate 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
skipping to change at page 17, line 46 skipping to change at page 17, line 40
Applications to the registry can request specific values that have Applications to the registry can request specific values that have
yet to be assigned. yet to be assigned.
8. Security Considerations 8. Security Considerations
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 to verify that the TLSA record has not been the security of DNSSEC to verify that the TLSA record has not been
altered. altered.
A DNS administrator who goes rogue and changes both the A, AAAA, A DNS administrator who goes rogue and changes both the A, AAAA,
and/or TLSA records for a domain name can cause the user to go to an and/or TLSA records for a domain name can cause the client to go to
unauthorized server that will appear authorized, unless the client an 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 by some CA 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 A zone is weaker than the authentication mechanism for changing the A
and/or AAAA records, a man-in-the-middle who can redirect traffic to and/or 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 their site may be able to impersonate the attacked host in TLS if
they can use the weaker authentication mechanism. A better design they can use the weaker authentication mechanism. A better design
for authenticating DNS would be to have the same level of for authenticating DNS would be to have the same level of
skipping to change at page 18, line 26 skipping to change at page 18, line 20
key is kept on the SSL proxy; the proxy intercepts TLS requests, key is kept on the SSL proxy; the proxy intercepts TLS requests,
creates a new TLS session with the intended host, and sets up a TLS creates a new TLS session with the intended host, and sets up a TLS
session with the client using a certificate that chains to the trust session with the client using a certificate that chains to the trust
anchor installed in the client by the proxy. In such environments, anchor installed in the client by the proxy. In such environments,
using TLSA records will prevent the SSL proxy from functioning as using TLSA records will prevent the SSL proxy from functioning as
expected because the TLS client will get a certificate association expected because the TLS client will get a certificate association
from the DNS that will not match the certificate that the SSL proxy from the DNS that will not match the certificate that the SSL proxy
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 trust anchor is a
anchor is a matter of local policy. This specification does not matter of local policy. This specification does not mandate that
mandate that such information be inspected or validated by the such information be inspected or validated by the server's domain
server's domain name administrator. 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 server and a trust anchor has its certificate
revoked, a TLSA record with a certificate usage 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 usage 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 become 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.
Generators of TLSA records should be aware that the client's full Generators of TLSA records should be aware that the client's full
trust of a certificate association retrieved from a TLSA record may trust of a certificate association retrieved from a TLSA record may
be a matter of local policy. While such trust is limited to the be a matter of local policy. While such trust is limited to the
specific domain name, protocol, and port for which the TLSA query was specific domain name, protocol, and port for which the TLSA query was
made, local policy may deny to trust the certificate (such as due to made, local policy may decline to accept the certificate (for reasons
weak cryptography), the same as it is with PKIX trust anchors. such as weak cryptography), as is also the case with PKIX trust
anchors.
8.1. Comparing DANE to Public CAs 8.1. Comparing DANE to Public CAs
As stated above, the security of the DNS RRtype described in this As stated above, the security of the DNS RRtype described in this
document relies on the security of DNSSEC to verify that the TLSA document relies on the security of DNSSEC to verify that the TLSA
record has not been altered. This section describes where the record has not been altered. This section describes where the
security of public CAs and the security of TLSA are similar and security of public CAs and the security of TLSA are similar and
different. This section applies equally to other security-related different. This section applies equally to other security-related
DNS RRtypes such as keys for IPsec and SSH. DNS RRtypes such as keys for IPsec and SSH.
skipping to change at page 20, line 4 skipping to change at page 19, line 48
constrain the keys they identify to names that are within the zone constrain the keys they identify to names that are within the zone
signing the certificate. In order for a domain's DLV resource signing the certificate. In order for a domain's DLV resource
records to be honored, the domain must be configured as a DLV domain, 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 and the domain's DNSKEYs must be configured as trust anchors or be
authentic [RFC5074]. authentic [RFC5074].
8.1.1. Risk of Key Compromise 8.1.1. Risk of Key Compromise
The risk that a given certificate that has a valid signing chain is 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 fake is related to the number of keys that can contribute to the
validation of the certificate, the quality of protection each key validation of the certificate, the quality of protection each private
receives, the value of each key to an attacker, and the value of key receives, the value of each key to an attacker, and the value of
falsifying the certificate. falsifying the certificate.
DNSSEC allows any set of domains to be configured as trust anchors 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 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 only trust anchor. Also, because a given DNSKEY can only sign
resource records for that zone, the number of keys capable of resource records for that zone, the number of private keys capable of
compromising a given TLSA resource record is limited to the number of compromising a given TLSA resource record is limited to the number of
zones between the TLSA resource record and the nearest trust anchor, zones between the TLSA resource record and the nearest trust anchor,
plus any configured DLV domains. Typically, this will be six keys, plus any configured DLV domains. Typically, this will be six keys,
half of which will be KSKs. half of which will be KSKs.
PKIX only describes how to validate a certificate based on a client- PKIX only describes how to validate a certificate based on a client-
chosen set of trust anchors, but says nothing about how many trust chosen set of trust anchors, but says nothing about how many trust
anchors to use or how they should be constrained. As currently anchors to use or how they should be constrained. As currently
deployed, most PKIX clients use a large number of trust anchors deployed, most PKIX clients use a large number of trust anchors
provided with the client or operating system software. These trust provided with the client or operating system software. These trust
skipping to change at page 21, line 20 skipping to change at page 21, line 13
equivalent impact of an unconstrained public CA. equivalent impact of an unconstrained public CA.
o Public CAs are not typically constrained in what names they can o Public CAs are not typically constrained in what names they can
sign, and therefore a compromise of even one CA allows the sign, and therefore a compromise of even one CA allows the
attacker to generate a certificate for any name in the DNS. A attacker to generate a certificate for any name in the DNS. A
domain holder can get a certificate from any willing CA, or even domain holder can get a certificate from any willing CA, or even
multiple CAs simultaneously, making it impossible for a client to multiple CAs simultaneously, making it impossible for a client to
determine whether the certificate it is validating is legitimate determine whether the certificate it is validating is legitimate
or fraudulent. or fraudulent.
Because a TLS certificate association is constrained to its Because a TLSA certificate association is constrained to its
associated name, protocol, and port, the PKIX certificate is associated name, protocol, and port, the PKIX certificate is
similarly constrained, even if its public CAs signing the certificate similarly constrained, even if its public CAs signing the certificate
(if any) are not. (if any) are not.
8.1.3. Detection of Key Compromise 8.1.3. Detection of Key Compromise
If a key is compromised, rapid and reliable detection is important in If a key is compromised, rapid and reliable detection is important in
order to limit the impact of the compromise. In this regard, neither order to limit the impact of the compromise. In this regard, neither
model prevents an attacker from near-invisibly attacking their model prevents an attacker from near-invisibly attacking their
victim, provided that the necessary keys are compromised. victim, provided that the necessary keys are compromised.
skipping to change at page 21, line 43 skipping to change at page 21, line 36
fraudulent certificate, as there is typically no publicly-accessible fraudulent certificate, as there is typically no publicly-accessible
directory of all the certificates issued by a CA that can be directory of all the certificates issued by a CA that can be
inspected. DNS resource records are typically published publicly. inspected. DNS resource records are typically published publicly.
However, the attacker could also allow the uncompromised records to However, the attacker could also allow the uncompromised records to
be published to the Internet as usual but provide a compromised DNS be published to the Internet as usual but provide a compromised DNS
view to the victim to achieve the same effect. view to the victim to achieve the same effect.
8.1.4. Spoofing Hostnames 8.1.4. Spoofing Hostnames
Some CAs implement technical controls to ensure that certificates are Some CAs implement technical controls to ensure that certificates are
not issued to domains that with names similar to popular & prone-to- not issued to domains with names similar to popular & prone-to-attack
attack domains. Of course, an attacker can attempt to circumvent domains. Of course, an attacker can attempt to circumvent this
this restriction by finding a CA willing to issue the certificate restriction by finding a CA willing to issue the certificate anyway.
anyway. However, by using DNSSEC and TLSA, the attacker can However, by using DNSSEC and TLSA, the attacker can circumvent this
circumvent this check completely. 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 association 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
skipping to change at page 22, line 44 skipping to change at page 22, line 37
by an attacker. by an attacker.
However, even with secure communications between a host and the However, even with secure communications between a host and the
external validating resolver, there is a risk that the external external validating resolver, there is a risk that the external
validator could become compromised. Nothing prevents a compromised validator could become compromised. Nothing prevents a compromised
external DNSSEC validator from claiming that all the records it external DNSSEC validator from claiming that all the records it
provides are secure, even if the data is falsified, unless the client provides are secure, even if the data is falsified, unless the client
checks the DNSSEC data itself (rendering the the external validator checks the DNSSEC data itself (rendering the the external validator
unnecessary). unnecessary).
For this reason, it is RECOMMENDED that DNSSEC validation always be For this reason, DNSSEC validation is best performed on-host, even
performed on-host, even when a secure path to an external validator when a secure path to an external validator is available.
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
 End of changes. 32 change blocks. 
65 lines changed or deleted 61 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/