Subject: Comments on Draft IRTF ASRG DNSBL - 07

From: Jonathan Curtis <[email-masked]>
Date: Tue, 11 Nov 2008 12:49:38 -0800

Having spent 13 years managing abuse (Spam/Phishing/Botnets) within a large ISP organization, 5 to 6 years in a leadership position of the Messaging Anti-Abuse Working Group and active member of the Canadian National Cyber-Forensics Training Alliance, I can say that DNSxL's are a critical part of most ISP's security infrastructure.  Here are my specific thoughts on "http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-07"

1. A large percentage of ISP's, ESP's, Enterprise and Internet Commerce companies have managed to build significant infrastructure that make extensive use of DNSxBL's for E-Mail related Phishing, Scam, Spam and Malicious Transaction Prevention. These practices have been in place for several years without a standard.  As new DNSxL's, applications for DNSxL's and IPv6 DNSxL's emerge, however, I believe standardization will become increasingly valuable in helping manage the technology change within ISP's, Enterprise, NGO, Not-for-profit Organizations and vendors.

2. The impact of DNSxL's when applied on Inbound Email Servers is significant with very little collateral damage. A good estimate is that over 70% of all spam email is prevented by the application of DNSxBL's, sparing many service providers millions in hardware that would otherwise be spent processing and storing these messages.  In all cases, without this type of implementation, customers' inboxes would be rendered completely useless.

3. When discussing DNSxL's with various carriers, it is clear that careful due-diligence has been applied to ensure that the risk of false positives is minimized. In several cases, the DNSxL is merely used as part of an overall reputation database that helps determine the delivery decision.

4. With the evolution of Internet Threats, ISP's and Enterprise's have deployed DNSxBL's to improve Data Security/Protection, Trust, Reliability and Confidence of Employee's and Customers. They have deployed DNSxL's that protect against phishing, spam, child exploitation and other malicious intended transactions.  To this end, several not-for-profit and for-profit organizations/agencies/vendors/governments have been making extensive use of DNSxL's to protect country, city, community and citizens. This document will help foster standardization for those organizations.

In summary, Nominum has made commercial investments to enable ISP's to make use of highly scalable DNSxL's within their infrastructure. As an industry stakeholder in the standardization of DNSxL's we welcome and support this document.

Thanks for your time,

Jonathan

Jonathan Curtis
Nominum, Inc.

2003 - 2008  Founder and Vice/Chairman of The Messaging Anti-Abuse Working Group

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 Nov 2008 14:57:32 -0800

Hi -

> From: "Jonathan Curtis" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, November 11, 2008 12:49 PM
> Subject: Comments on Draft IRTF ASRG DNSBL - 07
...
> 2. The impact of DNSxL's when applied on Inbound Email Servers
> is significant with very little collateral damage.
...

I guess this depends on one's view of what consitutes "very little
collateral damage."  I've had my own mail blocked, both when sent
from my current ISP, Earthlink, as well as when sent via the servers of
my last employer, BMC Software.  As mailing list admin
for three IETF-hosted mailing lists (disman, agentx, and ltru) I've
seen bounces and automatic unsubscribes due to IETF's
infrastucture having been blacklisted.  Thus I'm rather
skeptical about "very little collateral damage."  This may
be due to misuse of DNSxL technology or other reputation
systems, but if this small sample is any indication of the
extent to which the technology is being used inappropriately
or incorrectly, it suggests that significant educational effort in
"correct" or "appropriate" uses of the technology is needed.
(Assuming that it's not an indication that there are fundamental
architectural flaws...)

"Informational" makes sense to me at this time.
"Proposed Standard" does not. 
http://www.ietf.org/mail-archive/web/ietf/current/msg53668.html
sums up the issues nicely, in my opinion.

Randy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Nov 2008 09:57:06 +1100

In message <[email-masked]
>, Jonathan Curtis writes:
> 
> 2. The impact of DNSxL's when applied on Inbound Email Servers is significant 
> with very little collateral damage. A good estimate is that over 70% of all sp
> am email is prevented by the application of DNSxBL's, sparing many service pro
> viders millions in hardware that would otherwise be spent processing and stori
> ng these messages.  In all cases, without this type of implementation, custome
> rs' inboxes would be rendered completely useless.

	Small sites route around the damage caused by used DNSxBLs.
	This makes the outbound email more fragile.  It also stops
	the small sites being able to use cryptography to stop man
	in the middle attacks as they are forced to insert a middle
	man.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 11 Nov 2008 16:03:26 -0800

> "Informational" makes sense to me at this time.

Why?

What are the specific aspects of this specification that fail to qualify for 
Proposed Standard?

What changes to the specification will fix these deficiencies?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Nov 2008 07:05:13 +0100

On 11/12/08 1:03 AM, Dave CROCKER wrote:
> Why?
>
> What are the specific aspects of this specification that fail to 
> qualify for Proposed Standard?

This is precisely what I want to know.
> What changes to the specification will fix these deficiencies?

What he said.

Eliot

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 11 Nov 2008 18:17:55 -0500

On Tue, Nov 11, 2008 at 02:57:32PM -0800, Randy Presuhn wrote:
> This may be due to misuse of DNSxL technology or other reputation

I agree -- both with the notion that much of this is due to misuse
of the technology and that significant educational effort is needed.
That effort has been underway for over a decade, and some of the people
commenting here (as well as the document's author) have been a large
part of it.  This document may thus in one sense be seen as an adjunct
to those efforts, since it's a BCP for *operating* DNSBLs -- adoption
of which will complement education directed at those *using* DNSBLs.
(And as Chris alluded to briefly, perhaps a second BCP which concerns
itself with that second audience would be a good idea.)

---Rsk

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Nov 2008 17:55:36 +0000

On Wed, 12 Nov 2008, Mark Andrews wrote:
>
> It also stops the small sites being able to use cryptography to stop man
> in the middle attacks as they are forced to insert a middle man.

SMTP over TLS to an MX does NOT protect against man in the middle attacks.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
LUNDY FASTNET IRISH SEA: WEST OR NORTHWEST 4 OR 5 BACKING SOUTHWEST 5 TO 7.
SLIGHT OR MODERATE. FAIR THEN RAIN OR DRIZZLE. GOOD BECOMING MODERATE OR POOR.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Nov 2008 11:34:14 +1100

In message <[email-masked]>, Tony Fi

> SMTP over TLS to an MX does NOT protect against man in the middle attacks.

	It does when you turn on DNSSEC so that it covers the MX
	RRset, or the synthesized MX RRset when there is no MX RRset
	but there are address records (also covered by DNSSEC), and
	match the server certificate to the (synthesized) name in
	the MX record.

	We have the technology to do this.  People just need to use it.

	Mark

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 12 Nov 2008 17:01:50 -0800

Mark Andrews wrote:
> 	It does when you turn on DNSSEC 

Perhaps I'm not understanding, but I think you just confirmed that Tony's 
statement was correct.

d/
-- 

   Dave Crocker

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Nov 2008 14:04:48 +1100

> Perhaps I'm not understanding, but I think you just confirmed that Tony's 

	No.  To protect against man-in-the middle you need to know
	with whom you are supposed to be talking. SMTP over TLS
	will do that provided you have that knowledge.  One way to
	aquire that knowledge is to use DNSSEC to prevent spoofed
	MX records.  Another way is to use configuration information.

	You also need to configure you MTA to not use plain SMTP
	if STARTTLS is not offered by MTA.  This can be done globally
	or on a MTA by MTA basis.

	Having the ability to signal if the MTA is supposed to offer
	STARTTLS in the DNS would remove the downgrade attack path,
	in the general case.

	Mark

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Nov 2008 11:50:05 +0000

On Thu, 13 Nov 2008, Mark Andrews wrote:
>>>In message <[email-masked]>, Tony Finch writes:
>>>>
> No.  To protect against man-in-the middle you need to know with whom you
> are supposed to be talking. SMTP over TLS will do that provided you have
> that knowledge.  One way to aquire that knowledge is to use DNSSEC to
> prevent spoofed MX records.

You also need the server to provide a verifiable TLS certificate. The vast
majority of them are not. This problem is perhaps even harder to fix than
the lack of DNSSEC.

http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

> Another way is to use configuration information.

Which is useful for a few select senders and recipients, but doesn't
scale to all the external destinations a site might use.

> You also need to configure you MTA to not use plain SMTP if STARTTLS is
> not offered by MTA.  This can be done globally or on a MTA by MTA basis.

Which would mean you can only send email to a vanishingly small number of
destinations.

> Having the ability to signal if the MTA is supposed to offer STARTTLS in
> the DNS would remove the downgrade attack path, in the general case.

Right, there are several improvements of this kind that need to be made to
the protocol before it can provide widespread security without explicit
per-recipient configuration at every sending site.

ESMTP STARTTLS has its place - it works OK for message submission - but I
think we need something different for TLS to MXs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHWESTERLY VEERING NORTHEASTERLY, 5 TO 7, VEERING
SOUTHWESTERLY IN FAR SOUTH LATER. ROUGH OR VERY ROUGH. RAIN OR SQUALLY
SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Nov 2008 09:09:02 +1100

In message <[email-masked]>, Tony F
> majority of them are not. This problem is perhaps even harder to fix than

	Just use DNSSEC and CERT records to do that.

	If self signed, look in the DNS for the CERT.  Accept if
	signed and validated by DNSSEC.  Have a low TTL on the CERT
	so as to not blow the DNS cache (caches can enforce this
	if needed) and maintain a on disk cache of the certs retrieved
	via the DNS as they have their own validitiy period.  Attempt
	to retieve a new one via DNS of the on disk one doesn't
	match.

	Certs that are signed by private CAs are harder to deal
	with as you don't have the linkage from the name to the
	CA.

	Mark

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Nov 2008 08:13:38 +0200 (EET)

On Fri, 14 Nov 2008, Mark Andrews wrote:
> In message 
> <[email-masked]>, Tony F 
> inch writes:
>> You also need the server to provide a verifiable TLS certificate. 
>> The vast majority of them are not. This problem is perhaps even 
>> harder to fix than the lack of DNSSEC.
>
...>
> 	signed and validated by DNSSEC.

How does an application do "accept if signed and validated by DNSSEC"?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Nov 2008 18:13:16 +1100

> How does an application do "accept if signed and validated by DNSSEC"?

	You validate the CERT RRset using the techniques in RFC
	4033, 4034 and 4035.  If the answer is "secure" then it was
	signed and validated.  You the match offered cert to the CERT
	RRs using the information from RFC 4398.

	Do you need more detail or is that enough guidance?

	Mark

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Nov 2008 09:35:53 +0200 (EET)

> 	Do you need more detail or is that enough guidance?

I was interested in more detail, specifically, are there application 
interfaces an application could use, or every app need to implement 
validation using 4033-5 techniques (a lot of work, and most would 
probably do it wrong)?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Nov 2008 18:42:19 +1100

> validation using 4033-5 techniques (a lot of work, and most would 

	There are a number of libraries available which can do
	dnssec validation.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Nov 2008 18:56:27 +1100

> 	There are a number of libraries available which can do

	And if you want to off load the validation you can used
	AD + TSIG.