draft-ietf-dane-protocol-10.txt   draft-ietf-dane-protocol-11.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: February 16, 2012 Kirei AB Expires: March 10, 2012 Kirei AB
August 15, 2011 September 7, 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-10 draft-ietf-dane-protocol-11
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 February 16, 2012. This Internet-Draft will expire on March 10, 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 16 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
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 Type Field . . . . . . . . . . . . . . 5 2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 5
2.1.2. The Reference Type Field . . . . . . . . . . . . . . . 6 2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 6
2.1.3. The Certificate for Association Field . . . . . . . . 6 2.1.3. The Matching Type 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 . . . . . . . . . . . . . . . . . . . . . 6 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 Types . . . . . . . 7 4. Semantics and Features of TLSA Certificate Usages . . . . . . 8
4.1. End Entity Certificate . . . . . . . . . . . . . . . . . . 7 4.1. Pass PKIX Validation and Chain Through CA . . . . . . . . 8
4.2. Certification Authority Certificate . . . . . . . . . . . 8 4.2. Pass PKIX Validation and Match End Entity Certificate . . 8
4.3. Certificate Public Key . . . . . . . . . . . . . . . . . . 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
5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 9 5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 9
6. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 10 6. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. TLSA Certificate Types . . . . . . . . . . . . . . . . . . 11 7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. TLSA Hash Types . . . . . . . . . . . . . . . . . . . . . 11 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . 14 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 . . . . . 16
A.1.3. Provisioning TLSA Records with Wildcards . . . . . . . 16 A.1.3. Provisioning TLSA Records with Wildcards . . . . . . . 17
A.2. Securing the Last Hop . . . . . . . . . . . . . . . . . . 16 A.2. Provisioning Using NS Records . . . . . . . . . . . . . . 17
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 16 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 17
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 5, line 14 skipping to change at page 5, line 14
the TLSA RR is interpreted are given later in this document. the TLSA RR is interpreted are given later in this document.
The type value for the TLSA RR type is TBD. The type value for the TLSA RR type is 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 certificate type The RDATA for a TLSA RR consists of a one octet usage type field, a
field, a one octet reference type field and the certificate for one octet selector field, o one octet matching type field and the
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert type | Ref type | / | Usage | Selector | Matching Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ / / /
/ Certificate for association / / Certificate for Association /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1. The Certificate Type Field 2.1.1. The Certificate Usage Field
A one-octet value, called "certificate type", specifying the provided
association that will be used to match the target certificate. This
will be an IANA registry in order to make it easier to add additional
certificate types in the future. The types defined in this document
are:
1 -- A PKIX certificate that identifies an end entity A one-octet value, called "certificate usage" or just "usage",
specifying the provided association that will be used to match the
target certificate. This will be an IANA registry in order to make
it easier to add additional certificate usages in the future. The
usages defined in this document are:
2 -- A PKIX certification authority's certificate 0 -- Certificate MUST pass PKIX validation and MUST chain through
a CA certificate matching the TLSA record
3 -- A public key expressed as a PKIX SubjectPublicKeyInfo 1 -- Certificate MUST pass PKIX validation and MUST match the TLSA
structure record
All three types are structured using the RFC 5280 formatting rules 2 -- Certificate MUST pass PKIX validation, with any certificate
and use the DER encoding. matching the TLSA record considered to be a trust anchor for this
validation
The three certificate types 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.
2.1.2. The Reference Type Field 2.1.2. The Selector Field
A one-octet value, called "reference type", specifying how the A one-octet value, called "selector", specifying what will be
matched. This value is defined in a new IANA registry. The
selectors defined in this document are:
0 -- Full certificate
1 -- SubjectPublicKeyInfo
2.1.3. The Matching Type Field
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. The types defined in this document are: IANA registry. The types defined in this document are:
0 -- Full certificate 0 -- Exact match on selected content
1 -- SHA-256 hash of the certificate 1 -- SHA-256 hash of selected content
2 -- SHA-512 hash of the certificate 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.3. The Certificate for Association Field 2.1.4. The Certificate for Association Field
The "certificate for association". This is the bytes containing the The "certificate for association". This is the bytes containing the
full certificate, SubjectPublicKeyInfo or the hash of the associated full certificate, SubjectPublicKeyInfo or the hash of the associated
certificate or SubjectPublicKeyInfo. For certificate types 1 and 2, certificate or SubjectPublicKeyInfo. This is the certificate or the
this is the certificate or the hash of the certificate itself, not of hash of the certificate itself, not of the TLS ASN.1 Certificate
the TLS ASN.1 Cert object. 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 type field MUST be represented as an unsigned o The certificate usage field MUST be represented as an unsigned
decimal integer. decimal integer.
o The reference type field MUST be represented as an unsigned o The selector field MUST be represented as an unsigned decimal
decimal integer. integer.
o The matching type field MUST be represented as an unsigned decimal
integer.
o The certificate for association field MUST be represented as a o The certificate for association field MUST be represented as a
string of hexadecimal characters. Whitespace is allowed within string of hexadecimal characters. Whitespace is allowed within
the string of hexadecimal characters. the string of hexadecimal characters.
2.3. TLSA RR Examples 2.3. TLSA RR Examples
An example of a SHA-256 hash (type 1) of an end entity certificate An example of a hashed (SHA-256) association of a PKIX CA
(type 1) would be: certificate:
_443._tcp.www.example.com. IN TLSA ( _443._tcp.www.example.com. IN TLSA (
1 1 5c1502a6549c423be0a0aa9d9a16904de5ef0f5c98 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
c735fcca79f09230aa7141 ) 7983a1d16e8a410e4561cb106618e971 )
An example of an unhashed CA certificate (type 2) would be: An example of a hashed (SHA-512) subject public key association of a
PKIX end entity certificate:
_443._tcp.www.example.com. IN TLSA ( _443._tcp.www.example.com. IN TLSA
2 0 308202c5308201ada00302010202090... ) 1 1 2 92003ba34942dc74152e2f2c408d29ec
a5a520e7f2e06bb944f4dca346baf63c
1b177615d466f6c4b71c216a50292bd5
8c9ebdd2f74e38fe51ffd48c43326cbc )
An example of a full certificate association of a PKIX trust anchor:
_443._tcp.www.example.com. IN TLSA
2 0 0 30820307308201efa003020102020... )
3. Domain Names for TLS Certificate Associations 3. Domain Names for TLS Certificate Associations
TLSA resource records are stored at a prefixed DNS domain name. The TLSA resource records are stored at a prefixed DNS domain name. The
prefix is prepared in the following manner: prefix is prepared in the following manner:
1. The decimal representation of the port number on which a TLS- 1. The decimal representation of the port number on which a TLS-
based service is assumed to exist is prepended with an underscore based service is assumed to exist is prepended with an underscore
character ("_") to become the left-most label in the prepared character ("_") to become the left-most label in the prepared
domain name. This number has no leading zeros. domain name. This number has no leading zeros.
skipping to change at page 7, line 34 skipping to change at page 8, line 10
3. The domain name is appended to the result of step 2 to complete 3. The domain name is appended to the result of step 2 to complete
the prepared domain name. the prepared domain name.
For example, to request a TLSA resource record for an HTTP server For example, to request a TLSA resource record for an HTTP server
running TLS on port 443 at "www.example.com", you would use running TLS on port 443 at "www.example.com", you would use
"_443._tcp.www.example.com" in the request. To request a TLSA "_443._tcp.www.example.com" in the request. To request a TLSA
resource record for an SMTP server running the STARTTLS protocol on resource record for an SMTP server running the STARTTLS protocol on
port 25 at "mail.example.com", you would use port 25 at "mail.example.com", you would use
"_25._tcp.mail.example.com". "_25._tcp.mail.example.com".
4. Semantics and Features of TLSA Certificate Types 4. Semantics and Features of TLSA Certificate Usages
The three certificate types have very different semantics, but also The three certificate usages have very different semantics, but also
have features common to all three types. have features common to all three types.
4.1. End Entity Certificate 4.1. Pass PKIX Validation and Chain Through CA
Certificate type 1 (a certificate that identifies an end entity) is
matched against the first certificate offered by the TLS server. The
certificate for association is used only for exact matching, not for
chained validation. With reference type 0, the certificate
association is valid if the certificate in the TLSA data matches to
the first certificate offered by TLS. With reference types other
than 0, the certificate association is valid if the hash of the first
certificate offered by the TLS server matches the value from the TLSA
data.
4.2. Certification Authority Certificate
Certificate type 2 (certification authority's certificate) can be
used in one of two ways. With reference type 0, the certificate in
the TLSA resource record is used in chaining from the end entity
given in TLS. The certificate association is valid if the first
certificate in the certificate bundle can be validly chained to the
trust anchor from the TLSA data. With reference types other than 0,
if the hash of any certificate past the first in the certificate
bundle from TLS matches the trust anchor from the TLSA data, and the
chain in the certificate bundle is valid up to that TLSA trust
anchor, then the certificate association is valid. Alternately, if
the first certificate offered chains to an existing trust anchor in
the TLS client's trust anchor repository, and the hash of that trust
anchor matches the value from the TLSA data, then the certificate
association is valid.
4.3. Certificate Public Key Certificate usage 0 is used to specify a CA certificate, or the
public key of such a certificate, that the must be found in any of
the PKIX validation chains for the end entity certificate given by
the server in TLS. This usage is sometimes referred to as "CA
constraint" because it limits which CA can be used to issue
certificates for a given host name.
Certificate type 3 (public key expressed as a PKIX 4.2. Pass PKIX Validation and Match End Entity Certificate
SubjectPublicKeyInfo structure) is used to assert that the public key
will appear in one of the certificates received from the server. A
server might choose this type for many reasons, including (but not
limited to):
o the trust anchor to which TLS server's certificate chains might Certificate usage 1 is used to specify an end entity certificate, or
change without the trust anchor's public key changing the public key of such a certificate, that must be matched with the
end entity certificate given by the server in TLS. This usage is
sometimes referred to as "service certificate constraints" because it
limits which end entity certificate may be used by a given host name.
o the TLS server is using a self-signed certificate that is not 4.3. Pass PKIX Validation and Use Trust Anchor
marked as a CA certificate
A TLS client conforming to this protocol that receives a public key Certificate usage 2 is used to specify a certificate, or the public
in a type 3 certificate for association must be able to extract the key of such a certificate, that must be used as a trust anchor when
SubjectPublicKeyInfo from each of the certificates presented to it by validating the end entity certificate given by the server in TLS.
the TLS server. It then does a bit-for-bit comparison between the This usage is sometimes referred to as "domain-issued certificate"
certificate for association and the SubjectPublicKeyInfos in the because it allows for a domain name administrator to issue
certificates; if it does not find a match, the client aborts the TLS certificates for a domain without involving a third-party CA.
handshake.
4.4. Use of TLS Certificate Associations in TLS 4.4. Use of TLS Certificate Associations in TLS
A TLS client conforming to this protocol receiving a certificate for Section 2.1 of this document defines the mandatory matching rules for
association of type 1 MUST compare it for equality, using the the data from the TLS certificate associations and the certificates
specified reference type, with the end entity certificate received in received from the TLS server.
TLS. A TLS client conforming to this protocol receiving a
certificate for association of type 2 MUST treat it as a trust anchor
for that domain name. A TLS client conforming to this protocol
receiving a certificate for association of type 3 MUST find a
matching SubjectPublicKeyInfo structure in one of the certificates
offered by the TLS server.
The end entity certificate from TLS, regardless of whether it was The TLS session that is to be set up MUST be for the specific port
matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA number and transport name that was given in the TLSA query. The
certificate, might have at least one identifier in the subject or matching or chaining MUST be done within the life of the TTL on the
subjectAltName field of the matched certificates that matches the TLSA record.
expected identifier for the TLS server. Some specifications for
applications that run under TLS, such as [RFC2818] for HTTP, require Some specifications for applications that run under TLS, such as
the server's certificate to have a domain name that matches the host [RFC2818] for HTTP, require the server's certificate to have a domain
name expected by the client. Further, the TLS session that is to be name that matches the host name expected by the client. Some
set up MUST be for the specific port number and transport name that specifications such at [RFC6125] detail how to match the identify
was given in the TLSA query. The matching or chaining MUST be done given in a PKIX certificate with those expected by the user.
within the life of the TTL on the TLSA record.
In order to use one or more TLS certificate associations described in In order to use one or more TLS certificate associations described in
this document obtained from the DNS, an application MUST assure that this document obtained from the DNS, an application MUST assure that
the certificates were obtained using DNS protected by DNSSEC. TLSA the certificates were obtained using DNS protected by DNSSEC. TLSA
records must only be trusted if they were obtained from a trusted records must only be trusted if they were obtained from a trusted
source. This could be a localhost DNS resolver answer with the AD source. This could be a localhost DNS resolver answer with the AD
bit set, an inline validating resolver library primed with the proper bit set, an inline validating resolver library primed with the proper
trust anchors, or obtained from a remote nameserver to which one has trust anchors, or obtained from a remote name server to which one has
a secured channel of communication. a secured channel of communication.
If a certificate association contains a reference type that is not If a certificate association contains a certificate usage, selector,
understood by the TLS client, that certificate association MUST be or matching type that is not understood by the TLS client, that
marked as unusable. certificate association MUST be marked as unusable. If the
comparison data for a certificate is malformed, the certificate
association MUST be marked as unusable.
An application that requests TLS certificate associations using the An application that requests TLS certificate associations using the
method described in this document obtains zero or more usable method described in this document obtains zero or more usable
certificate associations. If the application receives zero usable certificate associations. If the application receives zero usable
certificate associations, it processes TLS in the normal fashion. certificate associations, it processes TLS in the normal fashion.
If a match between one of the certificate association(s) and the On the first match between one of the certificate association(s) and
server's end entity certificate in TLS is found, the TLS client the server's end entity certificate in TLS is found, the TLS client
continues the TLS handshake. If no match between the usable continues the TLS handshake, ignoring remaining certificate
certificate association(s) and the server's end entity certificate in associations. If no match between the usable certificate
TLS is found, the TLS client MUST abort the handshake with an association(s) and the server's end entity certificate in TLS is
found, the TLS client MUST abort the handshake with an
"access_denied" error. "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 type 2. A 3.1 CA Constraints -- Implemented using certificate usage 0.
hashed association is recommended for well-known certification
authorities.
3.2 Certificate Constraints -- Implemented using certificate type 1. 3.2 Certificate Constraints -- Implemented using certificate usage
1.
3.3 Domain-Issued Certificates -- Implemented using certificate type 3.3 Domain-Issued Certificates -- Implemented using certificate
1 combined with any reference type, or by using certificate type 2 usage 2.
together with a full certificate association.
The requirements from section 4 of [DANEUSECASES] are covered in this The requirements from section 4 of [DANEUSECASES] are covered in this
protocol as follows (note that some of these might be excessively protocol as follows (note that some of these might be excessively
glib): glib):
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.
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 Certificate Type 3. Simple Key Management -- Implemented using the SubjectPublicKeyInfo
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 the TLSA request syntax; see Appendix A. Wild Cards -- Covered in a limited manner in the TLSA request
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 DNS systems conforming to this specification MUST be able to create
TLSA records containing certificate types 1 and 2. DNS systems TLSA records containing certificate usages 0, 1 and 2. DNS systems
conforming to this specification MUST be able to create TLSA records conforming to this specification MUST be able to create TLSA records
using reference type 0 (no hash used) and reference type 1 (SHA-256), with selectors 0 (full certificate) and 1 (SubjectPublicKeyInfo).
and SHOULD be able to create TLSA records using reference type 2 DNS systems conforming to this specification MUST be able to create
(SHA-512). 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 containing certificate types 1, 2 correctly interpret TLSA records with certificate usages 0, 1 and 2.
and 3. TLS clients conforming to this specification MUST be able to TLS clients conforming to this specification MUST be able to compare
compare a certificate for association with a certificate from TLS a certificate for association with a certificate from TLS using
using reference type 0 (no hash used) and reference type 1 (SHA-256), selectors type 0 and 1, and matching type 0 (no hash used) and
and SHOULD be able to make such comparisons with reference type 2 matching type 1 (SHA-256), and SHOULD be able to make such
(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
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.
7.2. TLSA Certificate Types 7.2. TLSA Usages
This document creates a new registry, "Certificate Types 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 Reserved [This] 0 Pass PKIX and chain through CA [This]
1 Certificate to identify an end entity [This] 1 Pass PKIX and match EE [This]
2 CA's certificate [This] 2 Pass PKIX and trusted via certificate [This]
3 Public key as SubjectPublicKeyInfo [This]
4-254 Unassigned 4-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.
7.3. TLSA Hash Types 7.3. TLSA Selectors
This document creates a new registry, "Hash Types for TLSA Resource This document creates a new registry, "Selectors for TLSA Resource
Records". The registry policy is "Specification Required". The Records". The registry policy is "Specification Required". The
initial entries in the registry are: initial entries in the registry are:
Value Short description Reference
----------------------------------------------------------
0 Full Certificate [This]
1 SubjectPublickeyInfo [This]
2-254 Unassigned
255 Private use
7.4. TLSA Matching Types
This document creates a new registry, "Matching Types for TLSA
Resource Records". The registry policy is "Specification Required".
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 NIST FIPS 180-3
2 SHA-512 NIST FIPS 180-3 2 SHA-512 NIST FIPS 180-3
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.
skipping to change at page 13, line 15 skipping to change at page 13, line 28
such information be inspected or validated by the domain name such information be inspected or validated by the domain name
administrator. administrator.
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, and Ondrej Sury. Laurie, Ilari Liusvaara, Scott Schmit, Ondrej Sury, Richard Barnes,
and Jim Schaad.
This document has also been greatly helped by many active This document has also been greatly helped by many active
participants of the DANE Working Group. participants of the DANE Working Group.
10. References 10. References
10.1. Normative References 10.1. Normative References
[DANEUSECASES] [DANEUSECASES]
Barnes, R., "Use Cases and Requirements for DNS-based Barnes, R., "Use Cases and Requirements for DNS-based
skipping to change at page 15, line 29 skipping to change at page 15, line 46
records using libraries that automatically follow CNAME (and DNAME) records using libraries that automatically follow CNAME (and DNAME)
aliasing. This allows hosts to put TLSA records in their own zones aliasing. This allows hosts to put TLSA records in their own zones
or to use CNAME to do redirection. or to use CNAME to do redirection.
If the owner of the original domain wants a TLSA record for the same, If the owner of the original domain wants a TLSA record for the same,
they simply enter it under the defined prefix: they simply enter it under the defined prefix:
; No TLSA record in target domain ; No TLSA record in target domain
; ;
sub5.example.com. IN CNAME sub6.example.com. sub5.example.com. IN CNAME sub6.example.com.
_443._tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com. IN A 10.0.0.0 sub6.example.com. IN A 10.0.0.0
If the owner of the orginal domain wants to have the target domain If the owner of the orginal domain wants to have the target domain
host the TLSA record, the original domain uses a CNAME record: host the TLSA record, the original domain uses a CNAME record:
; TLSA record for original domain has CNAME to target domain ; TLSA record for original domain has CNAME to target domain
; ;
sub5.example.com. IN CNAME sub6.example.com. sub5.example.com. IN CNAME sub6.example.com.
_443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com. _443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com.
sub6.example.com. IN A 10.0.0.0 sub6.example.com. IN A 10.0.0.0
_443._tcp.sub6.example.com. IN TLSA 1 1 536a570ac49d9ba4... _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
Note that it is acceptable for both the original domain and the Note that it is acceptable for both the original domain and the
target domain to have TLSA records, but the two records are target domain to have TLSA records, but the two records are
unrelated. Consider the following: unrelated. Consider the following:
; TLSA record in both the original and target domain ; TLSA record in both the original and target domain
; ;
sub5.example.com. IN CNAME sub6.example.com. sub5.example.com. IN CNAME sub6.example.com.
_443._tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com. IN A 10.0.0.0 sub6.example.com. IN A 10.0.0.0
_443._tcp.sub6.example.com. IN TLSA 2 0 ac49d9ba4570ac49... _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...
In this example, someone looking for the TLSA record for In this example, someone looking for the TLSA record for
sub5.example.com would always get the record whose value starts sub5.example.com would always get the record whose value starts
"308202c5308201ab"; the TLSA record whose value starts "308202c5308201ab"; the TLSA record whose value starts
"ac49d9ba4570ac49" would only be sought by someone who is looking for "ac49d9ba4570ac49" would only be sought by someone who is looking for
the TLSA record for sub6.example.com, and never for sub5.example.com. the TLSA record for sub6.example.com, and never for sub5.example.com.
Note that these methods use the normal method for DNS aliasing using Note that these methods use the normal method for DNS aliasing using
CNAME: the DNS client requests the record type that they actually CNAME: the DNS client requests the record type that they actually
want. want.
A.1.2. Provisioning TLSA Records with DNAME Records A.1.2. Provisioning TLSA Records with DNAME Records
Using DNAME records allows a zone owner to alias an entire subtree of Using DNAME records allows a zone owner to alias an entire subtree of
names below the name that has the DNAME. This allows the wholesale names below the name that has the DNAME. This allows the wholesale
aliasing of prefixed records such as those used by TLSA, SRV, and so aliasing of prefixed records such as those used by TLSA, SRV, and so
on without aliasing the name itself. However, because DNAME can only on without aliasing the name itself. However, because DNAME can only
be used for subtrees of a base name, it is rarely used to alias be used for subtrees of a base name, it is rarely used to alias
individual hosts that might also be running TLS. individual hosts that might also be running TLS.
; TLSA record in target domain, visible in original domain via DNAME
;
sub5.example.com. IN CNAME sub6.example.com.
_tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com.
sub6.example.com. IN A 10.0.0.0
_443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
A.1.3. Provisioning TLSA Records with Wildcards A.1.3. Provisioning TLSA Records with Wildcards
Wildcards are generally not terribly useful for RRtypes that require Wildcards are generally not terribly useful for RRtypes that require
prefixing because you can only wildcard at a layer below the host prefixing because you can only wildcard at a layer below the host
name. For example, if you want to have the same TLSA record for name. For example, if you want to have the same TLSA record for
every TCP port for www.example.com, you might have every TCP port for www.example.com, you might have
*._tcp.www.example.com. IN TLSA 1 1 5c1502a6549c423b... *._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b...
This is possibly useful in some scenarios where the same service is This is possibly useful in some scenarios where the same service is
offered on many ports. offered on many ports.
A.2. Securing the Last Hop A.2. Provisioning Using NS Records
[[ This was proposed, and questioned, and not yet followed through
on. ]]
A.3. Securing the Last Hop
[[ Need to add text here about the various ways that a client who is [[ Need to add text here about the various ways that a client who is
pulling in TLSA records can be sure that they are protected by pulling in TLSA records can be sure that they are protected by
DNSSEC. ]] DNSSEC. ]]
A.4. Handling Certificate Rollover
[[ 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
the RRset, and coordinating that with the use of the certs in 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 [[ IMPORTANT NOTE FOR THE DANE WG: Please review this new appendix
carefully. If you find differences between what is here and what is 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 in the rest of the draft, by all means please send it to the WG
mailing list. The ensuing discussion will hopefully help everyone. 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.
skipping to change at page 17, line 15 skipping to change at page 18, line 8
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] look up TLSA for _[port]._[transport].[hostname]
if (no secure TLSA record(s) received) { if (no secure TLSA record(s) received) {
fall back to "normal" cert validation fall back to non-TLSA cert validation
} }
for each TLSA record R received { // unusable records include unknown certUsage, unknown selectorType,
// unknown matchingType, and erroneous RDATA
strip unusable records
if (no usable TLSA record(s) received) {
fall back to non-TLSA cert validation
}
// a PKIX certificate that identifies an end entity // implement the selector function
if (R.certType == 1) { function Select(S, X) = {
if (R.referenceType == 0) AND (C == R.certAssoc) { if (S == 0) {
accept the TLS connection return X
} else if (hash(R.referenceType of C) == R.certAssoc) { }
accept the TLS connection if (S == 1) {
} else { return X.SubjectPublicKey
continue outer loop
}
} }
return undef
}
// a PKIX certification authority's certificate // implement the matching function
if (R.certType == 2) { function Match(M, X, Y) {
if (R.referenceType == 0) { if (M == 0) {
if (PKIX validation with R.certAssoc as the only TA succeeds) { return (X == Y)
accept the TLS connection }
} else { if (M == 1) {
continue outer loop return (SHA-256(X) == Y)
}
if (M == 2) {
return (SHA-512(X) == Y)
}
return undef
}
// A TLS client might have multiple trust anchors that it might use
// when validating the TLS server's end entity certificate. Also,
// there can be multiple PKIX validation chains for the
// certificates given by the server in TLS. Thus, there are
// possibly many chains that might need to be tested during
// PKIX validation.
for each TLSA record R {
// pass PKIX validation and chain through CA cert from TLSA
if (R.certUsage == 0) {
for each PKIX validation chain H {
if (C passes PKIX validation in H) {
for each D in H {
if (D is a CA certificate) and
Match(matchingType, Select(selectorType, D), R) {
accept the TLS connection
}
} }
} else { }
if (PKIX validation with existing TAs succeeds) { }
for each cert D in path except the EE cert {
if (hash(R.referenceType, D) == R.certAssoc) { // pass PKIX validation and match EE cert from TLSA
accept the TLS connection if (R.certUsage == 1) {
} for each PKIX validation chain H {
if (C passes PKIX validation in H) {
if (Match(matchingType, Select(selectorType, C), R)) {
accept the TLS connection
} }
} }
continue outer loop
} }
} }
// a public key expressed as a PKIX SubjectPublicKeyInfo structure // pass PKIX validation using TLSA record as trust anchor
if (R.certType == 3) { if (R.certUsage == 2) {
if (R.referenceType == 0) AND (publicKey(C) == R.certAssoc) { for each PKIX validation chain H that has R as the trust anchor {
accept the TLS connection if (C passes PKIX validation in H) {
} else if (hash(R.referenceType, publicKey(C)) == R.certAssoc) { accept the TLS connection
accept the TLS connection }
} else {
continue outer loop
} }
} }
} }
abort TLS handshake with "access_denied" error. abort TLS handshake with "access_denied" error.
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
 End of changes. 76 change blocks. 
202 lines changed or deleted 263 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/