draft-ietf-dane-protocol-15.txt   draft-ietf-dane-protocol-16.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: August 7, 2012 Kirei AB Expires: August 11, 2012 Kirei AB
February 4, 2012 February 8, 2012
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-15 draft-ietf-dane-protocol-16
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 August 7, 2012. This Internet-Draft will expire on August 11, 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 3, line 46 skipping to change at page 3, line 46
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Operational Considerations for Deploying TLSA Appendix A. Operational Considerations for Deploying TLSA
Records . . . . . . . . . . . . . . . . . . . . . . . 18 Records . . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 18 A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 18
A.1.1. Ambiguities and Corner Cases When TLS Clients A.1.1. Ambiguities and Corner Cases When TLS Clients
Build Trust Chains . . . . . . . . . . . . . . . . . . 18 Build Trust Chains . . . . . . . . . . . . . . . . . . 18
A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 19 A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 19
A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 20 A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 20
A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 20 A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 20
A.2.2. Provisioning with NS Records . . . . . . . . . . . . . 23 A.2.2. Provisioning with NS Records . . . . . . . . . . . . . 22
A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 23 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 23
A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 23 A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 23
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 24 Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 24
B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 24 B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 24
B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 25 B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
Some people want a different way to authenticate the association of Some people want a different way to authenticate the association of
the server's certificate with the intended domain name without the server's certificate with the intended domain name without
trusting an external certificate authority (CA). Given that the DNS trusting an external certificate authority (CA). Given that the DNS
administrator for a domain name is authorized to give identifying administrator for a domain name is authorized to give identifying
information about the zone, it makes sense to allow that information about the zone, it makes sense to allow that
administrator to also make an authoritative binding between the administrator to also make an authoritative binding between the
domain name and a certificate that might be used by a host at that domain name and a certificate that might be used by a host at that
domain name. The easiest way to do this is to use the DNS. domain name. The easiest way to do this is to use the DNS.
There are many use cases for such functionality. [DANEUSECASES] There are many use cases for such functionality. [RFC6394] lists the
lists the ones that the protocol in this document is meant to apply ones that the protocol in this document is meant to apply to.
to. [DANEUSECASES] also lists many requirements, most of which the [RFC6394] also lists many requirements, most of which the protocol in
protocol in this document is believed to meet. Section 6 covers the this document is believed to meet. Section 6 covers the
applicability of this document to the use cases in detail. applicability of this document to the use cases in detail.
This document applies to both TLS [RFC5246] and DTLS [RFC4347bis]. This document applies to both TLS [RFC5246] and DTLS [RFC6347]. In
In order to make the document more readable, it mostly only talks order to make the document more readable, it mostly only talks about
about "TLS", but in all cases, it means "TLS or DTLS". This document "TLS", but in all cases, it means "TLS or DTLS". This document only
only relates to securely associating certificates for TLS and DTLS relates to securely associating certificates for TLS and DTLS with
with host names; other security protocols and other forms of host names; other security protocols and other forms of
identification of TLS servers (such as IP addresses) are handled in identification of TLS servers (such as IP addresses) are handled in
other documents. For example, keys for IPsec are covered in other documents. For example, keys for IPsec are covered in
[RFC4025] and keys for SSH are covered in [RFC4255]. [RFC4025] and keys for SSH are covered in [RFC4255].
1.1. Certificate Associations 1.1. Certificate Associations
A certificate association is formed from a piece of information A certificate association is formed from a piece of information
identifying a certificate with the domain name where the data is identifying a certificate with the domain name where the data is
found. The data used to identify the certificate consists of either found. The data used to identify the certificate consists of either
a PKIX certificate or a hash of a PKIX certificate. When using the a PKIX certificate or a hash of a PKIX certificate. When using the
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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 protocol are made that accept formats later, or if extensions to this protocol 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.
The use of this field is described in greater detail in Section 4. 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 the association A one-octet value, called "selector", specifying which part of the
data will be matched against from the TLS certificate presented by TLS certificate presented by the server will be matched against the
the server. This value is defined in a new IANA registry (see association data. This value is defined in a new IANA registry (see
Section 8.3. The selectors defined in this document are: Section 8.3. The selectors defined in this document are:
0 -- Full certificate 0 -- Full certificate
1 -- SubjectPublicKeyInfo 1 -- SubjectPublicKeyInfo
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 8.4). The types defined in this document IANA registry (see Section 8.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
2 -- SHA-512 hash of selected content 2 -- SHA-512 hash of selected content
Because a client support for multiple hash algorithms might be Because clients' support for multiple hash algorithms might be
limited, it is advisable to use the same hash algorithm for the limited, it is advisable to use the same hash algorithm for the
matching type as is used for the signature in the certificate. Doing matching type as is used for the signature in the certificate. Doing
so will increase the likelihood of interoperability. so will increase the likelihood of interoperability.
2.1.4. The Certificate Association Data Field 2.1.4. The Certificate Association Data Field
The "certificate association data" to be matched. The field contains The "certificate association data" to be matched. This field
the bytes to be matched or the hash of the bytes to be matched. The contains the data to be matched. These bytes are either raw data
field contains the bytes to be matched: the raw data, for matching (that is, the full certificate or its SubjectPublicKeyInfo, depending
type 0, or the hash of the raw data, for matching types 1 and 2. The on the selector) for matching type 0, or the hash of the raw data for
data refers to the certificate in the association, not to the TLS matching types 1 and 2. The data refers to the certificate in the
ASN.1 Certificate object. association, not to the TLS ASN.1 Certificate object.
2.2. TLSA RR Presentation Format 2.2. TLSA RR Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
o The certificate usage field MUST be represented as an unsigned o The certificate usage field MUST be represented as an 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 8, line 38 skipping to change at page 8, line 38
8c9ebdd2f74e38fe51ffd48c43326cbc ) 8c9ebdd2f74e38fe51ffd48c43326cbc )
An example of a full certificate association of a PKIX end entity An example of a full certificate association of a PKIX end entity
certificate: certificate:
_443._tcp.www.example.com. IN TLSA ( _443._tcp.www.example.com. IN TLSA (
3 0 0 30820307308201efa003020102020... ) 3 0 0 30820307308201efa003020102020... )
3. Domain Names for TLS Certificate Associations 3. Domain Names for TLS Certificate Associations
Unless there is an protocol-specific specification that is different Unless there is a protocol-specific specification that is different
than this one, TLSA resource records are stored at a prefixed DNS than this one, TLSA resource records are stored at a prefixed DNS
domain name. The prefix is prepared in the following manner: domain name. The 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.
2. The protocol name of the transport on which a TLS-based service 2. The protocol name of the transport on which a TLS-based service
is assumed to exist is prepended with an underscore character is assumed to exist is prepended with an underscore character
skipping to change at page 9, line 42 skipping to change at page 9, line 42
the public key of such a certificate, that must be matched with the 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 end entity certificate given by the server in TLS. This usage is
sometimes referred to as "service certificate constraints" because it sometimes referred to as "service certificate constraints" because it
limits which end entity certificate may be used by a given host name. limits which end entity certificate may be used by a given host name.
4.3. Pass PKIX Validation and Use Trust Anchor 4.3. Pass PKIX Validation and Use Trust Anchor
Certificate usage 2 is used to specify a certificate, or the public Certificate usage 2 is used to specify a certificate, or the public
key of such a certificate, that must be used as a trust anchor when key of such a certificate, that must be used as a trust anchor when
validating the end entity certificate given by the server in TLS. validating the end entity certificate given by the server in TLS.
This usage allows a domain name administrator to specify a new trust This usage is sometimes referred to as "trust anchor assertion" and
anchor, such as if the domain issues its own certificates under its allows a domain name administrator to specify a new trust anchor,
own CA that is not expected to be in the end users collection of such as if the domain issues its own certificates under its own CA
trust anchors. that is not expected to be in the end users collection of trust
anchors.
4.4. Match Certificate 4.4. Match Certificate
Certificate usage 3 is used to specify a certificate, or the public Certificate usage 3 is used to specify a certificate, or the public
key of such a certificate, that must match the end entity certificate key of such a certificate, that must match the end entity certificate
given by the server in TLS. This usage is sometimes referred to as given by the server in TLS. This usage is sometimes referred to as
"domain-issued certificate" because it allows for a domain name "domain-issued certificate" because it allows for a domain name
administrator to issue certificates for a domain without involving a administrator to issue certificates for a domain without involving a
third-party CA. third-party CA.
skipping to change at page 11, line 6 skipping to change at page 11, line 8
insecure cannot be used for TLS and MUST be marked as unusable. insecure cannot be used for TLS and MUST be marked as unusable.
If an application receives zero usable certificate associations, it If an application receives zero usable certificate associations, it
processes TLS in the normal fashion without any input from the TLSA processes TLS in the normal fashion without any input from the TLSA
records; otherwise, that application attempts to match each records; otherwise, that application attempts to match each
certificate association with the TLS server's end entity certificate. certificate association with the TLS server's end entity certificate.
Clients that validate the DNSSEC signatures themselves MUST use Clients that validate the DNSSEC signatures themselves MUST use
standard DNSSEC validation procedures. Clients that rely on another standard DNSSEC validation procedures. Clients that rely on another
entity to perform the DNSSEC signature validation MUST use a secure entity to perform the DNSSEC signature validation MUST use a secure
transport between themselves and the validator. Examples of secure mechanism between themselves and the validator. Examples of secure
transports include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931],
[RFC6071]. Note that it is not sufficient to use secure transport to and IPsec [RFC6071]. Note that it is not sufficient to use secure
a DNS resolver that does not do DNSSEC signature validation. transport to a DNS resolver that does not do DNSSEC 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. If a certificate association association MUST be marked as unusable. If a certificate association
contains a matching type or certificate association data that uses a contains a matching type or certificate association data that uses a
cryptographic algorithm that is considered too weak for the TLS cryptographic algorithm that is considered too weak for the TLS
client's policy, the certificate association MUST be marked as client's policy, the certificate association MUST be marked as
unusable. unusable.
6. TLSA and DANE Use Cases and Requirements 6. TLSA and DANE Use Cases and Requirements
The different types of certificates associations defined in TLSA are The different types of certificate associations defined in TLSA are
matched with various sections of [DANEUSECASES]. Three use cases matched with various sections of [RFC6394]. The use cases from
from Section 3 of [DANEUSECASES] are covered in this protocol as Section 3 of [RFC6394] are covered in this protocol as follows:
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
1. 1.
3.3 Domain-Issued Certificates -- Implemented using certificate 3.3 Trust Anchor Assertion and Domain-Issued Certificates --
usage 3. Implemented using certificate usages 2 and 3, respectively.
The requirements from Section 4 of [DANEUSECASES] are covered in this The requirements from Section 4 of [RFC6394] are covered in this
protocol as follows: protocol 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 5 specifies the conditions under which a No Downgrade -- Section 5 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
skipping to change at page 13, line 45 skipping to change at page 13, line 45
8. IANA Considerations 8. IANA Considerations
8.1. TLSA RRtype 8.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 TLSA usages, and In the following sections, "RFC Required" was chosen for TLSA usages
"Specification Required" for selectors and hashes, because of the and "Specification Required" for selectors and matching types because
amount of detail that is likely to be needed for implementers to of the amount of detail that is likely to be needed for implementers
correctly implement new usages as compared to new matching types and to correctly implement new usages as compared to new selectors and
hash types. matching types.
8.2. TLSA Usages 8.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 Pass PKIX and chain through CA [This] 0 Pass PKIX and chain through CA [This]
skipping to change at page 16, line 27 skipping to change at page 16, line 27
customers to use that certificate with usage type 2. This in essence customers to use that certificate with usage type 2. This in essence
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.
10. Acknowledgements 10. 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 and words here originated with Paul Vixie, Dan Kaminsky, Jeff
Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben Hodges, Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam
Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit, Ondrej Sury, Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit,
Richard Barnes, Jim Schaad, Stephen Farrell and Suresh Krishnaswamy. Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh
Krishnaswamy, Peter Palfrader, and Pieter Lexis.
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.
11. References 11. References
11.1. Normative References 11.1. Normative References
[DANEUSECASES]
Barnes, R., "Use Cases and Requirements for DNS-based
Authentication of Named Entities (DANE)",
draft-ietf-dane-use-cases (work in progress), 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4347bis]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis (work in
progress), July 2010.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
11.2. Informative References 11.2. Informative References
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
skipping to change at page 18, line 15 skipping to change at page 18, line 9
[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.
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
Authentication of Named Entities (DANE)", RFC 6394,
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 record with certificate usage type 0 (CA When creating TLSA records with certificate usage type 0 (CA
Certificate) or type 2 (Trust Anchor), one needs to understand the Certificate) or type 2 (Trust Anchor), one needs to understand the
implications when choosing between selector type 0 (full certificate) implications when choosing between selector type 0 (full certificate)
and 1 (SubjectPublicKeyInfo). A careful choice is required because and 1 (SubjectPublicKeyInfo). A careful choice is required because
the different methods for building trust chains are used by different different methods for building trust chains are used by different TLS
TLS clients. The following outlines the cases that one should be clients. The following outlines the cases that one should be aware
aware of and discusses the implications of the choice of selector of and discusses the implications of the choice of selector type.
type.
Certificate usage 2 is not affected by the different types of chain Certificate usage 2 is not affected by the different types of chain
building when the end entity certificate is the same as the trust building when the end entity certificate is the same as the trust
anchor certificate. anchor certificate.
A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains
TLS clients may implement their own chain-building code rather than TLS clients may implement their own chain-building code rather than
rely on the chain presented by the TLS server. This means that, rely on the chain presented by the TLS server. This means that,
except for the end entity certificate, any certificate presented in except for the end entity certificate, any certificate presented in
skipping to change at page 19, line 16 skipping to change at page 19, line 13
These reissued certificates are the certificates TLS client can use These reissued certificates are the certificates TLS client can use
in place of an original certificate. in place of an original certificate.
Clients are known to exchange or remove certificates that could cause Clients are known to exchange or remove certificates that could cause
TLSA association that rely on the full certificate to fail. For TLSA association that rely on the full certificate to fail. For
example: example:
o The client considers the signature algorithm of a certificate to o The client considers the signature algorithm of a certificate to
no longer be sufficiently secure no longer be sufficiently secure
o The client may not have an associated root certificate in trust o The client may not have an associated root certificate in its
store and instead uses a cross-certificate with an identical trust store and instead uses a cross-certificate with an identical
subject and public key. subject and public key.
A.1.2. Choosing a Selector Type A.1.2. Choosing a Selector Type
In this section, "false-negative failure" means that a client will In this section, "false-negative failure" means that a client will
not accept the TLSA association for certificate designated by DNS not accept the TLSA association for certificate designated by DNS
administrator. Also, "false-positive acceptance" means that the administrator. Also, "false-positive acceptance" means that the
client accepts a TLSA association for a certificate that is not client accepts a TLSA association for a certificate that is not
designated by the DNS administrator. designated by the DNS administrator.
skipping to change at page 21, line 31 skipping to change at page 21, line 27
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 1 1 1 308202c5308201ab... _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN A 192.0.2.1
sub6.example.com. IN AAAA 2001:db8::1/32 sub6.example.com. IN AAAA 2001:db8::1
If the owner of the original domain wants to have the target domain If the owner of the original 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 192.0.2.1 sub6.example.com. IN A 192.0.2.1
sub6.example.com. IN AAAA 2001:db8::1/32 sub6.example.com. IN AAAA 2001:db8::1
_443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4... _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
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 1 1 1 308202c5308201ab... _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN A 192.0.2.1
sub6.example.com. IN AAAA 2001:db8::1/32 sub6.example.com. IN AAAA 2001:db8::1
_443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...
In this example, someone looking for the TLSA record for In this example, someone looking for the TLSA record for
sub5.example.com would always get the record whose value starts sub5.example.com would always get the record whose value starts
"308202c5308201ab"; the TLSA record whose value starts "308202c5308201ab"; the TLSA record whose value starts
"ac49d9ba4570ac49" would only be sought by someone who is looking for "ac49d9ba4570ac49" would only be sought by someone who is looking for
the TLSA record for sub6.example.com, and never for sub5.example.com. the TLSA record for sub6.example.com, and never for sub5.example.com.
One should note that deploying different certificates for multiple One should note that deploying different certificates for multiple
services located at a shared TLS listener often requires the use of services located at a shared TLS listener often requires the use of
TLS SNI (Server Name Indication) [RFC6066]. TLS SNI (Server Name Indication) [RFC6066].
skipping to change at page 22, line 40 skipping to change at page 22, line 32
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 ; TLSA record in target domain, visible in original domain via DNAME
; ;
sub5.example.com. IN CNAME sub6.example.com. sub5.example.com. IN CNAME sub6.example.com.
_tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com. _tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com.
sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN A 192.0.2.1
sub6.example.com. IN AAAA 2001:db8::1/32 sub6.example.com. IN AAAA 2001:db8::1
_443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4... _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
A.2.1.3. Provisioning TLSA Records with Wildcards A.2.1.3. Provisioning TLSA Records with Wildcards
Wildcards are generally not terribly useful for RRtypes that require Wildcards are generally not terribly useful for RRtypes that require
prefixing because you can only wildcard at a layer below the host prefixing because 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 1 5c1502a6549c423b... *._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b...
 End of changes. 28 change blocks. 
70 lines changed or deleted 68 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/