Subject: [dane] I-D Action: draft-ietf-dane-srv-07.txt

From: [email-masked]
Date: Wed, 23 Jul 2014 10:28:59 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

        Title           : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records
        Authors         : Tony Finch
                          Matthew Miller
                          Peter Saint-Andre
	Filename        : draft-ietf-dane-srv-07.txt
	Pages           : 13
	Date            : 2014-07-23

Abstract:
   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
   certificate, where the association is secured with DNSSEC.  However,
   application protocols that use SRV records (RFC 2782) to indirectly
   name the target server host names 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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-srv/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-srv-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Jul 2014 12:57:57 +0000

> http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-07

For now comments on the -07 changes, will review the whole draft
later.

Section 3.1 paragraph 3 (page 4 line 17):

   If the the entire RRset is "insecure" or "indeterminate", this
   protocol has not been correctly deployed.  The client SHOULD fall
   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
   abort the attempt.

delete [or "indeterminate"], per RFC 4035, from which "indeterminate"
is reputedly taken, that status is essentially a lookup error
(failure to determine whether the query zone is opted out or not),
and so is not a case where the client simply falls back to non-DANE
behaviour.

Note the words "entire RRset" in paragraphs 3 and 4 are misleading.
I believe that it is not possible for an RRset to be partially
secure.  Unless I am mistaken, RRSIGs apply to an RRset, not an
individual RR.  Since we're ultimately looking at an SRV RRset
(possibly after CNAME expansion of the original domain), it is
either secure in full or insecure in full.  More appropriately,
"entire" applies not to RRset, but rather "entire chain" of aliases
(CNAME or DNAME if any) leading to the ultimate SRV RRset.

Not continuing with connections to the target service applies when
the DNS lookup fails ("bogus", "indeterminate", "timeout", ...).

DNS lookup error handling is more comprehensively specified in the
SMTP draft, and perhaps should be borrowed from that document in
its entirety.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Jul 2014 12:56:57 +0000

-- 
	Viktor.