On Wed, Jul 23, 2014 at 10:28:59AM -0700, [email protected] wrote:
> A diff from the previous version is available at:
> 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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
