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
