Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

Chris Lewis wrote:
> Keith Moore wrote:
>> I think you're missing the point.
> 
> Oh, no, I fully understand the point.  In contrast, I think you're
> relying on false dichotomies.
> 
> For example:
> 
>> Better "interoperation" of a facility that degrades the reliability of
>> email, by encouraging an increased reliance on dubious filtering
>> criteria and rumors, is not a desirable goal.
> 
> There is no such thing as a filtering mechanism that is 100% accurate,
> and hence all are dubious to one degree or another. 

Fine.  So please explain to me why, and under what conditions, using IP
addresses as a basis for filtering is reliable.

And please also explain why, and under what conditions, using DNS as a
means of communicating whether a particular IP address is spamming is a
good way to do that.  In particular, please explain how it encourages or
discourages selection of good criteria for filtering, how it enhances or
 degrades accountability for the party blacklisting the site (and/or the
party trusting the blacklist).  Explain the limitations of DNS for doing
this kind of rumor mongering and how they are addressed.  Explain the
mechanism for reporting blacklisting errors to the parties most affected
(which would include not only the senders of inappropriately filtered
messages but the intended recipients of inappropriately filtered
messages) and how use of DNS enhances or degrades those parties'
abililty to improve their email reliability.  Explain how DNS enhances
or degrades a party's ability to correct both a blacklist's mislabeling
of a site and a user's ability to correct his MSP's inappropriate use of
a blacklist.  Explain how the DNS ttl should be chosen and how it should
vary on a per-domain basis.  Explain the security risks associated with
trusting DNS as a blacklist query protocol, and in particular what
potentials exist for denial-of-service attacks and what can be done
about them.

See, it really appears that the design work that we would rationally
expect out of any standards-track protocol has not been done in this
case.  It appears that large-scale use of IP addresses as identifiers
for potential spammers is not well-considered, especially in an era with
widespread use of NAT.  It also appears that use of DNS as a query
protocol is not well considered beyond the fact that such a query could
be implemented by a sendmail rewrite rule.

In other words, this is a hack that has gotten way out of hand.  And not
a particularly well-designed hack at that.

> A demonstrable assertion that "IP x is demonstrably infected with
> Srizbi and anything it emits is probably crap" and communicated by
> DNS is much less dubious than "this combination of random content
> fragments makes it look like a Nigerian 419, sorta, marginally".

I'd probably agree with that statement on its face, but (a) comparing
DNSBL to SA like schemes is damning DNSBL with faint praise.  To my
knowledge nobody has requested that IETF standardize SA, but just
because SA sucks doesn't mean that DNSBL is standards-track quality even
if it sucks a bit less.  (b) DNSBL, in practice, doesn't actually
provide anywhere near that level of assurance.  It doesn't say that a
host is infected with Srizbi, it just alleges that a host is bad.   And
in fact the alleged badness might well have been "this host sent out a
combination of random content fragments that look like a Nigerian 419".
 Indeed, DNSBL doesn't actually say that a host is bad, it associates
the badness with an IP address which might or might not be associated
with the same host now as it was when the badness was observed.  It
doesn't say when traffic from that IP address was observed to be bad.  etc.

> Indeed, experience shows that a correctly chosen set of DNSBLs is often
> not only more effective than other techniques in correctly identifying
> malicious email, can often have far fewer false positives than just
> about any other mechanism.

In other words, if you make the selection the filtering criteria someone
else's problem, you can pretend that the problem has gone away - even if
that "someone else" is not responsible to either sender or recipient,
and that "someone else" is not accountable for misrepresentation.

That certainly doesn't sound like something that would pass muster for
standards track.  Maybe the security folks would like to comment on the
sanity of extending trust to unaccountable third parties?

> It certainly is counterintuitive that "source reputation" might be more
> accurate than "per email evaluation".  But, experience in the field
> demonstrates the true reality - the current state of the art is that
> intelligently chosen DNSBLs (the aforementioned BCP is intended to help
> that) often work much better than complete reliance on the latter.

I can accept that it makes some sense to identify compromised hosts, for
instance, and that blocking mail from hosts known to be compromised with
a spamming virus can in some cases be more reliable than blocking
content based on actual message content.

But there are still several problems: (1) the problem of "intelligently
choosing" DNSBLs (since many mail admins - even those working for large
ISPs - don't seem to be able to choose very well).  (2) the problem of
extending trust to a party not accountable to either sender or
recipient.  (3) the problem of trusting IP addresses as host
identifiers.  (4) various problems associated with using DNS as a query
protocol for this - including caching, ttls, spoofing, lack of ability
to carry all of the information needed for a reasonable decision to be
made, etc.

> Furthermore, incorrect DNSBL listings are easier to cope with than, say,
> random combinations of SpamAssassin scores that just happen to zap a
> desirable email.

Marginally easier, yes, because some DNSBLs include TXT records, and
some ISPs return NDNs with those TXT records.  And if the sender is
lucky, his ISP might not drop the NDN.   And so there's at least some
chance that the sender can figure out why his mail was bounced - or ask
someone to do so.  But this has nothing to do with use of a DNSBL per se
- it's equivalent to saying that SpamAssassin, as usually configured,
doesn't bounce mail.

And when I've been asked to track down why a blacklist rejected a
client's mail, the criteria for blacklisting the host have been bogus in
every single case.  For instance I recently found out that a client's
mail had been bounced because the server that sent out the mail didn't
have a PTR record pointing to a DNS name with the letters "mail" or "mx"
in it... and some idiot decided that this would be a good reason to
bounce perfectly legitimate mail.

Obviously there's a problem with "intelligently choosing" blacklists -
maybe mail system administrators are not, overall, very intelligent?
Maybe a system that expects mail system administrators to be able to
evaluate good blacklist criteria is not well-designed?

> I generate several DNSBLs for use here only.  Why shouldn't there be a
> standard so that mail server software I buy/lease/license will
> interoperate with DNSBLs I create?

Having a standard for reputation servers might be a good idea.  Basing
that reputation on IP address might not be a good idea.  Using DNS to
transmit that reputation might not be a good idea either.

> "Not well-established"?  You don't seem to have any idea how prevalent
> the use of DNSBLs is. 

I most assuredly do - because I'm constantly trying to figure out why
people's mail has bounced and running into the damn things.

But I think you misread what wrote earlier.  I didn't say that DNSBLs
weren't well-established.   I said the benefit of reputation servers was
not well-established.

> The reality is: almost everybody uses DNSBLs, and ALL of the very big
> sites do.

Sounds like "almost everybody" needs a clue.  No surprise there.

Or maybe what the industry needs are well-vetted mechanisms for
establishing a host or network's reputation, and well-engineered
mechanisms for reporting them, ensuring repeatability, reporting the
problems to people who can get them fixed, making the reputation
services accountable for their actions and so forth.    Not blessing of
a poorly designed hack.

>> use of DNS to communicate
>> such reputation, and basing such reputation on IP addresses, is itself
>> very dubious.
> 
> You may think it dubious, but it is usually more reliable and effective
> than any other, and its popularity alone means it needs to be standardized.

Nope.  Go read 2026.  Carefully.  The protocol has to be technically
sound (it's not) and it has to have rough consensus of the whole IETF
community (it doesn't).

> Rejecting the standardization of DNSBL protocols because the entries of
> a specific DNSBL _might_ be dubious is in itself a dubious position.

It strikes me that part of the problem with evaluating the quality of
reputation services used to bounce mail is that legitimate users rarely
see when they work well.  They mostly see when they don't work well,
when their mail is filtered for bogus reasons.

>> The problem isn't just the rumor passing mechanism, but
>> the mechanism is indeed part of the problem.
>>
>> It's not as if we're arguing about whether to standardize a facility
>> that is widely believed to work well.
> 
> It is widely believed to work well.  That's part of the point.

It's only believed to work well among mail system administrators who are
isolated from their users.   I've never met an end user who thought
DNSBLs worked well.  I've never met a MSA who worked directly with end
users who thought DNSBLs worked well.

>> We're arguing about whether to
>> standardize a facility that causes problems for everyone.
> 
> No more so than filtering in general.

Perhaps not, but that doesn't mean it's worthy of standardization.

>> Back when I started working with email, getting a message reliably
>> delivered was something of a black art, because you had to know how to
>> thread your message through the hodgepodge of Internet, uucp, BITNET,
>> DECnet, fidonet, and whatnot.  That was in some sense understandable
>> because Internet access was not widely available, and there wasn't
>> really any common network that everybody could tap into.
>>
>> Today, getting a message reliably delivered is once again a black art.
>> But today, it's not for lack of standards or network connectivity.  It's
>> because so many messages are filtered for dubious reasons, or on the
>> basis of what are essentially unsubstantiated rumors, or because of
>> over-reliance on IP source addresses as identifiers.
> 
> DNSBLs exist and their use is extremely widespread because the industry
> _does_ believe in them. 

The industry might believe in them.  But users don't believe in the
reliability of email, because their experience is that email is not
reliable.  And DNSBLs (and mail filtering in general) are the primary
reasons for that.

> We have to get our heads out of the sand and put it on a solid standards
> footing to finish the job of de-black-arting it.

The first step is to stop assuming a priori that DNS is a suitable
protocol for communicating reputation, and that IP addresses are
suitable as host identifiers.

Keith
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf