< draft-ietf-dane-srv-06.txt   draft-ietf-dane-srv-07.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: December 12, 2014 Cisco Systems, Inc. Expires: January 24, 2015 Cisco Systems, Inc.
P. Saint-Andre P. Saint-Andre
&yet &yet
June 10, 2014 July 23, 2014
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-06 draft-ietf-dane-srv-07
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 in the DNS to associate a server's host name with its TLS records in the DNS to associate a server's host name with its TLS
certificate, where the association is secured with DNSSEC. However, certificate, where the association is secured with DNSSEC. However,
application protocols that use SRV records (RFC 2782) to indirectly application protocols that use SRV records (RFC 2782) to indirectly
name the target server host names for a service domain cannot apply name the target server host names 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 December 12, 2014. This Internet-Draft will expire on January 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
same entities with the terms "source domain" and "derived domain". same entities with the terms "source domain" and "derived domain".
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 [RFC4033]. This draft uses the acronyms and "indeterminate" from [RFC4035]. This draft uses the acronyms
from [RFC7218] for the values of TLSA fields where appropriate. from [RFC7218] for the values of TLSA fields where appropriate.
3. DNS Checks 3. DNS Checks
To expedite connection to the intended service, where possible the To expedite connection to the intended service, where possible the
queries described in the following sections SHOULD be performed in queries described in the following sections SHOULD be performed in
parallel (this is similar to the "happy eyeballs" approach for IPv4 parallel (this is similar to the "happy eyeballs" approach for IPv4
and IPv6 connections described in [RFC6555]). and IPv6 connections described in [RFC6555]).
3.1. SRV Query 3.1. SRV Query
skipping to change at page 4, line 17 skipping to change at page 4, line 17
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).
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 DNSSSEC validation ([RFC4033] returned MUST be "secure" according to DNSSSEC validation ([RFC4033]
section 5). In the case of aliases, the whole chain of CNAME and section 5). In the case of aliases, the whole chain of CNAME and
DNAME RRsets MUST be secure as well. This corresponds to the AD bit DNAME RRsets MUST be secure as well. This corresponds to the AD bit
being set in the response(s); see [RFC4035] section 3.2.3. being set in the response(s); see [RFC4035] section 3.2.3.
If the the entire RRset is not secure, this protocol has not been If the the entire RRset is "insecure" or "indeterminate", this
correctly deployed. The client SHOULD fall back to its non-DNSSEC, protocol has not been correctly deployed. The client SHOULD fall
non-DANE behavior (this corresponds to the AD bit being unset). back to its non-DNSSEC, non-DANE behavior (this corresponds to the AD
bit being unset). If the entire RRset is "bogus", the client MUST
If a particular response is "bogus" or "indeterminate" according to abort the attempt.
DNSSEC validation, the client MUST ignore that target server host
name.
In the successful case, the client now has an authentic list of In the successful case, the client now has an authentic list of
target server host names with weight and priority values. It target server host names with weight and priority values. It
performs server ordering and selection using the weight and priority performs server ordering and selection using the weight and priority
values without regard to the presence or absence of DNSSEC or TLSA values without regard to the presence or absence of DNSSEC or TLSA
records. It also takes note of the DNSSEC validation status of the records. It also takes note of the DNSSEC validation status of the
SRV response for use when checking certificate names (see Section 4). SRV response for use when checking certificate names (see Section 4).
The client can now proceed to making address queries on the target The client can now proceed to making address queries on the target
server host names as described in the next section. server host names as described in the next section.
 End of changes. 6 change blocks. 
12 lines changed or deleted 10 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/