Subject: RE: pros and cons of RMX (Re: [Asrg] Declaration to the world)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Mar 2003 13:06:56 -0800

Adam,

Paul kindly forwarded me a copy of his paper he sent out last year 
which addresses the issue you raise.

The security hole can be eliminated with a simple nonce scheme, see
my earlier post.

	Phill

> -----Original Message-----
> From: Adam Back [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 3:46 PM
> To: Hallam-Baker, Phillip
> Cc: Hadmut Danisch; [email-masked]; Adam Back
> Subject: Re: pros and cons of RMX (Re: [Asrg] Declaration to 
> the world)
> 
> 
> Phil wrote:
> > [...] If DNS is broken we can fix it for this application.
> 
> That was my request: 
> 
> - RMX proposers should demonstrate fixes to it's security problems
> 
> - the deployment of any fixes to DNS should be considered part of the
> deployment picture for RMX
> 
> (Deployment being probably the biggest challenge with any anti-spam
> solution.)
> 
> Adam
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Mar 2003 15:48:00 -0800

> Why is 65536 100 byte packets a lot? That's only 655k. 

Because it would stick out like a giant day-glo beacon shouting

HEY YOOO-HOOO I AM GOING TO SPAAAAAM YOU NOW...

If not we just make it a requirement to use a fixed version of DNS. 

		Phill
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jonathan Wilkins" <[email-masked]>
Date: Thu, 6 Mar 2003 16:23:22 -0800

Sure.. But only if you add a new capability to the DNS server
to signal the SMTP server that this is occuring.  Or install
a NIDS system that does the same.  More infrastructure to 
fix a broken system.  Patches upon patches upon patches.

Never mind that you then have to improve NIDS to take care
of certain issues if you've got a determined attacker (See
http://www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.html 
and
http://monkey.org/~dugsong/fragroute/ )

And you would have some pretty determined attackers if you've 
got a large enough site (and therefore enough spam recipients to
make it worth the attackers energy)

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Thursday, March 06, 2003 3:48 PM
To: Jonathan Wilkins; Chris Lewis; ietf anti-spam research group

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Mar 2003 16:29:47 -0800

> fix a broken system.  Patches upon patches upon patches.

That is rhetoric, not an argument.

DNS has some problems, they have not been serious enough to fix till now but
the security community always understood how to fix them.

This is an IRTF working group. The expected outcome is either proposals to
change protocols or a statement why the problem is impossible, not
worthwhile or otherwise not to be addressed.

	Phill

---

From: "Jonathan Wilkins" <[email-masked]>
Date: Thu, 6 Mar 2003 16:48:57 -0800

No it's not rhetoric.  It's a statement of fact.  DNS alone
doesn't solve this problem.  If you want RMX to work, you need
to do one of the following:
1. patch the DNS protocol
2. patch DNS servers to keep track of multiple bogus responses 
   and inform the SMTP server
   (what you're going to do when this happens is unclear.  Since
   they're UDP and spoofable, surely you're not proposing that 
   all data from that IP be dropped)
   See any IDS list for details on the hazards of automated
   filtering.
3. Add a NIDS that watches for lots of unasked for DNS replies
   and communicates with your SMTP server.

If you're doing this much to compensate for a broken protocol, 
you ought to re-evaluate the cost-benefit equation.

I agree with you that DNS hasn't been a major problem for the
internet up until now, but that's because most uses don't make
it easy for an attacker to spoof.  Since an attacker doesn't
know when you're going to go to your bank's site (and therefore
do a DNS lookup), it's difficult for them to spoof a DNS reply.
This is not the case for RMX.  The spammer controls the timing
of the lookup.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Thursday, March 06, 2003 4:30 PM
To: Jonathan Wilkins; Hallam-Baker, Phillip; Chris Lewis; ietf anti-spam
research group

DNS has some problems, they have not been serious enough to fix till now
but
the security community always understood how to fix them.

This is an IRTF working group. The expected outcome is either proposals
to
change protocols or a statement why the problem is impossible, not
worthwhile or otherwise not to be addressed.

	Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Mar 2003 17:25:54 -0800

> you ought to re-evaluate the cost-benefit equation.

Perhaps we might get further if you just told us all your pet 
theory rather than making us all wait till you have attacked
everything else.

You might find that we don't consider your pet theory to be
incompatible or in competition.

You appear to have the same problem Bruce Schneier had with security
before he wrote secrets and lies. The perfect is the enemy of the 
good. Security is risk control, not risk elimination.

Spam is an infestation, we are not going to find a magic bullet.
We are going to have to fight a long war on many fronts. We shall
fight them with filters, we shall fight them with authenticated
mail, we shall fight them in the legislatures and in the court 
room. We shall never surrender but if the Internet shall last a 
thousand years it shall be said of us that this was our finnest
hour.

		Phill

	Phill

---

From: "Jonathan Wilkins" <[email-masked]>
Date: Fri, 7 Mar 2003 11:56:41 -0800

If an attacker fails when spoofing foo.com they can turn
around and spoof bar.com.  If that fails too, they can keep
trying until they manage to get something cached.  

Once something's cached they can spam all they like.

You always know where to spoof.  You send the packets at
the SMTP server, since that's the machine that's going to
make a request of it's server.  

Further, your estimate of the success ratio is probably overly
pessimistic.  There are a bunch of layers to go through for
a valid response to be returned.  The SMTP server makes a request
to it's local DNS server which asks the root server who's authorative
and then turns around and asks that server for the data.

That's several round trips versus a bunch of direct sends.

-----Original Message-----
From: Chris Lewis [mailto:[email-masked]] 
Sent: Thursday, March 06, 2003 9:26 PM
Cc: ietf anti-spam research group

> Why is 65536 100 byte packets a lot? That's only 655k.

(a) it assumes you manage to guess the right packet before the real 
server gets its answer thru.  Let's be generous, and say that they beat 
it 50% of the time. So, half of your spam run is toast.
(b) it's 65536 100 byte packets for _each_ MTA you're trying to get 
around - _if_ you know where to flood.  Worthwhile for attacking large 
ISPs.  Not small MTAs.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 7 Mar 2003 13:30:41 -0800

> trying until they manage to get something cached.  

This attack is very easily prevented.

It has only a chance of 1 in 2^16 of succeeding per spoofing
try.

The DNS client can very easily detect attempts at spoofing.
It simply keeps a record of unsolicited DNS responses.

So if the DNS client receives 10 unsolicited responses for 
xyz.com the client simply notes that it is under attack from
a party wanting to spoof that address.

So the probability of success withthat threshold is 1 in 6636.

> make a request of it's server.  

That is not going to work. The SMTP server knows what the
address of its DNS server is. You may know the destination
address but you don't know the source.

If it is an issue you can secure the DNS client/server 
connection using TSIG.

I do not find this attack to be persuasive. I might have
concerns if we were considering a cryptographic protocol
intended to provide robust confidentiality and integrity.
However for our particular application the perfect is going
to be the enemy of the good.

The IETF has not been particularly good at designing security
protocols. The only two major successes, Kerberos and SSL were
both developed and deployed successfully before being brought
to the IETF. Internally developed security protocols have 
tended to fall victim to requirements bloat leading to
protocols that are too inflexible to deploy.

For example we could have easily provided a usefull degree of
security in SMTP by simply incorporating a certificateless
DH key exchange to secure the connection. That idea was squashed
as there is a man-in-the-middle vulnerability so we have had
NOTHING instead - until people started to use STARTTLS in a
configuration that i actually vulnerable to that same MITM 
attack.

All we have to do to defeat spam is to reduce the probability 
of success to 1 in 100 or so and the spam sender costs are
toast. We have a technology already designed and deploed in
100 million clients that reduces the probability of success
to 1 in 2^128 - S/MIME. Only it is not going to provide a 
solution at current deployment rates.

		Phill

---

From: "Jonathan Wilkins" <[email-masked]>
Date: Fri, 7 Mar 2003 14:18:05 -0800

I agree completely that if you go ahead and give your SMTP
server knowledge of what's happening in your DNS server that
this attack can be thwarted.  However this is bad design.
You're creating a linkage that is unnecessary.  Why not
look for an alternative transport.  Why are you so stuck on
using DNS?

Allowing a mail administrator to state that "only these IP
addresses will send mail for my domain" isn't a horrible idea. 
It is the use of DNS as a transport for this statement that
is the problem.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Friday, March 07, 2003 1:31 PM
To: Jonathan Wilkins; Chris Lewis
Cc: ietf anti-spam research group

		Phill