draft-ietf-dane-protocol-17.txt   draft-ietf-dane-protocol-18.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 1, 2012 Kirei AB Expires: September 10, 2012 Kirei AB
February 29, 2012 March 9, 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-17 draft-ietf-dane-protocol-18
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 administrator of a domain name to certify 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 September 1, 2012. This Internet-Draft will expire on September 10, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . 9
2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 9 2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 9
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 . . . . . . . . 10
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 . . . . . . . . . . . 12
6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 14 6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 15 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 15
7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 15 7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Operational Considerations for Deploying TLSA Appendix A. Operational Considerations for Deploying TLSA
Records . . . . . . . . . . . . . . . . . . . . . . . 20 Records . . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 20 A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . 20
A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 21 A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 21
A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 22 A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 23
A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 22 A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 23
A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 24 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 25
A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 25 A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 26
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 26 Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 26
B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 26 B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 26
B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 27 B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 28
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 29 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 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 privacy 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 published
keys can be replaced by bogus keys, these systems provide little or keys can be replaced by bogus keys, these systems provide little or
no security. no security.
TLS uses certificates to protect keys. A certificate combines a TLS uses certificates to bind keys and names. A certificate combines
published key with other information such as the name of the service a published key with other information such as the name of the
that the key is used by, and this combination is digitally signed by service that the key is used by, and this combination is digitally
another key. Having a certificate for a key is only helpful if you signed by another key. Having a certificate for a key is only
trust the other key that signed the certificate. If that other key helpful if you trust the other key that signed the certificate. If
was itself revealed or substituted, then its signature is worthless that other key was itself revealed or substituted, then its signature
in proving anything about the first key. is 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.
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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 host name, port, and protocol. The certificates for a given service on a host. The target
target certificate MUST pass PKIX certification path validation certificate MUST pass PKIX certification path validation and a CA
and a CA certificate that matches the TLSA record MUST be included certificate that matches the TLSA record MUST be included as part
as part of a valid certification path. of a valid certification path.
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 may be
used by a given host name, port, and protocol. The target used by a given service on a host. The target certificate MUST
certificate MUST pass PKIX certification path validation and MUST pass PKIX certification path validation and MUST match the TLSA
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 a 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
domain name administrator to issue certificates for a domain domain name administrator to issue certificates for a domain
without involving a third-party CA. The target certificate MUST without involving a third-party CA. The target certificate MUST
match the TLSA record. match the TLSA record. The difference between certificate usage 1
and certificate usage 3 is that certificate usage 1 requires that
the certificate pass PKIX validation, but PKIX validation is not
tested for certificate usage 3.
The certificate usages defined in this document explicitly only apply The certificate usages defined in this document explicitly only apply
to PKIX-formatted certificates in DER encoding. 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", specifying which part of the
skipping to change at page 9, line 14 skipping to change at page 9, line 18
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", specifying 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 1 -- SHA-256 hash of selected content [RFC6234]
2 -- SHA-512 hash of selected content 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, the record SHOULD 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. This will assist clients that support a small number of
hash algorithms. 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
skipping to change at page 11, line 23 skipping to change at page 11, line 23
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 under 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 records An implementation of this protocol makes a DNS query for TLSA
(or uses already-retrieved TLSA records if they are cached within records, validates these records using DNSSEC, and uses the resulting
their time to live value), validates these records using DNSSEC, and TLSA records and validation status to modify its responses to the TLS
uses the resulting TLSA records and validation status to modify its server.
responses to the TLS server.
If a host is using TLSA usage type 2 for its certifcate, the If a host is using TLSA usage type 2 for its 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 depends on the DNSSEC
validation state (as defined in [RFC4033]). 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
skipping to change at page 13, line 8 skipping to change at page 13, line 8
document as follows: document as follows:
Multiple Ports -- The TLSA records for different application Multiple Ports -- The TLSA records for different application
services running on a single host can be distinguished through the services running on a single host can be distinguished through the
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, TLS is not attempted at all. 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 appendixes 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
skipping to change at page 13, line 30 skipping to change at page 13, line 30
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.
Combination -- Multiple TLSA records can be published for a given Combination -- Multiple TLSA records can be published for a given
host name, thus enabling the client to construct multiple TLSA host name, thus enabling the client to construct multiple TLSA
certificate associations that reflect different DANE assertions. certificate associations that reflect different DANE assertions.
No support is provided to combine two TLSA certificate No support is provided to combine two TLSA certificate
associations in a single operation. associations in a single operation.
Roll-over -- Section 4 states that applications must not cache TLSA Roll-over -- TLSA records are processed in the normal manner within
records beyond their TTL expiration. This ensures that clients the scope of DNS protocol, including the TTL expiration of the
will not latch onto assertions made by expired TLSA records, and records. This ensures that clients will not latch onto assertions
will be able to transition between using one DANE mechanism to made by expired TLSA records, and will be able to transition from
another. using one DANE public key or certificate usage type to another.
Simple Key Management -- The SubjectPublicKeyInfo selector in the Simple Key Management -- The SubjectPublicKeyInfo selector in the
TLSA record provides a mode that enables a domain holder to only TLSA record provides a mode that enables a domain holder to only
have to maintain a single long-lived public/private key pair have to maintain a single long-lived public/private key pair
without the need to manage certificates. Appendix A outlines the without the need to manage certificates. Appendix A outlines the
usefulness and the potential downsides to using this mode. usefulness and the potential downsides to using this mode.
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
skipping to change at page 14, line 17 skipping to change at page 14, line 17
specification encourages applications to use TLSA records that are specification encourages applications to use TLSA records that are
only shown to be validated. only 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
A system creating TLSA records that conforms to this specification
MUST be able to create TLSA records containing certificate usages 0,
1, 2, and 3. A system creating TLSA records that conforms to this
specification MUST be able to create TLSA records with selectors 0
(full certificate) and 1 (SubjectPublicKeyInfo). A system creating
TLSA records that conforms to this specification MUST be able to
create TLSA records using matching type 0 (no hash used) and matching
type 1 (SHA-256), and SHOULD be able to create TLSA records using
matching type 2 (SHA-512).
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 selectors type 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
In the following sections, "RFC Required" was chosen for TLSA usages
and "Specification Required" for selectors and matching types because
of the amount of detail that is likely to be needed for implementers
to correctly implement new usages as compared to new selectors and
matching types.
7.1. TLSA RRtype 7.1. TLSA RRtype
This document uses a new DNS RR type, TLSA, whose value 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
reviewer, and future versions of this document will have that value reviewer, and future versions of this document will have that value
instead of TBD. instead of TBD.
In the following sections, "RFC Required" was chosen for TLSA usages
and "Specification Required" for selectors and matching types because
of the amount of detail that is likely to be needed for implementers
to correctly implement new usages as compared to new selectors and
matching types.
7.2. TLSA Usages 7.2. TLSA Usages
This document creates a new registry, "Certificate Usages for TLSA This document creates a new registry, "Certificate Usages for TLSA
Resource Records". The registry policy is "RFC Required". The Resource Records". The registry policy is "RFC Required". The
initial entries in the registry are: initial entries in the registry are:
Value Short description Reference Value Short description Reference
---------------------------------------------------------- ----------------------------------------------------------
0 CA constraint [This] 0 CA constraint [This]
1 Service certificate constraint [This] 1 Service certificate constraint [This]
skipping to change at page 16, line 6 skipping to change at page 15, 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.
7.4. TLSA Matching Types 7.4. TLSA Matching Types
This document creates a new registry, "Matching Types for TLSA This document creates a new registry, "Matching Types for TLSA
Resource Records". The registry policy is "Specification Required". Resource Records". The registry policy is "Specification Required".
The initial entries in the registry are: The initial entries in the registry are:
Value Short description Reference Value Short description Reference
--------------------------------------------- --------------------------------------------------------
0 No hash used [This] 0 No hash used [This]
1 SHA-256 NIST FIPS 180-3 1 SHA-256 RFC 6234
2 SHA-512 NIST FIPS 180-3 2 SHA-512 RFC 6234
3-254 Unassigned 3-254 Unassigned
255 Private use 255 Private use
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 as used by the client requesting A/AAAA and the security of DNSSEC as used by the client requesting A/AAAA and
skipping to change at page 16, line 35 skipping to change at page 16, line 24
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 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 owner 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.
In these scenarios, the clients add a new trust anchor whose private In these scenarios, the clients add a new trust anchor whose private
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,
the 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 certificate trust
anchor is a matter of local policy. This specification does not anchor is a matter of local policy. This specification does not
mandate that such information be inspected or validated by the domain mandate that such information be inspected or validated by the
name administrator. server's domain name administrator.
If a server's certificate is revoked, or if an intermediate CA in a If a server's certificate is revoked, or if an intermediate CA in a
chain between the end entity and a trust anchor has its certificate chain between the end entity and a trust anchor has its certificate
revoked, a TLSA record with a certificate type of 2 that matches the revoked, a TLSA record with a certificate type of 2 that matches the
revoked certificate would in essence override the revocation because revoked certificate would in essence override the revocation because
the client would treat that revoked certificate as a trust anchor and the client would treat that revoked certificate as a trust anchor and
thus not check its revocation status. Because of this, domain thus not check its revocation status. Because of this, domain
administrators need to be responsible for being sure that the key or administrators need to be responsible for being sure that the key or
certificate used in TLSA records with a certificate type of 2 are in certificate used in TLSA records with a certificate type of 2 are in
fact able to be used as reliable trust anchors. fact able to be used as reliable trust anchors.
skipping to change at page 17, line 34 skipping to change at page 17, line 23
allows an intermediate CA to be come a trust anchor for certificates allows an intermediate CA to be come a trust anchor for certificates
that the end user might have expected to chain to an existing trust that the end user might have expected to chain to an existing trust
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
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
which the TLSA query was made, local policy may deny the trust or
further restrict the conditions under which that trust is permitted.
8.1. DNS Caching 8.1. 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 TLSA records/ be cautious in assuming the continuing validity of an assocation
DNS name association. between a TLSA record and a DNS name.
In particular, implementations SHOULD rely on their DNS resolver for In particular, implementations SHOULD rely on their DNS resolver for
confirmation of an association between a TLSA record and a DNS name, confirmation of an association between a TLSA record and a DNS name,
rather than caching the result of previous domain name lookups. Many rather than caching the result of previous domain name lookups. Many
platforms already can cache domain name lookups locally when platforms already can cache domain name lookups locally when
appropriate, and they SHOULD be configured to do so. It is proper appropriate, and they SHOULD be configured to do so. It is proper
for these lookups to be cached, however, only when the TTL (Time To for these lookups to be cached, however, only when the TTL (Time To
Live) information reported by the DNS makes it likely that the cached Live) information reported by the DNS makes it likely that the cached
information will remain useful. information will remain useful.
If implementations cache the results of domain name lookups in order If implementations cache the results of domain name lookups in order
to achieve a performance improvement, they MUST observe the TTL to achieve a performance improvement, they MUST observe the TTL
information reported by DNS. Implementations that fail to follow information reported by DNS. Implementations that fail to follow
this rule this rule could be spoofed when a previously-accessed this rule could be spoofed or have access denied when a previously-
server's TLSA record changes, such as during a certificate rollover. accessed server's TLSA record changes, such as during a certificate
rollover.
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
skipping to change at page 19, line 46 skipping to change at page 19, line 40
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006. RFC 4641, September 2006.
[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
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 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.
skipping to change at page 21, line 48 skipping to change at page 21, line 47
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 should be noted: creating a TLSA association to
certificate I1 that directly signed end entity certificate S1 of the CA certificate I1 that directly signed end entity certificate S1 of
server. Since the key used to sign S1 is fixed, association to I1 the server. The case can be illustrated by following graph:
must succeed: if a client swaps I1 for I2 (a different certificate),
its SPKI must match SPKI of I1. Such and association would not +----+ +----+
suffer from a false-negative failure on client's side if the client | I1 | | I2 |
uses a reissued CA certificate I2 in place of I1. +----+ +----+
| |
v v
+----+ +----+
| S1 | | S1 |
+----+ +----+
Certificate chain sent by A different validation path
server in TLS handshake built by the TLS client
I2 is a reissued version of CA certificate I1 (that is, it has a
different hash in its signature algorithm).
In the above scenario, both certificates I1 and I2 that sign S1 need
to have identical SubjectPublicKeyInfos because the key used to sign
S1 is fixed. An association to SubjectPublicKeyInfo (selector type
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
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 the CA not to engage in bad o The administrator must know or trust that the CA does not engage
practices, such as not sharing key of I1 for unrelated CA in bad practices, such as not sharing key of I1 for unrelated CA
certificates leading to trust-chain redirect. If possible, the certificates leading to trust-chain redirect. If possible, the
administrator should review all CA certificates that have the same administrator should review all CA certificates that have the same
SPKI. SPKI.
o The administrator should understand whether some PKIX extension o The administrator should 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 should review all CA certificates that share the
SubjectPublicKeyInfo. SubjectPublicKeyInfo.
o The administrator should understand that any CA could, in the
future, issue a certificate that contains the same
SubjectPublicKeyInfo. Therefore, new chains can crop up in the
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.
A.2. Provisioning TLSA Records in DNS A.2. Provisioning TLSA Records in DNS
A.2.1. Provisioning TLSA Records with Aliases A.2.1. Provisioning TLSA Records with Aliases
skipping to change at page 26, line 43 skipping to change at page 27, line 21
exit exit
} }
// unreachable // unreachable
} }
// implement the selector function // implement the selector function
function Select (S, X) = { function Select (S, X) = {
// Full certificate // Full certificate
if (S == 0) { if (S == 0) {
return X return X in DER encoding
} }
// SubjectPublicKeyInfo // SubjectPublicKeyInfo
if (S == 1) { if (S == 1) {
return X.SubjectPublicKeyInfo return X.SubjectPublicKeyInfo in DER encoding
} }
// unreachable // unreachable
} }
// implement the matching function // implement the matching function
function Match (M, X, Y) { function Match (M, X, Y) {
// Exact match on selected content // Exact match on selected content
if (M == 0) { if (M == 0) {
return (X == Y) return (X == Y)
} }
// SHA-256 hash of selected content // SHA-256 hash of selected content
skipping to change at page 28, line 46 skipping to change at page 29, line 23
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 certificaten 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 for each PKIX certification path H that has R as the
trust anchor { trust anchor {
if (C passes PKIX certification validation in H) and if (C passes PKIX certification 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)
} }
} }
 End of changes. 38 change blocks. 
81 lines changed or deleted 103 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/