Subject: Re: (ngtrans) The reverse lookup issue

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Jul 2002 16:58:53 -0400 (EDT)

On 12 Jul 2002, Greg Hudson wrote:

> On Fri, 2002-07-12 at 01:02, Dean Anderson wrote:
> > Your disagreement is that your use isn't actually misuse, and that it
> > should be OK to use Reverse DNS for authentication or "validation", and
> > logging.  You have argued that when reverse and forward maps match, that
> > there is some kind of useful meaning to be implied from this.  I think I
> > have shown through several examples that, in fact, there is no meaning
> > that can be attached should it happen that forward and reverse match, and
> > therefore validation is also a misuse of Reverse DNS.  This is the crux of
> > the disagreement, I think.
> 
> Of course there is meaning.  It means "this domain is listed in the DNS
> as the name for this address, and it is not a complete forgery (although
> it might be meaningless)."  A fine thing to log.  Log the IP address
> too, since as you pointed out, the name might go away.

It could be a complete forgery. As a complete forgery, it might not be
actually listed in DNS. So your statement is false. If you log it, you've
just logged a false statement.  I assert that is a harm.

> I wouldn't call this logging a purely aesthetic benefit.  You can use
> that information to collect statistical data ("look, 30% of our
> connections are from IBM") as long as you're willing to accept that
> organizations can hide themselves from that collection (don't expect to
> find out that another 30% of your connections are coming from the NSA).

This has the implied assumption that most or all of your traffic is
"honest", by which I mean that the connections aren't spoofed, and there
isn't anyone trying to skew your logs.  You would be much better off by
analyzing the IP addresses into route netblocks, AS numbers or using Whosi
information directly to find out where most of your traffic is comming
from.  'Log skewing' has happened, and isn't a purely theoretical
possibility.

> > It is a frequent misconception that reverse DNS can be used for logging,
> > and authentication or validation, and therefore a "widespread misuse of
> > Reverse DNS."
> 
> There are historical examples of use for authentication (I'm still
> unsure what you mean by "validation"), but I'm not aware of any recent
> examples.  I think your "widespread misuse" is pretty much limited to
> the occasional logging of domain names without also logging IP
> addresses.

Actually, I think validation was Ted's term. By it, I think he meant the
same thing you said in your first paragraph: [It means "this domain is
listed in the DNS as the name for this address, and it is not a complete
forgery (although it might be meaningless)."]

But as I said, a false sense of comfort leads one to grant access that
should not be granted with the information available.  This is sort of
thing may have led to the r-cmd problem, and it could still happen, as
other kinds of access is granted based on the false sense of comfort
obtained when reverse and forward match.

As Ted mentioned that authentication would be possible with DNSsec, let me
take a minute to put down some thoughts about that.

If I recall the dates properly, BSD4.3 was released in 1986, and DNS was
invented that same year, or slightly earlier. It seems to me it is likely
the rcmds were developed with a hosts file, and then a resolver with
reverse DNS introduced later. So perhaps the rcmds weren't developed with
a "false" sense of security--the hosts file could be trusted.  It was the
seemingly innocuous change to use the resolver with reverse DNS that
introduced the exploitable security flaw.

What I'm getting to, is that one might develop applications that depend on
DNSsec with trustable reverse DNS, and then make a similar seemingly
innocuous change to not using DNSsec, and in doing so introduce a similar
exploitable security flaw.  This is a risk of having Reverse DNS.

> With forward DNSSEC, of course, it's fine to use reverse DNS for
> authentication, as long as you don't want to give anyone negative access
> rights (and aren't worried about IP spoofing, for whatever reason).  If
> I want to say "only these hosts can log in here," reverse DNS works as a
> hint.  An inline statement in the protocol would work just as well, if
> the protocol allows for that; I'm not saying that this is a great idea,
> just that it works.

Agreed, subject to the limitation that the "trusted" domains _must_ use
DNSsec, and that DNSsec must be proven to be unspoofable. I'm not sure if
one can claim DNSsec can't be spoofed just yet. <This doesn't mean I
personally know the answer, but rather I think the answer is still an
unknown>. Should DNSsec turn out to be spoofable, then this becomes false.
This could be an example of that "seemingly innocuous change", I was
talking about above.

		--Dean

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: David Terrell <[email-masked]>
Date: Fri, 12 Jul 2002 15:41:34 -0700

> This could be an example of that "seemingly innocuous change", I was

Yes, but then I can break your claimed superior solution of rwhois 
by simply spoofing the A{,AAA} record of the rwhois server. :)

A node to name mapping is a fundamental necessity for various pieces
of functionality on the internet.  Let's not forget that that
mapping, like all others, should be verified and hopefully signed;
but it's not a trivially removable component of the architecture
of the internet today.

-- 
David Terrell           | "The Court understands fully why licensing has many 
Nebcorp Prime Minister  | advantages for software publishers. However, this 
[email-masked]            | preference does not alter the Court's analysis that 
http://wwn.nebcorp.com/ | the substance of the transaction at issue here is a 
  sale and not a license." - Judge Dean Pregerson, Softman v Adobe.