Re: [dane] DNS errors text

[Andrew Sullivan <[e-mail]>]

On Wed, Oct 01, 2014 at 08:01:47PM -0600, Peter Saint-Andre - &yet wrote:
> Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text on DNS
> errors.

Well, yes, but once again I've been caught asleep at the wheel.  I
know I participated in early work on some of the text below, but
apparently threads got away from me that I should have attended to.

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.  (I'm even more dubious that
they're the result of corrupted or lost network packets -- that sounds
to me rather more like something that would be handled by the regular
DNS mechanisms for this sort of thing, including DNS retries with a
smaller EDNS buffer size or reversion to TCP.  But never mind that).

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
    ah 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."

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.

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.
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.  But we don't need to mischaracterise how DNSSEC
works in this text (whatever draft it lands in).

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.
I suggest reading RFC 6840, especially the bits in appendices B and C.
Olafur and I both had several painful discussions (independently and
together) about that document, and it'd be useful to understand how
the interaction of stubs, CD, TA preferences, and failed upstream
validation could be made clearer.

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".

If you wanted to make the definition cleaner, you could define "secure
lookup error" instead.  Or something like that.  This might help,
because sometimes "lookup failure" and "lookup error" seem to be
treated the same, and sometimes we have "DNS lookup failure", which
appears to be different but I bet actually isn't.

I hope this helps rather than hinders.

A

-- 
Andrew Sullivan
[e-mail]