Subject: [dnsop] well known MTA's , smtp servers and DNS co-operating

From: Jukka Inkeri <[email-masked]>
Date: Thu, 20 Nov 2003 16:17:02 +0200

We have thought next idea for put together smtp sender checking and DNS
without big changes.

Today many smtp receivers check spam mails/sender/... using
To:
From:
MAIL FROM
RCPT TO
Subject:
and other headers, MIME-types, ....

Problems are with new open relays, using dynamic ip "selfmade"
smtp-servers, ..., new spam ideas,... so we add more and more rules. Why
do not translate method ? Same idea like firewall. Stop everything
except from registered MTA.

Operators have to define smtp servers same way like  NS (and MX) are for
domains.

Today every services based mostly on domain rules, but mostly smtp
sending has done  using operator's networks smtp-server, not domains.
Ofcource operator can add more power to check all outgoing smtp session
open function. Only registered stmp servers can open connection.

Need to check: Do we trust for this caller (MTA)? And this checking done
with reverse lookup, based on network, not domain.

Add new qtype ex. SMTP
ex. zone 111.111.111.in-addr.arpa include usually
1  IN PTR some.name.

add new record
@	IN	SMTP	111.111.111.123
	IN	SMTP	111.111.111.182

Then we have problem with new type ? But if we use reverse MX like MX
using in domain ? Every dns work now. 1st step is MX, but in future also
own record type SMTP.

@	IN	MX	10 111.111.111.123.
	IN	MX	10 111.111.131.182.
; or
	IN	MX	10 smtp.domain.xx.
	IN	MX	10 smtp.other.xx.

After this receiving mta looks sender mta's ip, make reverse check with
network (1st 3 octets, if no answer then  2 octets ... ). 1st look, is
this ip from my network ? If not, check is this sender registered.

In this idea every smtp-servers which make smtp connection to Internet,
must be registered. So if you have not registered mta, then you must use
smart relay / proxies like normal mail clients works.

My example:
dig @194.197.204.121  204.197.194.in-addr.arpa. mx
- only 5 registered MTA

sender ip is ex. 194.197.204.103, then make reverse-netname hostname ex.
with some regexp tools like
echo "194.197.204.103" | \
sed "s/\([0-9][0-9]*\)\.\([0-9][0-9]*\)\.\([0-9][0-9]*\)\.\([0-9][0
-9]*\)/\3.\2.\1.in-addr.arpa/"

You get answer 204.197.194.in-addr.arpa

Then make lookup and get some hosts ... check  was caller ip in that
list. Simple feature add to tcpwrapper, smtp-proxy, smtp-server  and so
on. Control connection, and after open connection maybe look also inside
smtp data = current filter method.
Just like in real life, we have only some postoffice, not in every
home/office.

We think that this is possible to do worldwide very quickly, using ex.
whois databases and apnic+arin+lacnic+ripe databases. Or co-operate with
some virusmaker = quicker :). I mean add those reverse MX records.

security1 At_sign awot dot fi

-jukka-
PS. as you see, english is not my primary language, but I hope that idea
has understood.
-- 
______________________________________________________________________
Karjalan ATK-Awot Oy, Jukka Inkeri
Polvijärventie 65 C, 80400 YLÄMYLLY, FINLAND
http://www.awot.fi security1 At_sign awot dot fi

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Ed Lewis <[email-masked]>
Date: Thu, 20 Nov 2003 13:59:13 -0500

> We have thought next idea for put together smtp sender checking and DNS

I think one of the lessons of the "*.com incident" is that an
application (such as "mail") ought not rely on the *mere* *presence* of
data in the DNS for the application's security.

E.g., as reported at the IEPG meeting prior to the last IETF (I can't
find on-line notes yet, but hey, it's just been a week), IP address
space hijacking has happened.  (I'll keep this short because it's OT for
DNSOP.)  The bottom line is that spammers have "taken over space" at
times to source spam.  If they accomplish doing this, it's not much more
work to assert they have name servers and populate the servers with this
data.

Backing up to the DNS track - if anyone is going to rely on the DNS for
security (and by that I mean authorization to send mail in this case)
let's get the DNS to be secure itself (source integrity) and see how
that goes.  Until then, piling security on top of the DNS is foolish.

.

---

From: Ed Lewis <[email-masked]>
Date: Thu, 20 Nov 2003 15:00:25 -0500

I'm a bit puzzled...

On Thu, 2003-11-20 at 14:35, Ted Lemon wrote:
> I should say that I'm not speaking up in favor of the proposal, but 
> rather against your argument against it.   This argument isn't correct, 
> and I know it's been used against at least one scheme for increasing 
> verifiability that would have (IMHO) been very much worthwhile, despite 
> not being a panacea.

Are you suggesting that there is a way to put data in DNS and be able to
rely on it for security?  (The double negation is playing tricks with my
head.)

A lot of services have relied on matching forward and reverse records
for authenitcation of the client, but this is seen as weak.  So much so
that the "in-addr required" draft can't state this as a reason that the
reverse map is important to have.

Post-"*.com" I am much more reluctant to encourage anyone to rely on the
"current state" of the DNS for security (here spam non-authorization). 
The one small change, for the protocol, had huge repercussions in other
areas.  And the "small change" was completely within the DNS protocol
specification.

The above two paragraphs are why I'd discourage using the presence of
data in the DNS as a step towards an authentication decision.

.

---

From: Mark Foster <[email-masked]>
Date: Thu, 20 Nov 2003 10:53:19 -0800

> We have thought next idea for put together smtp sender checking and DNS

You really should check out http://spf.pobox.com/ which addresses this 
very issue. Not to mention http://amtp.bw.org/
-- 
=> Mark Foster <[email-masked]>	http://mark.foster.cc/
=> Was I helpful? http://svcs.affero.net/rm.php?r=fostermarkd

.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Nov 2003 13:35:41 -0600

> that goes.  Until then, piling security on top of the DNS is foolish.

No offense, Ed, but this is exactly what I was complaining about at the 
plenary when we were asked to comment about the net abuse problem.   
Yes, using the DNS as a gateway to control whether or not spam gets 
delivered is not, by itself, going to eliminate spam.   Yes, it is 
possible to circumvent non-DNSSEC dns protection schemes.   But with 
spam and with viruses, a solution that works well in some large cases 
can have a significant impact.   Even if it is not perfect, and even if 
it's possible to bypass it in some cases, it will still be useful.

.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 21 Nov 2003 05:52:48 +0900

Ed Lewis;

> "current state" of the DNS for security (here spam non-authorization). 

Does it mean you can't expect that an entity recklessly put "*.com"
behave properly to operate secure DNS securely?

> data in the DNS as a step towards an authentication decision.

Involving two different authorities for reverse and forward lookup
gives us certain security.

						Masataka Ohta

.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Nov 2003 15:49:26 -0500 (EST)

The issue of using DNS to do spam checking has been discussed several
times on both DNSOP and Namedroppers, and probably elsewhere.

DNS is not a tool for spam filtering. This is because it is not possible
to assign any level of trust based on anything that is learnable through
DNS.  Do not be misled by the pundit anti-spam radicals who suggest
otherwise. Their methods, and the foundations on which those methods are
based, have been previously debunked.

Also, it has also been proven that open relays have never contributed to
spam, and in fact do not allow or otherwise improve anonymity despite the
claims of anti-open relay radicals. Nor are there any other benefits to
open relay abuse. Also, the latest numbers presented to the FTC on open
relay abuse reported last May indicate that open relays are involved in
only 5% of spam, and that this number continues to decrease, even though
the number of open relays continue to increase.  This trend shows (at
least) that "spammers" have learned that open relays do not offer any
benefits. Indeed, the trend supports the notion that "spammers" never
abused open relays--rather anti-spammer radicals seeking to proactively
abuse them to get them closed did the abusing. In conjunction with this
trend away from open relay abuse, is a trend of open relay blacklists
closing, and a corresponding decrease in open relay scanning, and relay
abuse. In 7 years of open relay operations, this was nearly universally
the case in my experience--only anti-spammers ever abused our relays.  Of
those "anti-spammers"**, one was found to be the abuse admin at Verio, and
was eventually fired for abusing our relays from his work computers.

Further, Information Theory suggests that one cannot limit spam through
protocol changes. The information theory analysis starts by identifying
spam as a covert channel, and then using the machinery of information
theory to deduce limits on what can be done. If you are interested in the
subject, I'll be happy to discuss it further offline. There is also a
recent article in Data Mining magazine on fraud detection that runs along
the same lines, but of course, doesn't mention information theory.
Instead, the D.M. article notes that fraud artists adapt, and that one can
never be sure there isn't fraud, nor can one detect 100% of fraud, except
by designating everything fraud, and then having a very high false
positive rate. Simlarly, if one says nothing is fraud, then there is a
high false negative rate.

Spam detection, similarly to fraud detection, and covert channel
detection, is a matter of message analysis, not protocol gyrations.  Look
to the spambayes groups and the content analysis methods for spam
detection.  Real "opt-in"  spammers, such as Exactis, cannot be stopped as
that is a violation of the Sherman AntiTrust Act. Of course, real spammers
will also take your address off their list.  Bogus spammers, however, with
no commercial intent, can be stopped, and bogus spammers cannot resort to
the Anti-Trust Act, which only protects commerce.  These bogus spammers,
however, seem to be really be radical anti-spammers intent on getting spam
banned by proactively generating annoyance.  The best strategy against
these people is the elimination of virus infections, and the criminal
prosecution of those breaking into computers with viruses, which is a
federal felony in the US, and a crime in many countries.

If you run open relays, look for scanning in order to prevent abuse, as
scanning is necessary for abuse. In 7 years, we have only found anti-spam
groups scanning. No spammers were ever detected scanning for open relays
on our 70,000 or so ip addresses. Nor have any real spammers ever abused
our relays.  So either the "anti-spammers" were giving the results to
spammers (possible) or the "anti-spammers" were themselves doing the abuse
(found to be the case with Verio admin).  In whatever case, we found that
detecting and blocking the "anti-spammers" scanning drastically reduced
the abuse of our open relays.

		--Dean

** I put "anti-spammers" in quotes because you can hardly call someone who
abuses/spams an open relay to 'proactively get it closed' an anti-spammer.

.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Nov 2003 16:31:35 -0500 (EST)

> reverse map is important to have.

What "in-addr required" draft is that?  I must have missed something...

		--Dean

.

---

From: Kenneth Porter <[email-masked]>
Date: Thu, 20 Nov 2003 16:33:16 -0800

> Add new qtype ex. SMTP

Is this the same as the proposed RMX type?

<http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt>

I'm not sure if I'm mis-remembering, but haven't the IPv6 guys decided not to
require reverse DNS? That would kill any anti-spam technique requiring it,
since there's no guarantee you can get your upstream to delegate something it
doesn't have.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Nov 2003 19:59:25 -0600

> since there's no guarantee you can get your upstream to delegate 

The text in this draft that talks about the reverse namespace doesn't 
make a lot of sense to me.   I think we should avoid getting into the 
nitty-gritty here, but suffice it to say that no, reverse DNS is not 
required to make RMX useful.

.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Nov 2003 22:59:30 -0500 (EST)

> gives us certain security.

Two different authorities make no difference in the security for spoofing,
cache poisoning, or other attacks.

Second, forward and reverse are typically delegated to the sam authority
(the end user)

So, your claim is absolutely wrong. I can't believe we are going to have
this discussion again.

		--Dean

.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 21 Nov 2003 19:54:58 +0900

Dean Anderson;

> cache poisoning, or other attacks.

I'm talking about practical security of the real world.

In the real world, authorities can misbehave or be compromised.

That you use cryptographic security does not protect you from
a misbehaving or compromised authority.

Thus, two different authorities make difference.

As I post recently, DNS cache poisoning can be prevented.

MITM will not be there if you have proper local configuration
and ISPs are reliable, which is no more demanding than to believe
secure DNS is secure, that is, you have proper local configuration
and registries are reliable.

> Second, forward and reverse are typically delegated to the sam authority

Then, you can identify the attacker, which is best possible reaction
against most DoS, in two different ways.

> So, your claim is absolutely wrong. I can't believe we are going to have

I'm talking about the real world security, you are not.

						Masataka Ohta

.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Nov 2003 15:57:01 -0500 (EST)

> I'm talking about practical security of the real world.

I'm talking about DNS security, or lack thereof.

> a misbehaving or compromised authority.

The above is literally true. Irrelevant, but literally true nonetheless.

> Thus, two different authorities make difference.

And in the real world, DNS can't be used for security, no matter how many
different "authorities" you have. 2, 10, or 100 different authorities
won't change that.  Haven't you learned your lesson on this? Obviously,
not.

> As I post recently, DNS cache poisoning can be prevented.

Hmm. I'll have to re-read that. However, there are other attacks that
cannot be prevented.

> against most DoS, in two different ways.

If you used reverse DNS as your means of identification, you won't be able
to identify the attacker.

DOS (Denial of Service) identification has nothing whatsoever to do with
DNS.  The DOS packet source IP address is forged (hence the DOS), so
knowning either the IP address or the Reverse DNS or the forward DNS
associated with the forged source IP address is useless.

And of course, the DOS destination IP is you, so that won't help much ;-)

> > So, your claim is absolutely wrong. I can't believe we are going to
> > have this discussion again.

> I'm talking about the real world security, you are not.

Apparently, you don't have much real world experience with DOS attacks,
given you are unaware that the IP address in the packets are forged, so
reverse DNS lookups on those IP addresses are useless.

.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Nov 2003 15:38:55 -0600

> reverse DNS lookups on those IP addresses are useless.

It looks a bit like the two of you are talking at cross purposes.   Are 
we actually debating whether or not PTR records can be used for 
security purposes?   I don't *think* that's what Ohta-san is saying, 
but perhaps I am misunderstanding him.

.