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

[Peter Saint-Andre <[e-mail]>]

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