Re: [dane] DNS errors text

[Viktor Dukhovni <[e-mail]>]

On Wed, Oct 01, 2014 at 11:39:49PM -0400, Andrew Sullivan wrote:

> I object pretty strongly to this:
> 
>    To avoid much repetition in the text below, we will pause to explain
>    the handling of "bogus" or "indeterminate" DNSSEC query responses.
>    These are not necessarily the result of a malicious actor; they can,
>    for example, occur when network packets are corrupted or lost in
>    transit.  Therefore, "bogus" or "indeterminate" replies are equated
>    in this memo with lookup failure.
> 
> While I agree that neither bogus nor interdeterminate responses are
> necessarily the result of a malicious actor, I am not sure why this
> should be "equated with" lookup failure. 

Data integrity errors are errors.  DNSSEC detects more data integrity
failures than legacy DNS.   It is important to tell application
developers that e.g. "bogus", "srvfail" and lookup timeouts can
and should be treated identically.


> (I'm even more dubious that they're the result of corrupted or lost network
> packets

The quoted claim is that they "can be", not that they are.  Note,
that 4035 "indeterminate" can happen due to lost packets, while
"bogus" likely cannot.

> I'm ok if the idea is just to say this:
> 
>     For the purposes contemplated by this memo, neither bogus nor
>     indeterminate answers are acceptable.  Therefore, this memo uses
>     an analagous strategy to that used by DNSSEC when a validating
>     iterative resolver responds to a stub: SERVFAIL when positive
>     validation fails.  The difference in the present case lies in
>     treating bogus and indeterminate as the same thing -- what might
>     be called a 'strongly valid' bias.  This is required in order to
>     derive further security properties from the answer received from
>     DNS."

The draft is not for nameserver developers, it is for SMTP server
developers.  The above is far less clear than the original.

For the purpose of an SMTP with DANE implementation ordinary DNS
lookup errors and validation errors are indistinguishable, provided
NXDOMAIN is not treated as an error (DNSSEC secures denial of
existence).

> There are some other DNS errors in the same section:
> 
>    When a DNSSEC response with a
>    validation status that is either "secure" or "insecure" reports
>    either no records of the requested type or non-existence of the query
>    domain, the response is not a DNS error condition.

For the purposes of SMTP with DANE (or other DANE applications),
the text applies as written.  This draft is not a DNSSEC draft.

> This is strictly false.  The "no records of the requested type" is
> what is called a NODATA response, and is defined in RFC 2308.  It's
> not an RCODE.  But a response of "non-exstence of the query domain"
> is, if I understand it, an RCODE==3 ("Name Error" or "NXDOMAIN")
> response, which is certainly an "error" condition in pure DNS terms.

It is not an error condition for DANE with SMTP.  Authenticated
denial of existence is a valid outcome.

> For practical purposes in an application, it is quite possibly true
> that "NODATA" and "NXDOMAIN" -- presuming that they're both provably
> secure responses, or that you've decided to accept an opt-out proof --
> are the same thing.

Exactly!  This draft is focused on telling application developers
how handle DNSSEC queries in a way that avoids downgrade attacks.
The text is correct as written.

> But we don't need to mischaracterise how DNSSEC
> works in this text (whatever draft it lands in).

We're not explaining how DNSSEC works, we're explaining how to use
it.  Deliberately simplifying away inessential differences that
can easily confuse application developers, and simplifying later
exposion, by defining "lookup error" comprehensively.

> This isn't exactly true either:
> 
>    Security-aware stub resolvers will, of course, also signal DNS lookup
>    errors in other cases, for example when processing a "ServFail"
>    RCODE, which will not have an associated DNSSEC status.
> 
> A stub that gets a SERVFAIL, but that is itself validating, is in a
> perfectly good position to retry with CD=1.  If it gets an answer at
> that point, and yet cannot validate itself, then that is in fact a
> DNSSEC status: bogus.  Otherwise, it's SERVFAIL, which could mean
> anything.  This is underdetermined, but not completely indeterminate.

These nuances are out of scope.  At the end of the day, the text
explains to DANE implementors who are not DNSSEC experts how to
interact with DNS in a downgrade resistant manner.

> Instead of
> 
>    A lookup error is thus a failure to obtain the relevant RRset if it
>    exists, or to determine that no such RRset exists when it does not.
> 
> I suggest
> 
>    For the purposes of this memo, a "lookup error" is either a
>    failure to obtain securely the relevant RRset (if that RRset
>    exists), or to determine securely that no such RRset exists (if it
>    does not).  This is a broader meaning than is sometimes used for
>    "lookup error".

This is wrong, because "insecure" responses are also acceptable
from "opted out" zones.

> I hope this helps rather than hinders.

Mostly the latter I think.  Our audience is not DNSSEC implementors,
it is DANE (SMTP or broader) application developers, and the less
said about DNSSEC internals the better.

The goal is for developers to understand that DNSSEC-related errors
and just like other errors, with exactly one exception, NXDOMAIN
is not a lookup error.  It signals the non-existence of the query
domain, which from an application perspective is a perfectly normal
condition.

Yeah, sure, DNS nameserver developers may prefer a different mindset,
but that would needlessly complicate the exposition to application
developers.

-- 
	Viktor.