draft-ietf-dane-srv-13.txt   draft-ietf-dane-srv-14.txt 
DNS-Based Authentication of Named Entities (DANE) T. Finch DNS-Based Authentication of Named Entities (DANE) T. Finch
Internet-Draft University of Cambridge Internet-Draft University of Cambridge
Intended status: Standards Track M. Miller Intended status: Standards Track M. Miller
Expires: October 17, 2015 Cisco Systems, Inc. Expires: October 25, 2015 Cisco Systems, Inc.
P. Saint-Andre P. Saint-Andre
&yet &yet
April 15, 2015 April 23, 2015
Using DNS-Based Authentication of Named Entities (DANE) TLSA Records Using DNS-Based Authentication of Named Entities (DANE) TLSA Records
with SRV Records with SRV Records
draft-ietf-dane-srv-13 draft-ietf-dane-srv-14
Abstract Abstract
The DANE specification (RFC 6698) describes how to use TLSA resource The DANE specification (RFC 6698) describes how to use TLSA resource
records secured by DNSSEC (RFC 4033) to associate a server's records secured by DNSSEC (RFC 4033) to associate a server's
connection endpoint with its TLS certificate. However, application connection endpoint with its TLS certificate (thus enabling
protocols that use SRV records (RFC 2782) to indirectly name the administrators of domain names to specify the keys used in that
target server connection endpoints for a service domain cannot apply domain's TLS servers). However, application protocols that use SRV
the rules from RFC 6698. Therefore this document provides guidelines records (RFC 2782) to indirectly name the target server connection
that enable such protocols to locate and use TLSA records. endpoints for a service domain cannot apply the rules from RFC 6698.
Therefore this document provides guidelines that enable such
protocols to locate and use TLSA records.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 17, 2015. This Internet-Draft will expire on October 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DNS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DNS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. SRV Query . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. SRV Query . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Address Queries . . . . . . . . . . . . . . . . . . . . . 5 3.2. Address Queries . . . . . . . . . . . . . . . . . . . . . 5
3.3. TLSA Queries . . . . . . . . . . . . . . . . . . . . . . 5 3.3. TLSA Queries . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Impact on TLS Usage . . . . . . . . . . . . . . . . . . . 5 3.4. Impact on TLS Usage . . . . . . . . . . . . . . . . . . . 6
4. TLS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. TLS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SRV Records Only . . . . . . . . . . . . . . . . . . . . 6 4.1. SRV Records Only . . . . . . . . . . . . . . . . . . . . 6
4.2. TLSA Records . . . . . . . . . . . . . . . . . . . . . . 7 4.2. TLSA Records . . . . . . . . . . . . . . . . . . . . . . 7
5. Guidance for Protocol Authors . . . . . . . . . . . . . . . . 7 5. Guidance for Protocol Authors . . . . . . . . . . . . . . . . 7
6. Guidance for Server Operators . . . . . . . . . . . . . . . . 8 6. Guidance for Server Operators . . . . . . . . . . . . . . . . 8
7. Guidance for Application Developers . . . . . . . . . . . . . 8 7. Guidance for Application Developers . . . . . . . . . . . . . 9
8. Internationalization Considerations . . . . . . . . . . . . . 9 8. Internationalization Considerations . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10.1. Mixed Security Status . . . . . . . . . . . . . . . . . 9 10.1. Mixed Security Status . . . . . . . . . . . . . . . . . 9
10.2. Certificate Subject Name Matching . . . . . . . . . . . 9 10.2. Certificate Subject Name Matching . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
A.1. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.1. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The base DANE specification [RFC6698] describes how to use TLSA The base DANE specification [RFC6698] describes how to use TLSA
resource records secured by DNSSEC [RFC4033] to associate a target resource records secured by DNSSEC [RFC4033] to associate a target
server's connection endpoint with its TLS certificate. Some server's connection endpoint with its TLS certificate (thus enabling
application protocols locate connection endpoints indirectly via SRV administrators of domain names to specify the keys used in that
records [RFC2782]. As a result of this indirection, the rules domain's TLS servers). Some application protocols locate connection
specified in [RFC6698] cannot be directly applied to such application endpoints indirectly via SRV records [RFC2782]. As a result of this
protocols. (Rules for SMTP [RFC5321], which uses MX resource records indirection, the rules specified in [RFC6698] cannot be directly
instead of SRV records, are described in applied to such application protocols. (Rules for SMTP [RFC5321],
[I-D.ietf-dane-smtp-with-dane].) which uses MX resource records instead of SRV records, are described
in [I-D.ietf-dane-smtp-with-dane].)
This document describes how to use DANE TLSA records with SRV This document describes how to use DANE TLSA records with SRV
records. To summarize: records. To summarize:
o We rely on DNSSEC to secure SRV records that map the desired o We rely on DNSSEC to secure SRV records that map the desired
service, transport protocol, and service domain to the service, transport protocol, and service domain to the
corresponding target server connection endpoints (i.e., the target corresponding target server connection endpoints (i.e., the target
server host names and port numbers returned in the SRV records for server host names and port numbers returned in the SRV records for
that service type). that service type).
o Although in accordance with [RFC2782] a service domain can o Although in accordance with [RFC2782] a service domain can
skipping to change at page 4, line 33 skipping to change at page 4, line 40
3. DNS Checks 3. DNS Checks
3.1. SRV Query 3.1. SRV Query
When the client makes an SRV query, a successful result will When the client makes an SRV query, a successful result will
typically be a list of one or more SRV records (or possibly a chain typically be a list of one or more SRV records (or possibly a chain
of CNAME / DNAME aliases leading to such a list). of CNAME / DNAME aliases leading to such a list).
NOTE: Implementers need to be aware that unsuccessful results can NOTE: Implementers need to be aware that unsuccessful results can
occur because of various DNS-related errors; guidance on avoiding occur because of various DNS-related errors; guidance on avoiding
downgrade attacks can be found in Section 4 of downgrade attacks can be found in Section 2.1 of
[I-D.ietf-dane-smtp-with-dane]. [I-D.ietf-dane-smtp-with-dane].
For this specification to apply, the entire chain of DNS RRset(s) For this specification to apply, the entire chain of DNS RRset(s)
returned MUST be "secure" according to DNSSEC validation (Section 5 returned MUST be "secure" according to DNSSEC validation (Section 5
of [RFC4035]). In the case where the answer is obtained via a chain of [RFC4035]). In the case where the answer is obtained via a chain
of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME
RRsets MUST also be secure. RRsets MUST also be secure.
If the SRV lookup fails because the RRset is "bogus" (or the lookup If the SRV lookup fails because the RRset is "bogus" (or the lookup
fails for reasons other than no records), the client MUST abort its fails for reasons other than no records), the client MUST abort its
skipping to change at page 5, line 17 skipping to change at page 5, line 24
(see Section 4). The client can then proceed to making address (see Section 4). The client can then proceed to making address
queries on the target server host names as described in the following queries on the target server host names as described in the following
section. section.
3.2. Address Queries 3.2. Address Queries
For each SRV target server connnection endpoint, the client makes A For each SRV target server connnection endpoint, the client makes A
and/or AAAA queries, performs DNSSEC validation on the address (A or and/or AAAA queries, performs DNSSEC validation on the address (A or
AAAA) response, and continues as follows based on the results: AAAA) response, and continues as follows based on the results:
o If either the A or AAAA RRSets are "secure", the client MUST o If a returned RRSet is "secure", the client MUST perform a TLSA
perform a TLSA query for that target server connection endpoint as query for that target server connection endpoint as described in
described in the next section. the next section.
o If both RRsets are "insecure", the client MUST NOT perform a TLSA o If no returned RRsets are "secure", the client MUST NOT perform a
query for that target server connection endpoint; the TLSA query TLSA query for that target server connection endpoint; the TLSA
will most likely fail or produce spurious results. query will most likely fail or produce spurious results.
o If the address record lookup fails (this a validation status of o If the address record lookup fails (this a validation status of
either "bogus" or "indeterminate"), the client MUST NOT connect to either "bogus" or "indeterminate"), the client MUST NOT connect to
this connection endpoint; instead it uses the next most this connection endpoint; instead it uses the next most
appropriate SRV target. This mitigates against downgrade attacks. appropriate SRV target. This mitigates against downgrade attacks.
3.3. TLSA Queries 3.3. TLSA Queries
The client SHALL construct the TLSA query name as described in The client SHALL construct the TLSA query name as described in
Section 3 of [RFC6698], based on the fields from the SRV record: the Section 3 of [RFC6698], based on the fields from the SRV record: the
skipping to change at page 10, line 19 skipping to change at page 10, line 28
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-dane-ops] [I-D.ietf-dane-ops]
Dukhovni, V. and W. Hardaker, "Updates to and Operational Dukhovni, V. and W. Hardaker, "Updates to and Operational
Guidance for the DANE Protocol", draft-ietf-dane-ops-07 Guidance for the DANE Protocol", draft-ietf-dane-ops-07
(work in progress), October 2014. (work in progress), October 2014.
[I-D.ietf-dane-smtp-with-dane]
Dukhovni, V. and W. Hardaker, "SMTP security via
opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-15
(work in progress), March 2015.
[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.
[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.
[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", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, March 2005.
skipping to change at page 11, line 15 skipping to change at page 11, line 28
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
Conversations about DNS-Based Authentication of Named Conversations about DNS-Based Authentication of Named
Entities (DANE)", RFC 7218, April 2014. Entities (DANE)", RFC 7218, April 2014.
11.2. Informative References 11.2. Informative References
[I-D.ietf-dane-smtp-with-dane]
Dukhovni, V. and W. Hardaker, "SMTP security via
opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-15
(work in progress), March 2015.
[I-D.ietf-xmpp-dna] [I-D.ietf-xmpp-dna]
Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
Associations (DNA) in the Extensible Messaging and Associations (DNA) in the Extensible Messaging and
Presence Protocol (XMPP)", draft-ietf-xmpp-dna-10 (work in Presence Protocol (XMPP)", draft-ietf-xmpp-dna-10 (work in
progress), March 2015. progress), March 2015.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC Part Three: The Domain Name System (DNS) Database", RFC
3403, October 2002. 3403, October 2002.
skipping to change at page 14, line 22 skipping to change at page 14, line 22
Appendix C. Acknowledgements Appendix C. Acknowledgements
Thanks to Mark Andrews for arguing that authenticating the target Thanks to Mark Andrews for arguing that authenticating the target
server host name is the right thing, and that we ought to rely on server host name is the right thing, and that we ought to rely on
DNSSEC to secure the SRV lookup. Thanks to Stephane Bortzmeyer, DNSSEC to secure the SRV lookup. Thanks to Stephane Bortzmeyer,
James Cloos, Viktor Dukhovni, Ned Freed, Olafur Gudmundsson, Paul James Cloos, Viktor Dukhovni, Ned Freed, Olafur Gudmundsson, Paul
Hoffman, Phil Pennock, Hector Santos, Jonas Schneider, and Alessandro Hoffman, Phil Pennock, Hector Santos, Jonas Schneider, and Alessandro
Vesely for helpful suggestions. Vesely for helpful suggestions.
Carl Wallace provided an insightful review on behalf of the Security Carl Wallace completed an insightful review on behalf of the Security
Directorate. Directorate.
Ben Campbell, Brian Haberman, and Alvaro Retana provided helpful
feedback during IESG review.
The authors gratefully acknowledge the assistance of Olafur The authors gratefully acknowledge the assistance of Olafur
Gudmundsson and Warren Kumari as the working group chairs and Stephen Gudmundsson and Warren Kumari as the working group chairs and Stephen
Farrell as the sponsoring Area Director. Farrell as the sponsoring Area Director.
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
employing him during his work on earlier versions of this document. employing him during his work on earlier versions of this document.
Authors' Addresses Authors' Addresses
Tony Finch Tony Finch
 End of changes. 17 change blocks. 
33 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/