[getdns-api] DANE with dnssec_return_only_secure extension

[Paul Hoffman]

On Jul 1, 2014, at 5:14 AM, Willem Toorop <Willem at NLnetLabs.nl> wrote:

> Could you advice me on this...
> 
> The dnssec_return_only_secure extension seems on first sight an ideal
> fit for looking up DANE records.
> 
> DANE records (like TLSA) MUST be used when they can be retrieved
> securely.  The dnssec_return_only_secure will return with status
> GETDNS_RESPSTATUS_GOOD and the answers MUST be use to validate a secure
> session.  Good!
> 
> On insecure answers (either existing or non-existing), the
> dnssec_return_only_secure extension makes requests return
> GETDNS_RESPSTATUS_NO_SECURE_ANSWERS.  DANE records MUST and ordinary
> PKIX should proceed.  Also good!
> 
> On non-existing secure answers, the dnssec_return_only_secure extension
> makes requests return GETDNS_RESPSTATUS_NO_NAME.  We should proceed with
> normal PKIX now too.  Fine!

Agree up to here.

> 
> On bogus answers, the dnssec_return_only_secure extension makes requests
> also returns GETDNS_RESPSTATUS_NO_NAME .  

I think that is an error in the implementation. The text from the spec says:

====
GETDNS_RESPSTATUS_GOOD

At least one response was returned

GETDNS_RESPSTATUS_NO_NAME

Queries for the name yielded all negative responses

GETDNS_RESPSTATUS_ALL_TIMEOUT

All queries for the name timed out

GETDNS_RESPSTATUS_NO_SECURE_ANSWERS

The context setting for getting only secure responses was specified, and at least one DNS response was received, but no DNS response was determined to be secure through DNSSEC.
=====

The API got a positive response: it simply didn't pass validation. So, for bogus answers, dnssec_return_only_secure that gets at least one answer back should return GETDNS_RESPSTATUS_GOOD, even if they are all bogus. In the case that any of the answers are bogus, the replies_tree and replies_full are not filled in. Thus, if they are all bogus, both of those dicts are empty.

An application that sees a good reply that is empty knows that it should proceed with normal PKIX validation.

> This is inconvenient, because
> in this case we should not proceed with PKIX, but no secure session
> should be set up at all!  Not good.
> 
> In that last case we must also enable the dnssec_return_validation_chain
> extension to be able to peek at the packets to see if none was bogus in
> case of GETDNS_RESPSTATUS_NO_NAME .
> 
> What about another return status: "GETDNS_RESPSTATUS_ALL_BOGUS_ANSWERS"?

I don't think we should be adding DNSSEC-specific responses to the list above. That list pertains to the number of answers received, not the number that later processing (in this case, with DNSSEC) could use.

--Paul Hoffman