Subject: Re: IPv6 and Dynamic DNS

From: Dean Anderson <[email-masked]>
Date: Tue, 03 Aug 1999 23:34:49 -0400

Having reverse dns mappings is no security at all.  Both are easily
spoofed.  Having a valid reverse map does not make the connection any more
or less trustworthy.  Only really stupid admins make trust decisions based
on DNS information.

Indeed, there is another just as invalid "security" idea that one should
never use reverse mappings because the information might be used by
crackers.  Woe unto anyone who needs to get these two "security conscious"
networks to speak to each other.   One will not put out reverse maps, the
other will not trust anyone whose reverse maps are not "correct".

This is about as silly as believing that using RFC1918 addresses enhance
security because they are "unroutable". Lets just let both of these go into
the history of foolish ideas.

Please don't build this foolishness into DNS.  That would be a disaster.

		--Dean

Around 03:57 PM 8/3/1999 -0700, rumor has it that Terry Lambert said:
>Cutler, James R wrote:
>> 
>> Can we backstep a bit and better define the business and
>> technical need for updating DNS reverse entries?  It seems
>> clear that most usage is either:  1. for the convenience
>> of the service provider, or 2. for "poor man's security".
>> Is there another.
>
>I think it's mostly "poor man's security", so things like
>"sendmail" won't balk at talking to you.
>
>I believe the theory is that you can trust forward mappings,
>because of who owns the delegation, but you can't trust
>reverse mappings, mostly for the same reasons.
>
>To establish a trusted peer identity, a "getpeername()" is
>issued.  We know that they aren't lying about their IP
>address becuse everyone disables source routing, and
>because they want packets back from us.
>
>We then do a "gethostbyaddr()" to get the canonical name,
>and then we look it up to see if it had the same IP address,
>because we trust the domain to serve us the IP address we
>are expecting.  If we don't get this, then someone who
>owns the IP address, but not the domain, is spoofing us
>with an invalid name in their reverse map.
>
>
>I don't know how "poor" this really is; we are only
>interested in establishing that the forward and reverse
>mappings are transitive, so we know that whoever has
>the legally delegated ownership of the domain is who we
>are talking to, so that we can hold the domain owner
>accountable for the actions of an IP address.
>
>We may, additionally, use this to ensure that the domain
>claimed in data over the protocol transaction matches the
>domain of the owner of the IP address.  This means that
>we hold the machine with that IP address accountable for
>providing valid data.
>
>This is a widely deployed SPAM countermeasure, based on
>the theory that:
>
>o	Domains are expensive
>o	IP address blocks are expensive
>o	"Burning" either of these in order to SPAM should
>	be a more expensive proposition than the value of
>	SPAM'ming in the first place.
>
>This is also widely deployed for accounting records (logging,
>billing, etc.).
>
>
>> It seems clear to me that autoconfiguration is the
>> favored approach for small or temporary networks. The
>> choice for large networks, as for example - EDS Intranet,
>> may well be different. This implies that DNS updates from
>> autoconfiguration may well not be a requirement.
>
>I think you need to make a distinction between:
>
>o	Machines you trust, because they are installed
>	behind your firewall
>
>o	Machines you trust because they are your customers
>
>o	Machines you trust because the trust is temporary
>
>o	Machine you don't trust, but which someone else
>	might, based on their forward and reverse mappings
>	being transitive
>
>I think the question comes down to a succinct "who owns
>the address assigned during autoconfiguration?".
>
>I think the answer is "partly the assignor, and partly
>the assignee".  Then the question becomes "if I trust
>them enough to give them an address, why don't I trust
>them enough to accept a reverse mapping update from that
>address telling me who they think they are?".
>
>
>You could even be more explicit, and ask the question
>like this: "for a laptop in an airport access point, a
>telecommuting center, or a "wired" boardroom in which
>business between two companies is being conducted, how
>can I establish reverse mappings so that the laptop is not
>crippled in capability vis a vis a permanently installed
>workstation?".
>
>You might also ask "how can I do this such that I don't
>have to start trusting certificates and scanning laptop
>IR ports/WaveLAN cards as they enter my premesis?".
>
>
>I think this argument boils down to "why be protective
>of the reverse mappings at all, if they aren't useful for
>something about which we need to be protective?".
>
>
>One might take the view that, in the future, there will
>be no explicit Intranets, and what we now think of as
>an Intranet will be replaced by a virtual Intranet which
>consists of a VPN and some way to authenticate it to "get
>inside".
>
>In such a world, do we need to establish individual
>identity (setting aside the desirability of getting
>billed per-packet, which varies depending on whether or
>not you are a telco, and the personal privacy issues),
>or merely establish proxy identity, ala "they're inside,
>they must be trustworthy people".
>
>"Inside", in this case, being "the reverse mapping
>matches the forward mapping", until we can get around
>to implementing the world, above.
>
>
>-- Terry Lambert
>-- Whistle Communications, Inc.
>-- [email-masked]
>-------------------------------------------------------------------
>This is formal notice under California Assembly Bill 1629, enacted
>9/26/98 that any UCE sent to my email address will be billed $50
>per incident to the legally allowed maximum of $25,000.
>
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
           Plain Aviation, Inc                  [email-masked]
           LAN/WAN/UNIX/NT/TCPIP          http://www.av8.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Terry Lambert <[email-masked]>
Date: Wed, 04 Aug 1999 10:36:18 -0700

Dean Anderson wrote:
> 
> Having reverse dns mappings is no security at all.  Both are
> easily spoofed.  Having a valid reverse map does not make
> the connection any more or less trustworthy.  Only really
> stupid admins make trust decisions based on DNS information.

How do you spoof a forward mapping, without exploiting
some known (and presumably, fixed) bug?

I trust . to not lie about the delegation of .com.; I trust
.com. to not lie about the delegation of .whistle.com.; I
trust .whistle.com. to not lie about host names in its zone
of control, or its delegations, and so on.

Consider that if I define "fred.whistle.com" in my DNS to
point to 198.3.136.10, I am establishing a name in the
whistle.com domain for this IP address.

It matters very little that I don't own STARSHIP.av8.com
(your machine, which has that IP address), I am permitted
to name it within any domain for which control has been
delegated to me by . and .com. (and so on).

But I can not update the reverse record for 198.3.136.10,
because that has been delegated to .arpa. by ., and then
subsequently to starship.av8.com., and I can't change that
because I'm not in charge of any of the intermediates that
are between . and you.

This trust is implicit in the organization of the DNS
(try to get certificates added to the top level servers;
I dare you; I double-dog dare you -- others have tried).

You can lie in a forward record, but you can't lie in
the reverse unless you own the IP address mapping.  And
if you own the IP address mapping, both the domain name
and the IP address are logged, so welcome to the RBL,
buddy: you'll never send email to me from that IP address
again, and I don't give a damn what you name it.

> Indeed, there is another just as invalid "security" idea
> that one should never use reverse mappings because the
> information might be used by crackers.

I think you meant "provide", not "use", right?

>  Woe unto anyone who needs to get these two
> "security conscious" networks to speak to each other.
> One will not put out reverse maps, the other will not
> trust anyone whose reverse maps are not "correct".

Yes.  The latter set is pretty much a 1:1 intersection
set with "anyone who runs sendmail 8.9.x or above in
its default configuration".

Per address, time-limited certificate would be a better
soloution to this problem.  Unfortunately, there is still
an RSA patent or two in the way of that being standardized
without inviting patent infringement.

If this impacts someone's ability to SPAM -- so the hell
what?  It's _intended_ to.

> This is about as silly as believing that using RFC1918
> addresses enhance security because they are "unroutable".
> Lets just let both of these go into the history of foolish
> ideas.
> 

It's already implicit to DNS's delegation-based organization
(see above: it is deployed as a technical soloution to a
social problem -- "ya cann'a change the laws of physics",
so we design our laws of physics so "ya cann'a misbehave").

In your opinion, what is the proper purpose of reverse
records, if one is not to look them up, or trust their
contents should one be so "foolish" as to look them up?

Is it for displaying in browsers and log files, allowing
the humans who configured them to lie, by proxy, to the
humans whose programs look them up?

And if you answer none of the other questions, whatsoever:

What is the rationale for not allowing a machine, granted
a particular address, to set its reverse record?

The actual agency we are talking about trusting is the
address delegation agency.  If we decide to not trust
them, then we can dike their entire authority block out
of the list of people to whom we are willing to talk.

-- Terry Lambert

---

From: "John S. Quarterman" <[email-masked]>
Date: Wed, 04 Aug 1999 14:10:47 -0500

>of control, or its delegations, and so on.

You break into the machine that is serving whistle.com
and you change its DNS records.  Doubtless others have
also been attacked by this method.

Checking forward against reverse DNS is still better than nothing.
A cracker must at least crack both servers to fake that, or use
some other, perhaps more difficult, method.

Thanks,
John
-- 
John S. Quarterman <[email-masked]>
President, Matrix Information and Directory Services (MIDS)
[email-masked], http://www.mids.org, +1-512-451-7602, fax: +1-512-452-0127
1106 Clayton Lane, Suite 501W, Austin, TX 78723, U.S.A.
See our new Matrix IQ: http://www.miq.net/

---

From: "Perry E. Metzger" <[email-masked]>
Date: 04 Aug 1999 16:08:09 -0400

Faking DNS replies is bloody easy. Queries and replies are matched up
with a 16 bit number, so even if you randomize the numbers, brute
force will allow you to insert spoofed information at least part of
the time. If you can sniff a network that you're attacking, getting
hosts to believe totally faked up DNS replies is even easier.

Good security never relies on DNS information (unless you are using
signed records with the DNS security extensions).l

---

From: Smoot Carl-Mitchell <[email-masked]>
Date: Wed, 04 Aug 1999 15:22:04 -0500

>John Quarterman wrote:

One can also conceive of a person in the middle attacks where DNS
responses are changed in flight.  Given there is no authentication of DNS
responses, the system pretty much trusts that everyone with authoritative
DNS servers will handle their site security in a reasonable manner.
Strong cryptographic authentication would be ideal, but is probably
overkill for most applications and would likely add too much overhead to
DNS because all apps do not need that level of security or trust.

>some other, perhaps more difficult, method.

John is correct.  It is not perfect, but it does prevent the more obvious
and easy DNS spoofing types of attacks.  If I had a really sensitive service
I was offering and I really wanted to be sure of the identity of the
client connecting to my service, I would not trust the DNS information,
but instead rely on some other cryptographically secure method.

Smoot Carl-Mitchell

---

From: "John S. Quarterman" <[email-masked]>
Date: Wed, 04 Aug 1999 16:35:08 -0500

>hosts to believe totally faked up DNS replies is even easier.

If you can sniff a network you're attacking, of course you can do
just about anything.

>signed records with the DNS security extensions).l

Who recommended relying on DNS information?  All said was it was
better than nothing, and it forced crackers to use more difficult
methods, which yes, include the kind of spoofing you mention.
I figured we were all familiar with those and it wasn't necessary
to spell them out.

Could we move on to something other than this dead horse.

John

---

From: Jim Bound <[email-masked]>
Date: Thu, 05 Aug 1999 10:37:21 -0400

>some other, perhaps more difficult, method.

Wisdom I agree with.

Look folks I am trying to ship a product I think doing this is prudent
for now.  Once the standards folks (me included) define a better
solution I will do that too.  I am shipping this to the public for now.
Still not sure on what options I should give them in the user interface
to set up what happens though.

thanks
/jim