Subject: [dane] DNS errors text

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 01 Oct 2014 20:01:47 -0600

Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text on 
DNS errors. Viktor suggested that draft-ietf-dane-srv needs the same 
text. I would strongly prefer NOT to have the same text in two documents 
for various reasons. When I mentioned this to the chairs, they suggested 
moving the text from the SMTP document to the SRV document since it is 
more generic. I don't really care where it lives, I just want it to be 
in one place. What do WG participants think?

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Oct 2014 19:13:17 -0700

On Oct 1, 2014, at 7:01 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:

> Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text on DNS errors. Viktor suggested that draft-ietf-dane-srv needs the same text. I would strongly prefer NOT to have the same text in two documents for various reasons. When I mentioned this to the chairs, they suggested moving the text from the SMTP document to the SRV document since it is more generic. I don't really care where it lives, I just want it to be in one place. What do WG participants think?

As long as the SMTP document points to the SRV document for the errors, it's fine to have it live in the SRV document.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Oct 2014 03:18:00 +0000

On Wed, Oct 01, 2014 at 07:13:17PM -0700, Paul Hoffman wrote:
> As long as the SMTP document points to the SRV document for the
> errors, it's fine to have it live in the SRV document.

The main issue that comes to mind is that the SRV draft is at
present silent about whether DANE security is opportunistic or
mandatory.  Some of the error text is IIRC specific to the
opportunistic mode of operation, because this comes more ways to
attempt to mount downgrade attacks.

I don't think the SRV draft should sit on the fence with respect
to opportunistic use.  It probably needs to describe both modes of
operation explicitly.

Otherwise, yes I have no problem importing the DNS error handling
by referehce, but I also see little disadvantage to simply repeating
the text, one stop shopping is easier on the reader.

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Oct 2014 23:39:49 -0400

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
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Oct 2014 14:41:32 +0000

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

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

>     an analagous strategy to that used by DNSSEC when a validating

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

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

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

> 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

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.

> 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

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.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 21 Oct 2014 15:45:42 -0600

> As long as the SMTP document points to the SRV document for the errors, it's fine to have it live in the SRV document.

Matt and I talked about this, and we're more comfortable with having 
this text live in the SMTP document and pointing there from the SRV 
document. Viktor cares more and knows more about this topic than the 
dane-srv authors, so we think it's best to leave things as-is.

Peter

-- 
Peter Saint-Andre
https://andyet.com/