draft-ietf-dane-protocol-12.txt   draft-ietf-dane-protocol-13.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: March 30, 2012 Kirei AB Expires: June 21, 2012 Kirei AB
September 27, 2011 December 19, 2011
Using Secure DNS to Associate Certificates with Domain Names For TLS Using Secure DNS to Associate Certificates with Domain Names For TLS
draft-ietf-dane-protocol-12 draft-ietf-dane-protocol-13
Abstract Abstract
TLS and DTLS use PKIX certificates for authenticating the server. TLS and DTLS use PKIX certificates for authenticating the server.
Users want their applications to verify that the certificate provided Users want their applications to verify that the certificate provided
by the TLS server is in fact associated with the domain name they by the TLS server is in fact associated with the domain name they
expect. TLSA provides bindings of keys to domains that are asserted expect. TLSA provides bindings of keys to domains that are asserted
not by external entities, but by the entities that operate the DNS. not by external entities, but by the entities that operate the DNS.
This document describes how to use secure DNS to associate the TLS This document describes how to use secure DNS to associate the TLS
server's certificate with the intended domain name. server's certificate with the intended domain name.
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 March 30, 2012. This Internet-Draft will expire on June 21, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Certificate Associations . . . . . . . . . . . . . . . . . 3 1.1. Certificate Associations . . . . . . . . . . . . . . . . . 3
1.2. Securing Certificate Associations . . . . . . . . . . . . 4 1.2. Securing Certificate Associations . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 4 2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 4
2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 5
2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 5 2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 5
2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 6 2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 5
2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 6 2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 6
2.1.4. The Certificate for Association Field . . . . . . . . 6 2.1.4. The Certificate for Association Field . . . . . . . . 6
2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 6 2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 6
2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 7 2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 7
3. Domain Names for TLS Certificate Associations . . . . . . . . 7 3. Domain Names for TLS Certificate Associations . . . . . . . . 7
4. Semantics and Features of TLSA Certificate Usages . . . . . . 8 4. Semantics and Features of TLSA Certificate Usages . . . . . . 8
4.1. Pass PKIX Validation and Chain Through CA . . . . . . . . 8 4.1. Pass PKIX Validation and Chain Through CA . . . . . . . . 8
4.2. Pass PKIX Validation and Match End Entity Certificate . . 8 4.2. Pass PKIX Validation and Match End Entity Certificate . . 8
4.3. Pass PKIX Validation and Use Trust Anchor . . . . . . . . 8 4.3. Pass PKIX Validation and Use Trust Anchor . . . . . . . . 8
4.4. Use of TLS Certificate Associations in TLS . . . . . . . . 8 4.4. Use of TLS Certificate Associations in TLS . . . . . . . . 8
skipping to change at page 2, line 41 skipping to change at page 2, line 41
7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 11 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 11
7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 12 7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Operational Considerations for Deploying TLSA Appendix A. Operational Considerations for Deploying TLSA
Records . . . . . . . . . . . . . . . . . . . . . . . 14 Records . . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Provisioning TLSA Records with Aliases . . . . . . . . . . 14 A.1. Provisioning TLSA Records with Aliases . . . . . . . . . . 15
A.1.1. Provisioning TLSA Records with CNAME Records . . . . . 15 A.1.1. Provisioning TLSA Records with CNAME Records . . . . . 15
A.1.2. Provisioning TLSA Records with DNAME Records . . . . . 16 A.1.2. Provisioning TLSA Records with DNAME Records . . . . . 17
A.1.3. Provisioning TLSA Records with Wildcards . . . . . . . 16 A.1.3. Provisioning TLSA Records with Wildcards . . . . . . . 17
A.2. Provisioning Using NS Records . . . . . . . . . . . . . . 17 A.2. Provisioning Using NS Records . . . . . . . . . . . . . . 17
A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 17 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 17
A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 17 A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 17
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 17 Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The first response from the server in TLS may contain a certificate. The first response from the server in TLS may contain a certificate.
In order for the TLS client to authenticate that it is talking to the In order for the TLS client to authenticate that it is talking to the
expected TLS server, the client must validate that this certificate expected TLS server, the client must validate that this certificate
is associated with the domain name used by the client to get to the is associated with the domain name used by the client to get to the
server. Currently, the client must extract the domain name from the server. Currently, the client must extract the domain name from the
certificate, must trust a trust anchor upon which the server's certificate, must trust a trust anchor upon which the server's
certificate is rooted, and must successfully validate the certificate is rooted, and must successfully validate the
skipping to change at page 3, line 42 skipping to change at page 3, line 42
In order to make the document more readable, it mostly only talks In order to make the document more readable, it mostly only talks
about "TLS", but in all cases, it means "TLS or DTLS". This document about "TLS", but in all cases, it means "TLS or DTLS". This document
only relates to securely associating certificates for TLS and DTLS only relates to securely associating certificates for TLS and DTLS
with host names; other security protocols and other forms of with host names; other security protocols and other forms of
identification of TLS servers (such as IP addresses) are handled in identification of TLS servers (such as IP addresses) are handled in
other documents. For example, keys for IPsec are covered in other documents. For example, keys for IPsec are covered in
[RFC4025] and keys for SSH are covered in [RFC4255]. [RFC4025] and keys for SSH are covered in [RFC4255].
1.1. Certificate Associations 1.1. Certificate Associations
In this document, a certificate association is based on a A certificate association is formed from a piece of information
cryptographic hash of a certificate (sometimes called a identifying a certificate with the domain name where the data is
"fingerprint"), a public key, or on the certificate itself. For a found. The data used to identify the certificate consists of either
fingerprint, a hash is taken of the binary, DER-encoded certificate a PKIX certificate or a hash of a PKIX certificate. When using the
or public key, and that hash is the certificate association; the type certificate itself in the certificate association, the entire
of hash function used can be chosen by the DNS administrator. When certificate in the normal format is used. This document only applies
using the certificate itself in the certificate association, the to PKIX [RFC5280] certificates, not certificates of other formats.
entire certificate in the normal format is used. This document only
applies to PKIX [RFC5280] certificates, not certificates of other
formats. It also applies to public keys that are extracted from PKIX
certificates, not just full certificates.
Certificate associations are made between a certificate or public key A DNS query can return multiple certificate associations, such as in
and a domain name. Server software that is running TLS that is found the case of different server software on a single host using
at that domain name would use a certificate that has a certificate different certificates, or in the case that a server is changing from
association given in the DNS, as described in this document. A DNS one certificate to another.
query can return multiple certificate associations, such as in the
case of different server software on a single host using different
certificates, or in the case that a server is changing from one
certificate to another.
1.2. Securing Certificate Associations 1.2. Securing Certificate Associations
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 may need to be be protected by DNSSEC. Because the DNS information needs to be be protected by DNSSEC. Because the
the certificate association was retrieved based on a DNS query, the certificate association was retrieved based on a DNS query, the
domain name in the query is by definition associated with the domain name in the query is by definition associated with the
certificate. certificate.
DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033],
[RFC4034], and [RFC4035]), uses cryptographic keys and digital [RFC4034], and [RFC4035]), uses cryptographic keys and digital
signatures to provide authentication of DNS data. Information signatures to provide authentication of DNS data. Information
retrieved from the DNS and that is validated using DNSSEC is thereby retrieved from the DNS and that is validated using DNSSEC is thereby
proved to be the authoritative data. The DNSSEC signature MUST be proved to be the authoritative data. The DNSSEC signature MUST be
validated on all responses that use DNSSEC in order to assure the validated on all responses that use DNSSEC in order to assure the
proof of origin of the data. This document does not specify how proof of origin of the data. This document does not specify how
skipping to change at page 5, line 15 skipping to change at page 5, line 8
The type value for the TLSA RR type is TBD. The type value for the TLSA RR type is TBD.
The TLSA RR is class independent. The TLSA RR is class independent.
The TLSA RR has no special TTL requirements. The TLSA RR has no special TTL requirements.
2.1. TLSA RDATA Wire Format 2.1. TLSA RDATA Wire Format
The RDATA for a TLSA RR consists of a one octet usage type field, a The RDATA for a TLSA RR consists of a one octet usage type field, a
one octet selector field, o one octet matching type field and the one octet selector field, a one octet matching type field and the
certificate for association field. certificate for association field.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Usage | Selector | Matching Type | / | Usage | Selector | Matching Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ / / /
/ Certificate for Association / / Certificate for Association /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1. The Certificate Usage Field 2.1.1. The Certificate Usage Field
A one-octet value, called "certificate usage" or just "usage", A one-octet value, called "certificate usage" or just "usage",
specifying the provided association that will be used to match the specifying the provided association that will be used to match the
target certificate. This will be an IANA registry in order to make target certificate from TLS. This will be an IANA registry in order
it easier to add additional certificate usages in the future. The to make it easier to add additional certificate usages in the future.
usages defined in this document are: The usages defined in this document are:
0 -- Certificate MUST pass PKIX validation and MUST chain through 0 -- The target certificate MUST pass PKIX validation and MUST
a CA certificate matching the TLSA record chain through a CA certificate matching the TLSA record
1 -- Certificate MUST pass PKIX validation and MUST match the TLSA 1 -- The target certificate MUST pass PKIX validation and MUST
record match the TLSA record
2 -- Certificate MUST pass PKIX validation, with any certificate 2 -- The target certificate MUST pass PKIX validation, with any
matching the TLSA record considered to be a trust anchor for this certificate matching the TLSA record considered to be a trust
validation anchor for this validation
The three certificate usages defined in this document explicitly only The three certificate usages defined in this document explicitly only
apply to PKIX-formatted certificates. If TLS allows other formats apply to PKIX-formatted certificates. If TLS allows other formats
later, or if extensions to this protocol are made that accept other later, or if extensions to this protocol are made that accept other
formats for certificates, those certificates will need their own formats for certificates, those certificates will need their own
certificate types. certificate types.
The use of this field is described in greater detail in Section 4.
2.1.2. The Selector Field 2.1.2. The Selector Field
A one-octet value, called "selector", specifying what will be A one-octet value, called "selector", specifying what will be
matched. This value is defined in a new IANA registry. The matched. This value is defined in a new IANA registry. The
selectors defined in this document are: selectors defined in this document are:
0 -- Full certificate 0 -- Full certificate
1 -- SubjectPublicKeyInfo 1 -- SubjectPublicKeyInfo
skipping to change at page 6, line 33 skipping to change at page 6, line 27
1 -- SHA-256 hash of selected content 1 -- SHA-256 hash of selected content
2 -- SHA-512 hash of selected content 2 -- SHA-512 hash of selected content
Using the same hash algorithm as is used in the signature in the Using the same hash algorithm as is used in the signature in the
certificate will make it more likely that the TLS client will certificate will make it more likely that the TLS client will
understand this TLSA data. understand this TLSA data.
2.1.4. The Certificate for Association Field 2.1.4. The Certificate for Association Field
The "certificate for association". This is the bytes containing the The "association data" to be matched. The field contains the bytes
full certificate, SubjectPublicKeyInfo or the hash of the associated to be matched or the hash of the bytes to be matched. The source of
certificate or SubjectPublicKeyInfo. This is the certificate or the the data to be matched is controlled by the Matching Type field. The
hash of the certificate itself, not of the TLS ASN.1 Certificate data refers to the certificate in the association, not to the TLS
object. ASN.1 Certificate object.
2.2. TLSA RR Presentation Format 2.2. TLSA RR Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
o The certificate usage field MUST be represented as an unsigned o The certificate usage field MUST be represented as an unsigned
decimal integer. decimal integer.
o The selector field MUST be represented as an unsigned decimal o The selector field MUST be represented as an unsigned decimal
integer. integer.
skipping to change at page 9, line 11 skipping to change at page 9, line 7
number and transport name that was given in the TLSA query. The number and transport name that was given in the TLSA query. The
matching or chaining MUST be done within the life of the TTL on the matching or chaining MUST be done within the life of the TTL on the
TLSA record. TLSA record.
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 at [RFC6125] detail how to match the identify specifications such at [RFC6125] detail how to match the identify
given in a PKIX certificate with those expected by the user. given in a PKIX certificate with those expected by the user.
In order to use one or more TLS certificate associations described in An application that complies with this document first requests TLSA
this document obtained from the DNS, an application MUST assure that records in order to make certificate associations.
the certificates were obtained using DNS protected by DNSSEC. TLSA
records must only be trusted if they were obtained from a trusted Determining whether a TLSA RRset can be used depends on the DNSSEC
source. This could be a localhost DNS resolver answer with the AD validation state (as defined in [RFC4033]).
bit set, an inline validating resolver library primed with the proper
trust anchors, or obtained from a remote name server to which one has o A TLSA RRset whose DNSSEC validation state is secure MUST be used
a secured channel of communication. as a certificate association for TLS unless a local policy would
prohibit the use of the specific certificate association in the
secure TLSA RRset.
o If the DNSSEC validation state on the response to the request for
the TLSA RRset is bogus, this MUST cause TLS not to be started or,
if the TLS negotiation is already in progress, to cause the
connection to be aborted.
o A TLSA RRset whose DNSSEC validation state is indeterminate or
insecure cannot be used for TLS and MUST be marked as unusable.
Clients that validate the DNSSEC signatures themselves SHOULD use
standard DNSSEC validation procedures. Clients that do not validate
the DNSSEC signatures themselves MUST use a secure transport (e.g.,
TSIG [RFC2845], SIG(0) [RFC2931], or IPsec [RFC6071]) between
themselves and the entity performing the signature validation.
If a certificate association contains a certificate usage, selector, If a certificate association contains a certificate usage, selector,
or matching type that is not understood by the TLS client, that or matching type that is not understood by the TLS client, that
certificate association MUST be marked as unusable. If the certificate association MUST be marked as unusable. If the
comparison data for a certificate is malformed, the certificate comparison data for a certificate is malformed, the certificate
association MUST be marked as unusable. association MUST be marked as unusable.
An application that complies with this document first requests TLSA
records in order to make certificate associations. If that
application receives zero usable certificate associations, it
processes TLS in the normal fashion; otherwise, that application
attempts to match each certificate association with the TLS server's
end entity certificate. If such a match is found, that application
continues the TLS handshake and ignores any remaining certificate
associations; otherwise, that application MUST abort the TLS
handshake with an "access_denied" error.
5. TLSA and DANE Use Cases and Requirements 5. TLSA and DANE Use Cases and Requirements
The different types of certificates for association defined in TLSA The different types of certificates for association defined in TLSA
are matched with various sections of [DANEUSECASES]. The three use are matched with various sections of [DANEUSECASES]. The three use
cases from section 3 of [DANEUSECASES] are covered in this protocol cases from section 3 of [DANEUSECASES] are covered in this protocol
as follows: as follows:
3.1 CA Constraints -- Implemented using certificate usage 0. 3.1 CA Constraints -- Implemented using certificate usage 0.
3.2 Certificate Constraints -- Implemented using certificate usage 3.2 Certificate Constraints -- Implemented using certificate usage
skipping to change at page 10, line 17 skipping to change at page 10, line 22
Multiple Ports -- Covered in the TLSA request syntax. Multiple Ports -- Covered in the TLSA request syntax.
No Downgrade -- Covered by DNSSEC itself. No Downgrade -- Covered by DNSSEC itself.
Encapsulation -- Covered in the TLSA response semantics. Encapsulation -- Covered in the TLSA response semantics.
Predictability -- Covered by this spec. Predictability -- Covered by this spec.
Opportunistic Security -- Covered in the TLSA request syntax. Opportunistic Security -- Covered in the TLSA request syntax.
Combination -- Covered in the TLSA response semantics. Combination -- Covered in the TLSA response semantics. No support
is provided to combine two TLSA certificate associations in a
single operation. Support exists for having multiple TLSA
certificate associations that are treated independently.
Roll-over -- Covered by the TTLs on the TLSA records. Roll-over -- Covered by the TTLs on the TLSA records.
Simple Key Management -- Implemented using the SubjectPublicKeyInfo Simple Key Management -- Implemented using the SubjectPublicKeyInfo
selector. selector.
Minimal Dependencies -- Covered in the TLSA response semantics. Minimal Dependencies -- Covered in the TLSA response semantics.
Minimal Options -- Covered in the TLSA response semantics. Minimal Options -- Covered in the TLSA response semantics.
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 Algorithms 6. Mandatory-to-Implement Algorithms
DNS systems conforming to this specification MUST be able to create A system creating TLSA records that conforms to this specification
TLSA records containing certificate usages 0, 1 and 2. DNS systems MUST be able to create TLSA records containing certificate usages 0,
conforming to this specification MUST be able to create TLSA records 1 and 2. A system creating TLSA records that conforms to this
with selectors 0 (full certificate) and 1 (SubjectPublicKeyInfo). specification MUST be able to create TLSA records with selectors 0
DNS systems conforming to this specification MUST be able to create (full certificate) and 1 (SubjectPublicKeyInfo). A system creating
TLSA records using matching type 0 (no hash used) and matching type 1 TLSA records that conforms to this specification MUST be able to
(SHA-256), and SHOULD be able to create TLSA records using matching create TLSA records using matching type 0 (no hash used) and matching
type 2 (SHA-512). 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 and 2. correctly interpret TLSA records with certificate usages 0, 1 and 2.
TLS clients conforming to this specification MUST be able to compare TLS clients conforming to this specification MUST be able to compare
a certificate for association with a certificate from TLS using a certificate for association with a certificate from TLS using
selectors type 0 and 1, and matching type 0 (no hash used) and 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 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
skipping to change at page 13, line 14 skipping to change at page 13, line 21
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. Thus, for the supposed destination will not set up a TLS session. Thus,
such proxies might choose to aggressively block TLSA requests and/or such proxies might choose to aggressively block TLSA requests and/or
responses. responses.
Client treatment of any information included in the trust anchor is a Client treatment of any information included in the trust anchor is a
matter of local policy. This specification does not mandate that matter of local policy. This specification does not mandate that
such information be inspected or validated by the domain name such information be inspected or validated by the domain name
administrator. administrator.
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
revoked, a TLSA record with a certificate type of 2 that matches the
revoked certificate would in essence override the revocation because
the client would treat that revoked certificate as a trust anchor and
thus not check its revocation status. Because of this, domain
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
fact able to be used as reliable trust anchors.
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 here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges,
Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben
Laurie, Ilari Liusvaara, Scott Schmit, Ondrej Sury, Richard Barnes, Laurie, Ilari Liusvaara, Scott Schmit, Ondrej Sury, Richard Barnes,
and Jim Schaad. and Jim Schaad.
skipping to change at page 14, line 32 skipping to change at page 14, line 49
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
10.2. Informative References 10.2. Informative References
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
January 2006. January 2006.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
February 2011.
Appendix A. Operational Considerations for Deploying TLSA Records Appendix A. Operational Considerations for Deploying TLSA Records
A.1. Provisioning TLSA Records with Aliases A.1. Provisioning TLSA Records with Aliases
The TLSA resource record is not special in the DNS; it acts exactly The TLSA resource record is not special in the DNS; it acts exactly
like any other RRtype where the queried name has one or more labels like any other RRtype where the queried name has one or more labels
prefixed to the base name, such as the SRV RRtype [RFC2782]. This prefixed to the base name, such as the SRV RRtype [RFC2782]. This
affects the way that the TLSA resource record is used when aliasing affects the way that the TLSA resource record is used when aliasing
in the DNS. in the DNS.
skipping to change at page 17, line 25 skipping to change at page 18, line 7
A.4. Handling Certificate Rollover A.4. Handling Certificate Rollover
[[ Need to add text here about how to handle a change in certificate. [[ Need to add text here about how to handle a change in certificate.
It would cover using two TLSA records at the same time, the TTL on It would cover using two TLSA records at the same time, the TTL on
the RRset, and coordinating that with the use of the certificates in the RRset, and coordinating that with the use of the certificates in
the TLS server. ]] the TLS server. ]]
Appendix B. Pseudocode for Using TLSA Appendix B. Pseudocode for Using TLSA
[[ IMPORTANT NOTE FOR THE DANE WG: Please review this new appendix
carefully. If you find differences between what is here and what is
in the rest of the draft, by all means please send it to the WG
mailing list. The ensuing discussion will hopefully help everyone.
]]
This appendix describes the interactions given earlier in this This appendix describes the interactions given earlier in this
specification in pseudocode format. This appendix is non-normative. specification in pseudocode format. This appendix is non-normative.
If the steps below disagree with the text earlier in the document, If the steps below disagree with the text earlier in the document,
the steps earlier in the document should be considered correct and the steps earlier in the document should be considered correct and
this text incorrect. this text incorrect.
TLS connect using [transport] to [hostname] on [port] and TLS connect using [transport] to [hostname] on [port] and
receiving end entity cert C for the TLS server: receiving end entity cert C for the TLS server:
look up TLSA for _[port]._[transport].[hostname] (TLSArecords, ValState) = DNSSECValidatedLookup(
name=_[port]._[transport].[hostname], RRtype=TLSA, class=IN)
if (no secure TLSA record(s) received) { // check for states that would change processing
fall back to non-TLSA cert validation if (ValState == BOGUS) {
abort or prevent TLS handshake
} }
if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
fall back to non-TLSA certificate validation
}
// if here, ValState must be SECURE
// unusable records include unknown certUsage, unknown selectorType, for each R in TLSArecords {
// unknown matchingType, and erroneous RDATA // unusable records include unknown certUsage, unknown
strip unusable records // selectorType, unknown matchingType, and erroneous RDATA
if (no usable TLSA record(s) received) { if R is unusable, remove it from TLSArecords
fall back to non-TLSA cert validation
} }
if (length(TLSArecords) == 0) {
fall back to non-TLSA certificate validation
}
// implement the selector function // implement the selector function
function Select(S, X) = { function Select(S, X) = {
if (S == 0) { if (S == 0) {
return X return X
} }
if (S == 1) { if (S == 1) {
return X.SubjectPublicKey return X.SubjectPublicKey
} }
return undef return undef
} }
skipping to change at page 18, line 36 skipping to change at page 19, line 20
return undef return undef
} }
// A TLS client might have multiple trust anchors that it might use // A TLS client might have multiple trust anchors that it might use
// when validating the TLS server's end entity certificate. Also, // when validating the TLS server's end entity certificate. Also,
// there can be multiple PKIX validation chains for the // there can be multiple PKIX validation chains for the
// certificates given by the server in TLS. Thus, there are // certificates given by the server in TLS. Thus, there are
// possibly many chains that might need to be tested during // possibly many chains that might need to be tested during
// PKIX validation. // PKIX validation.
for each TLSA record R { for each R in TLSArecords {
// pass PKIX validation and chain through CA cert from TLSA // pass PKIX validation and chain through CA cert from TLSA
if (R.certUsage == 0) { if (R.certUsage == 0) {
for each PKIX validation chain H { for each PKIX validation chain H {
if (C passes PKIX validation in H) { if (C passes PKIX validation in H) {
for each D in H { for each D in H {
if (D is a CA certificate) and if (D is a CA certificate) and
Match(matchingType, Select(selectorType, D), R) { Match(matchingType, Select(selectorType, D), R) {
accept the TLS connection accept the TLS connection
} }
skipping to change at page 19, line 20 skipping to change at page 20, line 4
} }
} }
} }
// pass PKIX validation using TLSA record as trust anchor // pass PKIX validation using TLSA record as trust anchor
if (R.certUsage == 2) { if (R.certUsage == 2) {
for each PKIX validation chain H that has R as the trust anchor { for each PKIX validation chain H that has R as the trust anchor {
if (C passes PKIX validation in H) { if (C passes PKIX validation in H) {
accept the TLS connection accept the TLS connection
} }
} }
} }
} }
abort TLS handshake with "access_denied" error. // if here, the TLS connection was not accepted above
abort or prevent TLS handshake
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
Jakob Schlyter Jakob Schlyter
Kirei AB Kirei AB
 End of changes. 33 change blocks. 
91 lines changed or deleted 121 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/