On 8/19/14, 12:07 PM, Viktor Dukhovni wrote:
On Tue, Aug 19, 2014 at 11:24:47AM -0600, Peter Saint-Andre wrote:
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"?
Yes, the "Name".
OK. Yes, we might need to account for expansion there. I'm sure you will
tell me that the SMTP draft addresses this issue, right? ;-)
(I'm not being sarcastic, just in awe of your thoroughness!)
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?
Just be clear that the text in question is talking about the security
if the sequence of CNAMEs leading to the result, (all the links in
the chain need to be "secure"). The RRset at the end of the chain
is "secure" or not, binary, thus "entire" does not apply to that.
Yes, that makes sense.
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.
Yes, "bogus" is not the only case in which you skip the target,
and "indeterminate" (as defined in 4035) is best viewed as an error
condition. All error conditions in resolving the TLSA RRset lead
to skipping the target.
And are you suggesting that we expand that text to mention additional DNS
lookup errors (e.g., "timeout")?
All DNS lookup errors, with or without examples of specific ones.
Definitely not limited to just "bogus" and "indeterminate".
OK.
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.
Whatever works for you. There is also a possibility of migrating
that text to the OPS draft, if the WG consensus is that such text
would be better placed there, and used by reference in both SMTP
and SRV. This of course means that OPS must be published at least
concurrently with SMTP (and SRV) or even before.
Let's see what our WG chairs think about how to proceed.
Peter
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
