DNS is broken, and by extension so is RMX (Re: [Asrg] Re: RMX Records)

On Tue, Mar 04, 2003 at 10:26:00AM +0000, Roland wrote:
> Hadmut Danisch wrote:
> > Fixing the security problems of 
> > DNS is the task of another IETF working group. We shouldn't try
> > to improve the whole world, but focus on spam.
> 
> Bulkers need to spew out millions of mails, they would need to poison
> thausands of nameservers which is simply not feasible.

I think you are have not looked at DNS security issues.  It is far
easier to exploit and the cost can be amortized over many messages.
Read the paper I quoted:

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

It summarises a many of the known vulnerabilities and shows the
limitations to what an implementation can do without changing the
protocol.

On the risks associated with DNS security for the RMX application,
consider:

a) the sender knows when the SMTP server will make the DNS request (he
just injected the mail) so he can send a flurry of DNS UDP response
packets to arrive before the real response;

b) the sender can choose the TTL on his forged DNS response, making it
last for weeks;

c) during this time he can spam at full volume.

> Such harmful manipulations are already covered by the laws in many
> countries, and there are more secure alternatives to bind available.

I don't see law being any significant barrier to spam.  There are too
many jurisdictions, too many opportunities for spammers to hide their
identities, and too much money involved for it to be a deterrent; and
anyway introducing laws into internet protocols invites hamfisted
politicians to introduces laws generally to the detriment of internet
users who are still poorly represented.

Hadmut claims this is not a problem because we can leave fixing DNS to
the IETF:

> Fixing the security problems of DNS is the task of another IETF
> working group. We shouldn't try to improve the whole world, but
> focus on spam.

but basing a supposed fix on a heavily broken protocol, with no known
solution without replacing the entire protocol, and big deployment
problems in doing that in a backwards compatible way, and a long
history of failure to deploy DNSSEC a backwards compatible and
incremental improvement introduces more problems than it fixes.

I think the deployment path is the most difficult challenge of
anti-spam measures.  Adding a dependency on another hard tech problem
with a yet unsolved deployment path doesn't solve the problem.

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