< draft-ietf-dane-srv-09.txt   draft-ietf-dane-srv-10.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: August 17, 2015 Cisco Systems, Inc. Expires: August 20, 2015 Cisco Systems, Inc.
P. Saint-Andre P. Saint-Andre
&yet &yet
February 13, 2015 February 16, 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-09 draft-ietf-dane-srv-10
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 August 17, 2015. This Internet-Draft will expire on August 20, 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 3, line 39 skipping to change at page 3, line 39
server host name, as detailed in [I-D.ietf-dane-ops]. server host name, as detailed in [I-D.ietf-dane-ops].
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 [RFC4035]. This draft uses the acronyms and "indeterminate" from Section 4.3 of [RFC4035]. This draft uses
from [RFC7218] for the values of TLSA fields where appropriate. the acronyms from [RFC7218] for the values of TLSA fields where
appropriate.
Additionally, this document uses the following terms: Additionally, this document uses the following terms:
connection endpoint: A tuple of a fully qualified DNS host name, connection endpoint: A tuple of a fully qualified DNS host name,
transport protocol, and port number that a client uses to transport protocol, and port number that a client uses to
establish a connection to the target server. establish a connection to the target server.
service domain: The fully qualified DNS domain name that identifies service domain: The fully qualified DNS domain name that identifies
an application service; corresponds to the term "source domain" an application service; corresponds to the term "source domain"
from [RFC6125]. from [RFC6125].
skipping to change at page 4, line 27 skipping to change at page 4, line 27
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 2.1 of
[I-D.ietf-dane-smtp-with-dane]. [I-D.ietf-dane-smtp-with-dane].
For this specification to apply, the entire DNS RRset that is For this specification to apply, the entire DNS RRset that is
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 lookup result is "insecure" (or no SRV records are located), If the SRV lookup fails because the RRset is "bogus" (or the lookup
this protocol does not apply and the client SHOULD fall back to its fails for reasons other than no records), the client MUST abort its
non-DNSSEC, non-DANE (and possibly non-SRV) behavior. If the SRV attempt to connect to the desired service. If the lookup result is
lookup fails because the RRset is "bogus", the client MUST abort its "insecure" (or no SRV records exist), this protocol does not apply
attempt to connect to the desired service. and the client SHOULD fall back to its non-DNSSEC, non-DANE (and
possibly non-SRV) behavior.
When the lookup returns a "secure" RRset (possibly via a chain of When the lookup returns a "secure" RRset (possibly via a chain of
"secure" CNAME/DNAME records), the client now has an authentic list "secure" CNAME/DNAME records), the client now has an authentic list
of target server connection endpoints with weight and priority of target server connection endpoints with weight and priority
values. It performs server ordering and selection using the weight values. It performs server ordering and selection using the weight
and priority values without regard to the presence or absence of and priority values without regard to the presence or absence of
DNSSEC or TLSA records. It also takes note of the DNSSEC validation DNSSEC or TLSA records. It also takes note of the DNSSEC validation
status of the SRV response for use when checking certificate names status of the SRV response for use when checking certificate names
(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
skipping to change at page 5, line 41 skipping to change at page 5, line 45
The client SHALL determine if the TLSA records returned in the The client SHALL determine if the TLSA records returned in the
previous step are usable according to Section 4.1 of [RFC6698]. This previous step are usable according to Section 4.1 of [RFC6698]. This
affects the use TLS as follows: affects the use TLS as follows:
o If the TLSA response is "secure" and usable, then the client MUST o If the TLSA response is "secure" and usable, then the client MUST
use TLS when connecting to the target server. The TLSA records use TLS when connecting to the target server. The TLSA records
are used when validating the server's certificate as described in are used when validating the server's certificate as described in
Section 4. Section 4.
o If the TLSA lookup fails, then the client SHALL proceed as if the o If the TLSA response is "bogus" or "indeterminate" (or the lookup
target server had no TLSA records. It MAY connect to the target fails for reasons other than no records), then the client MUST NOT
server with or without TLS, subject to the policies of the connect to the target server (the client can still use other SRV
application protocol or client implementation. targets).
o If the TLSA response is "bogus" or "indeterminate", then the o If the TLSA response is "insecure" (or no TLSA records exist),
client MUST NOT connect to the target server (the client can still then the client SHALL proceed as if the target server had no TLSA
use other SRV targets). records. It MAY connect to the target server with or without TLS,
subject to the policies of the application protocol or client
implementation.
4. TLS Checks 4. TLS Checks
When connecting to a server, the client MUST use TLS if the responses When connecting to a server, the client MUST use TLS if the responses
to the SRV and TLSA queries were "secure" as described above. The to the SRV and TLSA queries were "secure" as described above. The
rules described in the next two sections apply to such secure rules described in the next two sections apply to such secure
responses; Section 4.2 where there is at least one usable TLSA responses; Section 4.2 where there is at least one usable TLSA
record, and Section 4.1 otherwise. record, and Section 4.1 otherwise.
4.1. SRV Records Only 4.1. SRV Records Only
skipping to change at page 10, line 50 skipping to change at page 10, line 50
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] [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-10 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-13
(work in progress), May 2014. (work in progress), October 2014.
[I-D.ietf-xmpp-dna] [I-D.ietf-xmpp-dna]
Saint-Andre, P. and M. Miller, "Domain Name Associations Saint-Andre, P. and M. Miller, "Domain Name Associations
(DNA) in the Extensible Messaging and Presence Protocol (DNA) in the Extensible Messaging and Presence Protocol
(XMPP)", draft-ietf-xmpp-dna-05 (work in progress), (XMPP)", draft-ietf-xmpp-dna-08 (work in progress),
February 2014. October 2014.
[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.
 End of changes. 10 change blocks. 
22 lines changed or deleted 26 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/