Re: [dane] Behavior in the face of no answer?

[Paul Hoffman <[e-mail]>]

On May 3, 2012, at 3:45 PM, Paul Wouters wrote:

> On Thu, 3 May 2012, Paul Hoffman wrote:
> 
>>> From the earlier thread on this topic, I do not think there is "wide agreement" on what is and is not bogus. RFC 4033 and 4035 don't even agree about it.
>> 
>> Just because I like actual proposals for text, I believe what ekr is proposing is changing the current:
>>  o  If the DNSSEC validation state on the response to the request for
>>     the TLSA RRset is bogus, this MUST cause TLS not to be started or,
>>     if the TLS negotiation is already in progress, MUST cause the
>>     connection to be aborted.
>> to:
>>  o  If the DNSSEC validation state on the response to the request for
>>     the TLSA RRset is bogus, or if a response is not received or the
>>     response has no data, this MUST cause TLS not to be started or,
>>     if the TLS negotiation is already in progress, MUST cause the
>>     connection to be aborted.
> 
> I'm not sure I understand "has no data" in the context of DNSSEC with
> a validation path (eg DS at the parent).

A response of SERVFAIL is a response, and it has no data in it.

> A response with no data, where there is a DNSSEC chain of trust, is
> per definition bogus, as your response, even for 'no data' has to come
> with the signed proof (NSEC/NSEC3)

That is a reasonable interpretation. Can you point to somewhere in 4033-5 where it says that clearly?

> I would just leave out "or the response has no data"

I would like to as well, but I think the text above reflects ekr's problem statement.

--Paul Hoffman