[Asrg] Problems that make the RMX proposal infeasible

I've been tracking this discussion for a little while and thought that
I'd finally de-lurk and give some comments.

I'm going to summarize some points that Adam Back has made and add
a little because it seems that some people have still not understood
the problems.  

Firstly, the DNS protocol is subject to spoofing.  This is a fundamental
problem with the protocol and cannot be fixed without totally changing
the protocol.  This is due to the fact that the first answer with a 
matching request ID is accepted.  Since the request ID is a 16 bit
field,
it is trivial for an attacker to send 65536 100 byte packets and provide
this answer.  

This is bad in general, but somewhat mitigated by the fact that it is
hard to determine when a given server will make a request and the fact
that most important things are backed up with SSL.  An attacker
may know that you bank with Wells Fargo, but will find it difficult to 
predict exactly when you're going to try and log into their servers.
Even if they manage that, you'll still be presented with a browser
warning
(or if they direct you to https://www.weelsfargo.com you stand a chance
of
noticing the unexpected URL)

In the context of the RMX proposal, neither of these are true.  The
attacker
knows roughly when you'll do the lookup. (Either when the MAIL FROM line
is
sent or when the message has been received.)  Furthermore, since the
attacker
gets to choose the TTL, the value of this attack is greatly increased.
Since the TTL is specified as an unsigned integer and given in seconds
this means that they only have to succeed with this attack once per
server.

Furthermore, since they don't care whether you're reading spam from 
spammer@foo.com or spammer@bar.com, if they somehow fail the first
attempt, 
they can retry over and over again with varying domains.  As soon as
they
win once, they can spam for however long your DNS server actually caches
the record.

DNS IS NOT A VALID METHOD OF AUTHENTICATION!!!!!!!!

Note:
While it is possible to make this attack harder by varying the source
port too (which DJBDNS does and BIND doesn't) the total search space
is still too small to withstand a concerted attack.  This is made worse
by the birthday attack mentioned in the DNS Cache Poisoning - TNG paper)

Papers to read:
DNS Cache Poisoning - The Next Generation
The old problem of DNS cache poisoning has again reared its ugly head. 
While some would argue that the domain name system protocol is
inherently 
vulnerable to this style of attack due to the weakness of 16-bit 
transaction IDs, we cannot ignore the immediate threat while waiting for

something better to come along. There are new attacks, which make DNS 
cache poisoning trivial to execute against a large number of nameservers

running today. The purpose of this article is to shed light on these new

attacks and recommend ways to defend against them. 

http://www.securityfocus.com/guest/17905

--------
Mike Schiffman (aka route, past editor of phrack) has done an analysis 
of the current state of the world's DNS infrastructure.

Synopsis:
DNS servers across the Internet running BIND are not up to date with 
security patches and software updates. As a result, a significant
fraction 
of the Internet's DNS servers is vulnerable to compromise, subversion, 
denial of service, and general misuse. Considering that DNS is the
lynchpin 
of the corporate enterprise, the impact of these vulnerabilities is 
significant and a successful attack could bring down any online
business. 

http://www.packetfactory.net/DNS/

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg