< draft-ietf-dane-srv-12.txt   draft-ietf-dane-srv-13.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: September 24, 2015 Cisco Systems, Inc. Expires: October 17, 2015 Cisco Systems, Inc.
P. Saint-Andre P. Saint-Andre
&yet &yet
March 23, 2015 April 15, 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-12 draft-ietf-dane-srv-13
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. However, application
protocols that use SRV records (RFC 2782) to indirectly name the protocols that use SRV records (RFC 2782) to indirectly name the
target server connection endpoints for a service domain cannot apply target server connection endpoints for a service domain cannot apply
the rules from RFC 6698. Therefore this document provides guidelines the rules from RFC 6698. Therefore this document provides guidelines
that enable such protocols to locate and use TLSA records. that enable such protocols to locate and use TLSA records.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 24, 2015. This Internet-Draft will expire on October 17, 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DNS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. SRV Query . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. SRV Query . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Address Queries . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 7 6. Guidance for Server Operators . . . . . . . . . . . . . . . . 8
7. Guidance for Application Developers . . . . . . . . . . . . . 8 7. Guidance for Application Developers . . . . . . . . . . . . . 8
8. Internationalization Considerations . . . . . . . . . . . . . 8 8. Internationalization Considerations . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
A.1. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.1. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13 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. Some
application protocols locate connection endpoints indirectly via SRV application protocols locate connection endpoints indirectly via SRV
records [RFC2782]. As a result of this indirection, the rules records [RFC2782]. As a result of this indirection, the rules
specified in [RFC6698] cannot be directly applied to such application specified in [RFC6698] cannot be directly applied to such application
skipping to change at page 3, line 13 skipping to change at page 3, line 13
[I-D.ietf-dane-smtp-with-dane].) [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
advertise a number of SRV records (some of which might map to
connection endpoints that do not support TLS), the intent of this
specification is for a client to securely discover connection
endpoints that support TLS.
o The TLSA records for each connection endpoint are located using o The TLSA records for each connection endpoint are located using
the transport protocol, port number, and host name for the target the transport protocol, port number, and host name for the target
server (not the service domain). server (not the service domain).
o When DNSSEC-validated TLSA records are published for a particular o When DNSSEC-validated TLSA records are published for a given
connection endpoint, clients always use TLS when connecting (even connection endpoint, clients always use TLS when connecting (even
if the connection endpoint supports cleartext communication). if the connection endpoint supports cleartext communication).
o If there is at least one usable TLSA record, the connection o If there is at least one usable TLSA record for a given connection
endpoint's TLS certificate or public key needs to match at least endpoint, the connection endpoint's TLS certificate or public key
one of those usable TLSA records. needs to match at least one of those usable TLSA records.
o If there are no usable TLSA records, the target server host name o If there are no usable TLSA records for a given connection
is used as one of the acceptable reference identifiers, as endpoint, the target server host name is used as one of the
described in [RFC6125]. Other reference identifiers might arise acceptable reference identifiers, as described in [RFC6125].
through CNAME expansion of either the service domain or target Other reference identifiers might arise through CNAME expansion of
server host name, as detailed in [I-D.ietf-dane-ops]. either the service domain or target server host name, as detailed
in [I-D.ietf-dane-ops].
o If there are no usable TLSA records for any connection endpoint
(and thus the client cannot securely discover a connection
endpoint that supports TLS), the client's behavior is a matter for
the application protocol or client implementation; this might
involve a fallback to non-DANE behavior using the public key
infrastructure [RFC5280].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this memo are to be interpreted as described in "OPTIONAL" in this memo are to be interpreted as described in
[RFC2119]. [RFC2119].
This draft uses the definitions for "secure", "insecure", "bogus", This draft uses the definitions for "secure", "insecure", "bogus",
and "indeterminate" from Section 4.3 of [RFC4035]. This draft uses and "indeterminate" from Section 4.3 of [RFC4035]. This draft uses
skipping to change at page 4, line 18 skipping to change at page 4, line 33
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 2.1 of downgrade attacks can be found in Section 4 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 7, line 13 skipping to change at page 7, line 26
servers that do not support this specification. servers that do not support this specification.
4.2. TLSA Records 4.2. TLSA Records
If the client received one or more usable TLSA certificate If the client received one or more usable TLSA certificate
associations, it SHALL process them as described in Section 2.1 of associations, it SHALL process them as described in Section 2.1 of
[RFC6698]. [RFC6698].
If the TLS server's certificate -- or the public key of the server's If the TLS server's certificate -- or the public key of the server's
certificate -- matches a usable TLSA record with Certificate Usage certificate -- matches a usable TLSA record with Certificate Usage
"DANE-EE", the client MUST ignore expiration checks from [RFC5280] "DANE-EE", the client MUST ignore validation checks from [RFC5280]
and reference identifier checks from [RFC6125]. The information in and reference identifier checks from [RFC6125]. The information in
such a TLSA record supersedes the non-key information in the such a TLSA record supersedes the non-key information in the
certificate. certificate.
5. Guidance for Protocol Authors 5. Guidance for Protocol Authors
This document describes how to use DANE with application protocols in This document describes how to use DANE with application protocols in
which target servers are discovered via SRV records. Although this which target servers are discovered via SRV records. Although this
document attempts to provide generic guidance applying to all such document attempts to provide generic guidance applying to all such
protocols, additional documents for particular application protocols protocols, additional documents for particular application protocols
skipping to change at page 9, line 41 skipping to change at page 10, line 4
checks are superfluous and potentially conflicting. checks are superfluous and potentially conflicting.
Otherwise, while DNSSEC provides a secure binding between the server Otherwise, while DNSSEC provides a secure binding between the server
name and the TLSA record, and the TLSA record provides a binding to a name and the TLSA record, and the TLSA record provides a binding to a
certificate, this latter step can be indirect via a chain of certificate, this latter step can be indirect via a chain of
certificates. For example, a Certificate Usage "PKIX-TA" TLSA record certificates. For example, a Certificate Usage "PKIX-TA" TLSA record
only authenticates the CA that issued the certificate, and third only authenticates the CA that issued the certificate, and third
parties can obtain certificates from the same CA. Therefore, clients parties can obtain certificates from the same CA. Therefore, clients
need to check whether the server's certificate matches one of the need to check whether the server's certificate matches one of the
expected reference identifiers to ensure that the certificate was expected reference identifiers to ensure that the certificate was
issued by the CA to the server the client expects. issued by the CA to the server the client expects (naturally, this is
in addition to standard certificate-related checks as specified in
[RFC5280], including but not limited to certificate syntax,
certificate extensions such as name constraints and extended key
usage, and handling of certification paths).
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.
skipping to change at page 11, line 8 skipping to change at page 11, line 23
11.2. Informative References 11.2. Informative References
[I-D.ietf-dane-smtp-with-dane] [I-D.ietf-dane-smtp-with-dane]
Dukhovni, V. and W. Hardaker, "SMTP security via Dukhovni, V. and W. Hardaker, "SMTP security via
opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-15 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-15
(work in progress), March 2015. (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-09 (work in Presence Protocol (XMPP)", draft-ietf-xmpp-dna-10 (work in
progress), February 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.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
skipping to change at page 14, line 5 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
Directorate.
The authors gratefully acknowledge the assistance of Olafur
Gudmundsson and Warren Kumari as the working group chairs and Stephen
Farrell as the sponsoring Area Director.
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
employing him during his work on earlier versions of this document.
Authors' Addresses Authors' Addresses
Tony Finch Tony Finch
University of Cambridge Computing Service University of Cambridge Computing Service
New Museums Site New Museums Site
Pembroke Street Pembroke Street
Cambridge CB2 3QH Cambridge CB2 3QH
ENGLAND ENGLAND
Phone: +44 797 040 1426 Phone: +44 797 040 1426
 End of changes. 18 change blocks. 
27 lines changed or deleted 55 lines changed or added

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