Hi Viktor, thanks for the continued feedback.
On 7/24/14, 6:57 AM, Viktor Dukhovni wrote:
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.
What would you suggest the client do in this case?
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.
That comports with my reading of RFC 4035.
Since we're ultimately looking at an SRV RRset
Correct.
(possibly after CNAME expansion of the original domain),
Disallowed by RFC 2782, right? Or do you mean expansion of the SRV
"Name" rather than the SRV "Target"?
it is
either secure in full or insecure in full.
That's what we were trying to capture by "entire". But it's just as easy
to remove the word if it is causing confusion.
More appropriately,
"entire" applies not to RRset, but rather "entire chain" of aliases
(CNAME or DNAME if any) leading to the ultimate SRV RRset.
I find the term "ultimate SRV RRset" to be a bit vague. Do you suggest
that we spend time and energy in defining it for use in this specification?
Not continuing with connections to the target service applies when
the DNS lookup fails ("bogus", "indeterminate", "timeout", ...).
Are you referring to this text?
o If the response is "bogus" or "indeterminate", the client MUST NOT
connect to this target server; instead it uses the next most
appropriate SRV target.
And are you suggesting that we expand that text to mention additional
DNS lookup errors (e.g., "timeout")?
DNS lookup error handling is more comprehensively specified in the
SMTP draft, and perhaps should be borrowed from that document in
its entirety.
Yes, Section 2.1 of draft-ietf-dane-smtp-with-dane is indeed quite
comprehensive. I am hesitant to copy it to draft-ietf-dane-srv primarily
because copying introduces the possibility of divergence in text and
secondarily because that text talks about SMTP. It seems safer to me if
we point to that text from the dane-srv specification.
Peter
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
