Re: The Large-Scale Threat of Bad Data in DNS

[Greg Steuck <greg-bugtraq () nest cx>]

Let's analyze the problem. We observed fallibility of SSL which is
supposed to identify the parties in conversation by binding them to some
flesh-world entities. The implementation turns out to be insecure even
though ideas are sound.

Now you are suggesting to move this identity proof burden from SSL to
DNSSEC (let's not even discuss DNS). Why do you think it will work any
better? Instead of 1 complex protocol and real-world identity proof
process that CAs execute now you will have 2 processes doing pretty much
the same thing.

DNSSEC on it's own will not do you any good. Imagine you have a 100%
reliable way of translating names into IPs. Does this guarantee you will
be talking who you meant to talk to? No: think active
man-in-the-middle. So SSL (or some other authenticated channel solution)
is still inevitable.

More inline.

> > > > > "FORENSICS" == FORENSICS ORG Security Coordinator <secalert () forensics org> writes:

    FORENSICS> The third protection is enhanced security policy for
    FORENSICS> Internet infrastructure operators. 1) Enforce a new
    FORENSICS> common-sense policy for DNS and DNSSEC (which is not
    FORENSICS> currently designed to prevent "bad data" if that "bad
    FORENSICS> data" is entered on purpose by an attacker who
    FORENSICS> legitimately, or through key or credential theft, has
    FORENSICS> control of a DNS zone) which says that IP address can't
    FORENSICS> be misappropriated without permission by anyone who
    FORENSICS> registers a domain name; instead, everyone who wishes to
    FORENSICS> map a domain name to an IP address should be required to
    FORENSICS> obtain permission first from the authority who has been
    FORENSICS> assigned control (and responsibility) for managing the IP
    FORENSICS> address block that contains the IP address.

Are you suggesting that I will need a permission from some "owner" to
add an "A" record binding some name in my domain to "his" IP address?

    FORENSICS> 2) Require,
    FORENSICS> as a condition of participating in the DNS (or DNSSEC)
    FORENSICS> that legitimate, verifiable contact information be
    FORENSICS> registered with the appropriate authority (IANA, ARIN,
    FORENSICS> RIPE, etc.) for the legal entity that has been assigned,
    FORENSICS> and has accepted, responsibility (and possibly legal
    FORENSICS> liability) for each address block.

Right, we can't do it right for SSL certificates that cost dozens of
dollars a piece. Are you suggesting having a similar burden for each DNS
record? What a gold mine for CAs! Oh, and IP address spoofing will do
wonders for liability.

    FORENSICS> 3) Exclude from
    FORENSICS> participation in DNS (or DNSSEC) any IP address that
    FORENSICS> belongs to an address block that is under the control of
    FORENSICS> anonymous or unverifiable entities.

I have an alternative suggestion: stop trusting DNS, use it as a
convenient shortcut, but keep in mind that it is no more than a
convenience.

Finally, if understood you correctly you were mostly concerned about the
servers outside answering with your internal addresses to your DNS
queries. It wouldn't take much to enhance your DNS cache (recursive
resolver) software with ACLs that dictate which answers you expect to
come from which source addresses. Megainfrastructure encompassing the
whole world is not required for that.

Bye
Greg