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

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 7 Nov 2008 12:17:44 +0100

On Tue, Nov 04, 2008 at 10:59:46AM -0800,
 The IESG <[email-masked]> wrote 
 a message of 26 lines which said:

> - 'DNS Blacklists and Whitelists '
>    <draft-irtf-asrg-dnsbl-07.txt> as a Proposed Standard

Well, it is certainly very important that the DNSxL are documented,
given their widespread use. And the I-D is a good document.

On the other hand, I have a few questions: the first one, why
"Proposed standard"? Is it really a good idea to standardize these
lists (most being badly managed)? Why not just "Informational" if we
just want to document what people are doing?

Second question, the document indeed standardizes many things which
are not in common use but does not point towards a rationale, so some
choices are puzzling. Why TXT records to point to an URL and not
NAPTR? Is this because of current usage in DNSxL? If so, this should
be noted. But why IPv6 lists use a A record and not a AAAA? I am not
aware of existing IPv6 lists so this cannot be the current usage?

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

---

From: John Levine <[email-masked]>
Date: 7 Nov 2008 14:18:21 -0000

Hi.  All of these questions have come up before on the various lists
where this draft was developed, but I suppose it's worth going through
them again.

>just want to document what people are doing?

The decscription of IPv4 DNSBLs/DNSWLs and most of the description of
domain DNSBLs document existing practice.  There aren't any v6 DNSBLs
yet, other than for testing, but there certainly will be, and my hope
here is to preemptively nail down the bits that are arbitrary choices,
e.g., the test addresses, so that software that uses v6 DNSBLs will
continue to interoperate, and DNSBL users continue to be able to
select the most effective lists by changing lines in a config file
rather than reprogramming.  Hence proposed standard.

>NAPTR?

That's what nearly all DNSBLs do now.  As the draft says in section
2.1, the contents of the TXT are useful to put into a 5xx SMTP
rejection message or the report from a scoring spam filter.

> Is this because of current usage in DNSxL? If so, this should be
> noted. But why IPv6 lists use a A record and not a AAAA?

Because the value isn't an address, it's a 32 bit value typically
interpreted as bitfields, which happens to be most easily transmitted
in an A record.  I've rewritten that part of the doc a few times
trying to make that clear, but I'd be happy to accept language which
makes it clearer.

Incidentally, although it may still be the conventional wisdom in the
IETF that DNSBLs don't work and aren't useful, in the outside world
where 95% or more of mail is spam, they're essential tools to run a
mail server.  Although there are indeed lots of stupid DNSBLs, those
aren't the ones that people use, and there are widely used ones that
have vanishingly low false positive rates that let you knock out most
of the spam cheaply so you can afford to do more expensive filtering
on what's left.  Spamhaus estimates, based on the systems that pay for
their data feeds, that there are about 1.4 billion mailboxes whose
mail is filtered using their lists, and they're the biggest but hardly
the only popular high quality DNSBL.  It's pretty clear that there are
a lot more mail systems that do use DNSBLs than don't.

R's,
John

PS: I noticed a buglet -- in section 5 it says that the apex of a DNSxL
zone may have an A record that points to a web server that contains
explanatory material.  It should of course say A and/or AAAA record.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 7 Nov 2008 15:52:57 +0100

On Fri, Nov 07, 2008 at 02:18:21PM -0000,
 John Levine <[email-masked]> wrote 
 a message of 55 lines which said:

> All of these questions have come up before on the various lists

That's the point of an IETF-Wide Last Call. I'm not a participant in
the ASRG.

> interpreted as bitfields, which happens to be most easily
> transmitted in an A record.  I've rewritten that part of the doc a
> few times trying to make that clear, but I'd be happy to accept
> language which makes it clearer.

After "Each entry in the DNSxL MUST have an A record.", add "The A
record MUST NOT be interpreted as an IPv4 address. It is an opaque
value, whose presence simply means that the name or address queried is
actually listed in the DNSxL."
 
> IETF that DNSBLs don't work and aren't useful, 

No, it's just experience. The last funny case is inside France Telecom
(French largest ISP) where one mail server refused another one because
it was blacklisted :-)
    
< orange.net #4.0.0 X-SMTP-Server; delivery temporarily suspended: host
relais-ias89.francetelecom.com[193.251.215.89] refused to talk to me: 450    4.7.1
Service temporarily unavailable; Client host [193.252.22.118] blocked    using Trend
Micro Network Reputation Service. Please see
http://www.mail-abuse.com/cgi-bin/lookup?ip_address=193.252.22.118; Mail    from
193.252.22.118 deferred using Trend Micro Email Reputation database.    Please see
<http://www.mail-abuse.com/cgi-bin/lookup?193.252.22.118>>

> It should of course say A and/or AAAA record.

Or use RFC 5321 vocabulary and write "address record".
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John L <[email-masked]>
Date: Fri, 7 Nov 2008 15:19:55 +0000 (GMT)

> actually listed in the DNSxL."

Seems reasonable.

> (French largest ISP) where one mail server refused another one because

Orange/Wanadoo/FT has a dreadful spam problem, so bad that I've locally 
had blacklist about half of their outbound mail servers.  If the point of 
the blacklist entry in question was to keep spam out of recipients' 
mailboxes, it was probably doing what it was supposed to.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 07 Nov 2008 07:57:18 -0800

> That's the point of an IETF-Wide Last Call. I'm not a participant in

Stephane,

Your view of the role of IETF Last Call does not match my reading of RFC 2418, 
"IETF Working Group Guidelines and Procedure":

    Last-Call is intended as a brief, final check with the
    Internet community, to make sure that no important concerns have been
    missed or misunderstood. The Last-Call should not serve as a more
    general, in-depth review.

You seem to be calling for an in-depth review.

Last Call gives the community a chance to actively put forward concerns, not to 
passively wait and require a detailed exposition by the working group. You note 
that you were not a participant. Yet that is exactly how someone who is 
concerned about the detailed history is supposed to obtain information about the 
detailed process (and affect its outcome.)

Sometimes, specification do contain rationales.  This is one of the things that 
distinguishes IETF specifications from most other standards groups.  But there 
is no requirement for this in IETF documents.  They are specifications, not 
tutorials.

> (French largest ISP) where one mail server refused another one because

That's a problem with administration and operation, not with specification of 
the format.

d/
-- 

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Nov 2008 12:10:43 -0500

>>>>> "Dave" == Dave CROCKER <[email-masked]> writes:

    Dave> Stephane Bortzmeyer wrote:
    >> On Fri, Nov 07, 2008 at 02:18:21PM -0000, John Levine
    >> <[email-masked]> wrote
    >>> All of these questions have come up before on the various
    >>> lists where this draft was developed, but I suppose it's worth
    >>> going through
    >>  That's the point of an IETF-Wide Last Call. I'm not a
    >> participant in the ASRG.

    Dave> Stephane,

    Dave> Your view of the role of IETF Last Call does not match my
    Dave> reading of RFC 2418, "IETF Working Group Guidelines and
    Dave> Procedure":

It seems quite clear to me that RFC 2418 does not apply at all to the
output of an RG.  From a process and consensus building standpoint,
this last call needs to be treated the same as an individual
submission, not WG output.  RGs are not required to maintain the level
of openness, minutes, etc that WGs do.  Thus, they don't get the
presumption of consensus that a WG does and the comments in 2418 about
last calls do not apply.  Even if a particular RG is open, it's still
not a WG; just as we would expect input from an external organization
to be treated through the individual process regardless of the
openness of that organization, we should do the same for IRTF output.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 07 Nov 2008 09:38:48 -0800

Sam Hartman wrote:
> output of an RG. 

Sam,

I've looked around and the WG Guidelines doc happens to be the only place I 
could find that defines the purpose of a Last Call. The mere fact that the title 
of document is about "working" groups doesn't obviously limit the scope of that 
definition.

Please explain.  Perhaps there is documentation for the individual and RG 
avenues that I missed?

  From a process and consensus building standpoint,
> to be treated through the individual process regardless of the

As John said, there was quite a bit of history to this work. All of it entirely 
open.

So I suspect this boils down to a question of whether there is a concern about 
actual history or formality of history, and whether you are suggesting that a 
Last Call for RG or Ind. Sub. carries an affirmative obligation for the 
submitters to provide a detailed review of the decision-making history for their 
work?

Again:

      If someone sees a specific problem, presents it and explains why they 
think it is a problem, then having the submitters respond with details about the 
specific history of the relevant decision(s) makes complete sense.  This, to me, 
is the essence of what a Last Call should deal with, no matter the source of the 
document.

      If, on the other hand, Last Call is an open invitation for an unbounded 
series of "why did you make this decision?" challenges, I'll ask you to explain 
how this is a community benefit, absent a broad consensus of concern, rather 
than its primarily serving to make the IETF approval process arbitrarily 
indeterminate.

      We have the real and concrete submission of a specification that documents 
existing practice and, so far, a solid demonstration of support for it.

      So what is the purpose of encouraging individuals to lodge open-ended 
challenges?

d/

-- 

   Dave Crocker

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 7 Nov 2008 13:52:30 -0500

> Incidentally, although it may still be the conventional 
> wisdom in the IETF that DNSBLs don't work and aren't useful, 
> in the outside world where 95% or more of mail is spam, 
> they're essential tools to run a mail server.  Although there 
> are indeed lots of stupid DNSBLs, those aren't the ones that 
> people use, and there are widely used ones that have 
> vanishingly low false positive rates that let you knock out 
> most of the spam cheaply so you can afford to do more 
> expensive filtering on what's left.  Spamhaus estimates, 
> based on the systems that pay for their data feeds, that 
> there are about 1.4 billion mailboxes whose mail is filtered 
> using their lists, and they're the biggest but hardly the 
> only popular high quality DNSBL.  It's pretty clear that 
> there are a lot more mail systems that do use DNSBLs than don't.

As an operator of a large mail domain, I'd like to reiterate John's
comments above.  DNSBLs work, are very cost (and computationally)
effective, and are in widespread use.

Regards
Jason

---

From: Doug Otis <[email-masked]>
Date: Fri, 7 Nov 2008 11:59:30 -0800

On Nov 7, 2008, at 3:17 AM, Stephane Bortzmeyer wrote:

> The IESG <[email-masked]> wrote a message of 26 lines which  
> said:
>

Agreed.

> are not in common use but does not point towards a rationale, so  
> some choices are puzzling. Why TXT records to point to an URL and  
> not NAPTR? Is this because of current usage in DNSxL? If so, this  
> should be noted. But why IPv6 lists use a A record and not a AAAA? I  
> am not aware of existing IPv6 lists so this cannot be the current  
> usage?

In putting together planning for IPv6 block-lists, one soon confronts  
the enormity of its potential data-set and the incredible complexity  
related to carrier grade NATs, tunneling protocols, and third-party  
translation services.  :^(

On the other hand, the DKIM signature "domain" and an accurate "on- 
behalf-of" value as a tuple offers a safer and simpler basis for  
acceptance with perhaps only a two order increase in the data-set.  In  
today's budget cutting and tight schedules, even establishing a DKIM  
list is not easy where ADSP needs to be modified before this can  
happen. :^(

Perhaps years from now, part of the overhead for sourcing from IPv6  
will be to include DKIM signatures with accurate "on-behalf-of"  
values.  The "on-behalf-of" values should be opaque in most cases.     
Today it would seem email wants to pretend to authenticate, rather  
than indicate what is actually authenticated, even when using opaque  
values. :^(

It is seldom that a person's email-address represents the source of  
abuse. Instead, it is often the result of compromised systems  
somewhere in the message stream.

-Doug

---

From: Pete Resnick <[email-masked]>
Date: Fri, 7 Nov 2008 14:03:30 -0600

On 11/7/08 at 9:38 AM -0800, Dave CROCKER wrote:

>Sam Hartman wrote:
>>It seems quite clear to me that RFC 2418 does not apply at all to 
>>the output of an RG.
>
>I've looked around and the WG Guidelines doc happens to be the only 
>place I could find that defines the purpose of a Last Call. The mere 
>fact that the title of document is about "working" groups doesn't 
>obviously limit the scope of that definition.
>
>Please explain.  Perhaps there is documentation for the individual 
>and RG avenues that I missed?

http://tools.ietf.org/rfc/rfc4844.txt
http://tools.ietf.org/id/draft-irtf-rfcs-03.txt

We have (IMO) historically screwed up with regard to IRTF and 
individual documents and not given them a proper stream to the RFC 
Editor. The above documents are dealing with that problem.

However, for this particular case, I'm with Sam: An IRTF document 
that is going into the *IETF* standards track is pretty much akin to 
an any other organizations documents going into the IETF standards 
track. It may be the case that the IETF and IRTF have a lot more 
sharing of resources and visibility, than say the IETF and ITU or 
IEEE, and therefore the hand-off should be quite a bit easier. 
However, there is no doubt that this is *different* than a WG handing 
off a document to the IESG for standards track approval. A WG has 
(ostensibly) been subject to the direct observation of an AD all 
along and therefore the IESG should have a pretty full understanding 
of the IETF-wide consensus that has built up around any document 
coming out of that WG by the time the Last Call comes around. That's 
not going to be the case for an IRTF (or individual or other external 
organization) document.

Yes, this is a less-than-efficient use of IETF Last Call. But if you 
want to make efficient use of the process for an *IETF* standards 
track document, work on it in the IETF.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Nov 2008 15:14:01 -0500

>>>>> "Pete" == Pete Resnick <[email-masked]> writes:

    Pete> http://tools.ietf.org/rfc/rfc4844.txt
    Pete> http://tools.ietf.org/id/draft-irtf-rfcs-03.txt

    Pete> We have (IMO) historically screwed up with regard to IRTF
    Pete> and individual documents and not given them a proper stream
    Pete> to the RFC Editor. The above documents are dealing with that
    Pete> problem.

As far as I can tell we're in agreement.  Implicit in my comment was
that this document was being published through the IETF stream.  (I'll
leave as an excersise for the pedants what happens if the IRTF tries
to publish an informational document for the IETF stream.)

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 07 Nov 2008 16:39:07 -0500

+1

If it's going to be an IETF Standard, it has to have IETF consensus.

This seems consistent with the way individual (i.e., non-WG) submissions 
are handled through the IESG.

Leslie.

Pete Resnick wrote:
>> Please explain.  Perhaps there is documentation for the individual and 
>> RG avenues that I missed?
> 
> We have (IMO) historically screwed up with regard to IRTF and individual 
> documents and not given them a proper stream to the RFC Editor. The 
> above documents are dealing with that problem.
> 
> However, for this particular case, I'm with Sam: An IRTF document that 
> is going into the *IETF* standards track is pretty much akin to an any 
> other organizations documents going into the IETF standards track. It 
> may be the case that the IETF and IRTF have a lot more sharing of 
> resources and visibility, than say the IETF and ITU or IEEE, and 
> therefore the hand-off should be quite a bit easier. However, there is 
> no doubt that this is *different* than a WG handing off a document to 
> the IESG for standards track approval. A WG has (ostensibly) been 
> subject to the direct observation of an AD all along and therefore the 
> IESG should have a pretty full understanding of the IETF-wide consensus 
> that has built up around any document coming out of that WG by the time 
> the Last Call comes around. That's not going to be the case for an IRTF 
> (or individual or other external organization) document.
> 
> want to make efficient use of the process for an *IETF* standards track 
> document, work on it in the IETF.
> 
> pr

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Nov 2008 18:28:39 -0500

Under no circumstances should any kind of Blacklists or Whitelists be
accepted by IETF as standards-track documents.  These lists are
responsible for huge numbers of illegitimate delivery failures.  We
should no more be standardizing such lists than to be standardizing spam.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Nov 2008 18:38:41 -0500

DNSBLs work to degrade the interoperability of email, to make its
delivery less reliable and system less accountable for failures.  They
do NOT meet the "no known technical omissions" criterion required of
standards-track documents.

The fact that they are widely used is sad, not a justification for
standardization.

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Nov 2008 06:46:54 -0500

Sadly, I have to agree with Keith.   While these lists are a
fact of life today, and I would favor an informational document
or document that simply describes how they work and the issues
they raise, standardizing them and formally recommending their
use is not desirable at least without some major changes in our
email model and standards for what gets addresses onto --and,
more important, off of-- those lists.

    john

--On Friday, 07 November, 2008 18:38 -0500 Keith Moore
<[email-masked]> wrote:

> DNSBLs work to degrade the interoperability of email, to make
> its delivery less reliable and system less accountable for
> failures.  They do NOT meet the "no known technical omissions"
> criterion required of standards-track documents.
> 
> The fact that they are widely used is sad, not a justification
> for standardization.

---

From: [email-masked]
Date: Sat, 08 Nov 2008 06:57:21 -0800 (PST)

> more important, off of-- those lists.

Such a criticism might be a sensible response to a document that defines an
actual whitelisting or blacklisting service. But that's not what this document
does. Rather, this document defines vaarious formats for storing such
information in the DNS and procedures for querying that data. Specification of
actual services based on these formats and procedures is left for later
specifications.

Standardizing these formats and procedures is important for at least two
reasons: (1) Without a specification nailing down these details there can be
(and in practice have been) interoperability problems between various
implementations and (2) Without something describing how to structure and
operate these systems they can, independent of the actual list content, create
serious operational problems.

Now, I am of course aware of the line of reasoning that says we should not
publish specifications for things that can potentially be abused. I'm sorry,
but if we take a candid look at how this strategy has played out with other
technologies ranging from MIME downgrading to NAT to Bonjour, I think the
record is fairly clear: We're much better off specifying things while calling
out the dangers of their use than we are when we all run off out our respective
corners and pout about the sad state of the world.

Assuming that the document does in fact define sensible formats that can be
operated at Internet scale (I think it does but am willing to be shown
otherwise by those with more expertise in large-scale DNS operations than I
have) and does not preclude operating a reliable and accountable service
(again, I think it does but I am willing to be proved wrong with specific
examples), I support publication of this specification. 

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 08 Nov 2008 07:53:55 -0800

> more important, off of-- those lists.

John,

What are the technical deficiencies of this specification?

What are the specific problems the mechanism it defines pose to "our email model 
and standards"?

What are the specific, "major changes" that would be required to the model and 
standards, to make the current specification acceptable?

This type of mechanism has massive adoption throughput the Internet.  It's 
perceived efficacy also is massive.  The current specification merely seeks to 
provide a stable technical basis for that mechanism.

In the face of overwhelming community consensus for this mechanism, you offer a 
simple, flat, fundamental rejection, yet provide no substantiation.

Really, John, it would help for a posting to do more than say that you don't 
like the idea of the mechanism.

d/
-- 

   Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 08 Nov 2008 08:46:49 -0800

At Sat, 08 Nov 2008 06:46:54 -0500,
> more important, off of-- those lists.

Speaking as someone who just got burned by exactly such a list,
I think I need to agree with John: I don't object to the IETF
publishing an informational document on this, but a PS implies
that IETF endorses the practice, which I don't think we should do.
I appreciate that there is a fine distinction here, but it seems
to me that it's precisely for cases like this where the distinction
is appropriate.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 11:39:48 -0500

> serious operational problems.

I could almost buy this argument.  The reasons I don't buy it in this
case are:

(1) using the IP source address as an indicator of any kind of identity
has been dubious for a long time (even in an enterprise network, but
especially in the Internet at large), and it is only going to get more
dubious in an era of IPv4/IPv6 transition where IPv4 addresses are
shared between different entities.

(2) use of DNS to communicate this information is a stretch at best.
the protocol is too constrained, and not designed for a use case like
this where the information that needs to be conveyed is very short-lived
in nature.

(3) the security considerations associated with such use, including
considerations for denial-of-service attack, are quite difficult to address.

so I think there's a compelling case to be made that any kind of DNSBL
is a poor design not worthy of standardization.

> corners and pout about the sad state of the world.

I don't think the examples you cite demonstrate that.  Standardizing
NATs in the 1990s would not have helped because the widespread
assumptions at that time were that you couldn't really change NAT
behavior and that the NATs had to operate "transparently" to the
applications.  Even today we still don't know how to make a NAT that
works well, without making the endpoints aware of the NAT, and giving
them explicit control over bindings.

As for Bonjour, I at least did try to call out dangers of the use of
IPv4 linklocal addresses, and with overloading DNS names and APIs, and
the WG repeatedly, stubbornly denied that those dangers existed.... and
continued to do so until IESG pushed back on at least some of those points.

But of course the question is not whether something like this can be
abused - anything can be abused.  The question is whether something like
this encourages abuse, or if not deliberate abuse, whether it encourages
 degraded reliability of the email system.  And I think there's a fair
amount of empirical evidence that it does.

That doesn't mean that we shouldn't try to design a better system for
identifying and reporting sources of spam or viruses.  But to me it
seems entirely plausible that relying on DNS to transmit this
information is part of the reason that DNSBLs are so often associated
with abuse and denial-of-service attack.  If we were designing such a
system from scratch we'd naturally be concerned about things like
accountability, repeatability, polling intervals, and identifying the
precise criteria used to blacklist an address.  We'd probably want to
expose more information to the client about why a site was blacklisted,
when it was blacklisted, and so forth, so that the client wouldn't be
bouncing mail without a good reason.  But trying to shoehorn this kind
of service into DNS forces most of these considerations to be overlooked
simply because there's not a good way to communicate them in DNS.

Really what this document is trying to do is to standardize a crude hack
- as well as being a blatant attempt at an end-run around our concensus
processes.  Publishing it as informational, with appropriate caveats
about the inherent limitations of the approach (including security
considerations) could be beneficial.  But I can't see how the protocol
described could ever be acceptable for the standards track.

And I really think the characterization of "pout[ing] about the sad
state of the world" is unhelpful.  What we really need to be doing is
figuring out how to retrofit or redesign the mail architecture to allow
senders to be more accountable (with appropriate granularity), and to
shift the cost of vetting mail to the senders.  Trying to make tired,
crude, poorly designed hacks work doesn't get us any closer to a viable
solution to the spam problem.

Keith

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 08 Nov 2008 08:53:36 -0800

> that IETF endorses the practice, which I don't think we should do.

Eric,

Roughly 95% of all mail is spam.  That makes email a pretty onerous "practice".

So we ought to remove standards status for all email specifications.

Or we could consider keeping mechanism and policy separate, standardizing 
technologies (mechanisms) and refraining from condemning them because some 
operators have misguided policies and use the mechanisms badly.

Really, guys, everything we standardize has examples of misuse.  So that hardly 
makes your current line of argument substantive.

Are you actually saying that there is something inherently inappropriate in 
having published reputation lists and that a technical standards body like the 
IETF is tasked with rejecting standardization of otherwise-acceptable technical 
specifications because we don't like how some people will use them?

Are you seriously lobbying for the IETF to be an idealistic island that ignores 
rough consensus and very well-established practice among the broader Internet 
community?

d/
-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 11:59:05 -0500

Dave,

you're mischaracterizing the situation and you ought to know better.

basing reputation on IP address is pretty dubious.
transmitting reputation over DNS is not "otherwise-acceptable"

and there's at least some argument to be made that this choice of
mechanism lends itself to abuse, or even encourages it.

and it appears that there's considerably less than rough consensus in
favor of DNSBLs ... especially if you ask people whose mail has been
blocked because of them.

Keith

> Or we could consider keeping mechanism and policy separate,
> standardizing technologies (mechanisms) and refraining from condemning
> them because some operators have misguided policies and use the
> mechanisms badly.
> 
> Really, guys, everything we standardize has examples of misuse.  So that
> hardly makes your current line of argument substantive.
> 
> Are you actually saying that there is something inherently inappropriate
> in having published reputation lists and that a technical standards body
> like the IETF is tasked with rejecting standardization of
> otherwise-acceptable technical specifications because we don't like how
> some people will use them?
> 
> Are you seriously lobbying for the IETF to be an idealistic island that
> ignores rough consensus and very well-established practice among the
> broader Internet community?
> 
> d/

---

From: John Levine <[email-masked]>
Date: 8 Nov 2008 17:05:00 -0000

> standardizing them and formally recommending their use

I'm not aware of any language in the current draft that recommends
that people use DNSBLs.  What it does say is that if you use or
publish DNSBLs, here's how they work so you can, you know,
interoperate and all that.  As I'm sure everyone is aware, there are
large numbers of independently written implementations, both
publishers and users of DNSBLs, so they seem ripe to me for
standardization.

> standards for what gets addresses onto --and, more important, off
> of-- those lists.

Some other people are working on a separate document codifying best
practices based on the experience of both people who run widely used
highly accurate DNSBLs and operators of large mail systems that use
them.  It should come along in the next month or so and might be BCP
or Informational.

But I have to say I am concerned that it will be picked to death by
people whose opinions of DNSBLs haven't been reexamined since they
were formed based on anecdotes in the late 1990s.  If you want to
start picking now, feel free to do so on the ASRG list.  For links see
http://wiki.asrg.sp.am

R's,
John

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 8 Nov 2008 12:27:15 -0500

On 8 Nov 2008 17:05:00 -0000
John Levine <[email-masked]> wrote:

> interoperate and all that. 

I hear you -- but http://xkcd.com/463/ comes to mind.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 12:31:52 -0500

John Levine wrote:
> that people use DNSBLs. 

Standardizing it is an implicit recommendation.  In particular it's a
statement that there are "no known technical omissions" about the
protocol.  Which is not an accurate description of the protocol at hand.

 What it does say is that if you use or
> publishers and users of DNSBLs, so they seem ripe to me for

So there's a clear justification for an Informational document
describing current practice - and also what's wrong with it.
Widespread deployment is not a justification for standardization.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 08 Nov 2008 09:35:01 -0800

At Sat, 08 Nov 2008 08:53:36 -0800,
> So we ought to remove standards status for all email specifications.

I don't think this follows from my comment.

> operators have misguided policies and use the mechanisms badly.

This sounds like a false choice to me.

> makes your current line of argument substantive.

You're certainly welcome to have that opinion, but I don't think that's
what I'm saying. For the reasons Keith is suggesting, among others,
I don't think this is a very good mechanism and therefore the IETF
shouldn't endorse it. As I said, I don't have a problem with this
document being advanced as Informational, but PS is different.

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Nov 2008 12:42:12 -0500

--On Saturday, 08 November, 2008 07:53 -0800 Dave CROCKER
<[email-masked]> wrote:

>> fact of life today, and I would favor an informational
>> document or document that simply describes how they work and
>> the issues they raise, standardizing them and formally
>> recommending their use is not desirable at least without some
>> major changes in our email model and standards for what gets
>> addresses onto --and, more important, off of-- those lists.
> 
> 
> John,
> 

Dave, Sorry if my note was incomplete.  I've halfway around the
world, trying to focus on something else and thought that the
issue Keith raised were clear enough that they didn't require an
in-depth explanation.  Ekr's comment reinforces that view.
However...

Our email model assumes that messages that are sent either get
delivered or that the sender gets an NDN back.  We have never
had a culture of receipts for delivery to what SMTP thinks of as
the last-hop MTA, much less delivery to the user's mailbox.
Today, messages can just disappear on the way to the user's
mailbox (often at or after that last-hop MTA).  They do so
without NDNs out of fear of blowback, and they do so for two
main reasons.  One has to do with analysis of message content
for patterns consistent with spam, the other has to with various
address and domain blacklisting techniques.  The problem with
the latter is that it is extremely subject to abuse, both
intentional and unintentional.  One variation on the former has
involved a DoS attack against a particular domain by used that
domain in faked addresses in spam.   That problem is worsened by
operational difficulties in getting off the lists once one has
been classified onto them, a problem exacerbated by "guilty
until proven innocent using standards of proof that are unclear"
that is built into the operational systems.

In theory, we could address this problem by writing a Security
Considerations section that includes "deployment and use of this
mechanism, even by others, undermines the assumption that mail
will either be delivered or NDNs produced and delivered to you
and neither you nor the final recipient will necessarily have
control over the mechanisms and decisions in use".  But that
raises issues that are quite similar to the "decision-making
middlebox not controlled from either endpoint" issue as well as
opening up the issue of whether we need to change the mail model
to be more strongly based  on delivery confirmations.   FWIW,
Security / Operational Considerations like that have been
considered more than adequate to block standardizion... and are
"known technical defects" relative to successful interoperation
with existing and established protocols and models.

> What are the specific problems the mechanism it defines pose
> to "our email model and standards"?

See above.

> What are the specific, "major changes" that would be required
> to the model and standards, to make the current specification
> acceptable?

Again, see above.

> This type of mechanism has massive adoption throughput the
> Internet.  It's perceived efficacy also is massive.  The
> current specification merely seeks to provide a stable
> technical basis for that mechanism.

Another part of the traditional mail model is that any
legitimate actor ought to be able to run his or her own mail
server.  I suspect, based on what is now a fairly large,
although opportunistic, sample, that a very large fraction of
those who are running a mail server on less than a T1/E1 link,
in PD space, and with mail system volume several orders of
magnitude smaller than that of AOL/ Gmail/ Hotmail/ Yahoo have
been burned at least once or twice by these mailing lists.
That implies that these methods are reducing the reliability and
predictability of the email system, which is exactly what Keith
said and, again, is a reason to not standardize.

> In the face of overwhelming community consensus for this
> mechanism, you offer a simple, flat, fundamental rejection,
> yet provide no substantiation.

Unlike you, I don't see "overwhelming community consensus for
this mechanism".   There is probably consensus among those for
whom mail system reliability in terms of delivery of legitimate
messages is less important than deleting spam, and especially
among those whose mail operations are large enough that they
will never find themselves blacklisted (although I vaguely
remember an incident in which some outgoing Gmail addresses
ended up on a blacklist).  But there is no consensus at all
among those of us who see this sort of technique as
operationally dangerous and problematic... so much so as to call
its value into question.

> Really, John, it would help for a posting to do more than say
> that you don't like the idea of the mechanism.

I don't think that characterization of what I (or Keith) said is
fair.  I also don't think that the discussion is moved forward
by either hyperbolic claims about consensus or attacking the
messenger.  You may disagree, of course.

     john

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Nov 2008 12:54:19 -0500

--On Saturday, 08 November, 2008 12:31 -0500 Keith Moore
<[email-masked]> wrote:

>> I'm not aware of any language in the current draft that
>> recommends that people use DNSBLs. 
> 
> Standardizing it is an implicit recommendation.  In particular
> it's a statement that there are "no known technical omissions"
> about the protocol.  Which is not an accurate description of
> the protocol at hand.

I'm am beginning to wish for the days at which, at least in
principle, we could standardize something and immediately put a
"not recommended" label on it.   I agree with John and Dave that
having an agreed-upon specification for how to do these things
if one insists on doing them would be a good idea.   I'm just
concerned about the implication of encouragement to do it, at
least without much stronger Security and Operational
considerations material than is now present (and, Dave, that
isn't a vague "don't like it" complaint -- it is a reference to
my earlier note, Keith's notes, ekr's notes, etc.).

    john

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 13:27:23 -0500

John C Klensin wrote:

> "not recommended" label on it.  

Well, I have often wished we had a clear label (or maybe even a separate
document series) for things of the form "if you're going to implement
this dubious idea, please do it this way because it appears to be less
harmful than other ways."  But we don't have one of those yet.

---

From: John Levine <[email-masked]>
Date: 8 Nov 2008 18:45:43 -0000

>Today, messages can just disappear on the way to the user's mailbox
>(often at or after that last-hop MTA).  They do so without NDNs out
>of fear of blowback, and they do so for two main reasons. ...

You know, DNSBLs make mystery disappearances less likely, not more.

The DNSBLs that most people use are typically checked at SMTP time, sp
MTAs can give a 5xx rejection using the TXT record from the DNSBL that
identifies why the mail was rejected.  Even if the DNSBL isn't in the
rejection message, there aren't that many lists that are widely enough
used to matter, and since DNSBL listings (unlike the private
per-system blacklists that are the most likely alternative) are by
their nature public, it is easy enough to check a bunch of them and
see if you're on one of them, thereby identifying the problem.  The
other approach is to use them in a scoring filter, but they'll do what
they do whether or not they mix DNSBLs into the score.

>this mechanism".

Aw, come on.  There's a billion and a half mailboxes using the
Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist
Linux boxes.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 14:50:13 -0500

> Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist

and there's a billion and a half users whose email is being degraded by
such mechanisms.

if you ask them whether they want to not receive spam, they'll say yes.
 if you ask them whether they want their incoming mail filtered on the
basis of unsubstantiated rumor and unreliable identifiers, they'll say no.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Nov 2008 12:16:10 -0800

Sometimes, people say "this shouldn't even be an Informational RFC because people can't tell the difference between the types of RFCs and they'll think the IETF supports the technology".

Sometimes, people say "this shouldn't be a standards-track RFC but it is OK for it to be an Informational RFC because people notice the difference and think the difference is important".

Sometimes, those are the same people talking about different documents.

The IETF has repeatedly tried and failed to fix the "RFC levels" problem. It is absurd to have the debate repeatedly and try to hold documents to one temporary belief or the other. Unless we fix the RFC levels problem, we can only rely on the content of the document itself.

To my reading, this document does not promote the use of blacklists, much less of crappy blacklists (of which I am an erroneous target). The text seems to be all about bits-on-the-wire interoperability that affects large and small ISPs.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Nov 2008 16:42:13 -0500

> basis of unsubstantiated rumor and unreliable identifiers, they'll say no.

Then you go to the next logical step, and turn Spamhaus off, and you ask
them whether they want it back on.  They'll say yes.  They did here (the
question was an accidental goof on my part that turned off Spamhaus
queries, the answer (trouble tickets about spam filtering not working,
despite all the other filtering mechanisms unaffected by the goof) was
overwhelming)

Secondly, the term "unsubstantiated rumor" - that implies that Spamhaus
accepts unsubstantiated allegations from anyone.  They don't.

"Unsubstantiated rumor" - unsubstantiated by whom?  Represented how? I'd
contend that Spamhaus's listings are all substantiated by them, but no
matter.  PSBL, for example, substantiates every listing with a spam
sample via their web site.  CBL (Spamhaus XBL) entries are substantiated
by SMTP transactions from the IP in question, usually with specific
identification of the spambot that did it.  They may not reveal precise
details of their heuristics of how they detected it, nor a sample, but
experience indicates that they are right virtually 100% of the time.

I don't need 100% full transparency or 100% substantiation, if
experience shows I can trust it.

And I do.  Those that represent 1 1/2 billion mail accounts trust it too.

This is also that false dichotomy again: just because a DNSBL might
issue "unsubstantiated rumor" doesn't mean that they ALL necessarily do.

"Some A does B" != "All A does B".

Indeed, I would contend that to most people, the appearance of Miriam
Abacha (that will trigger some non-DNSBL-based filters) as being spam
sign is unsubstantiated rumor.  But that is the basis for other
filtering methods.  One might reply that the IETF should not standardize
the insides of those methods.  But who cares?  They don't need
consistent inter-machine protocols.  DNSBLs do.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Nov 2008 16:43:41 -0500

> identifies why the mail was rejected.

Indeed, and more concretely: NDNs aren't inherently bad (blowback).
It's "accept then generate NDN" that's inherently bad.  Anti-spam
techniques that are after the destination's MX should not generate NDNs,
because all of it is potentially blowback by definition.

The "just disappear" argument more applies to techniques that can't NDN
without blowback.  Which, includes, for example, ALL client-side
filtering no matter what filtering they use, and all server-based
"accept-then-analyse" filtering.  Not DNSBLs per-se.

By far the most common server-based implementations using DNSBLs reject
at SMTP time (usually with some sort of remediation information in the
error message), which suppresses almost all blowback, yet "you" still
find out what happened.   In contrast, for example, the most common
implementations of (say) content analysis do accept-then-analyse, and
should not NDN because it'll be blowback.

Full analysis during SMTP time of (say) content and rejecting at SMTP
time is considerably rarer (we're one of the rarer ones).   In part
because older revisions of the SMTP standards weren't very clear about
handling of rejections after DATA.  We decided to ignore that limitation.

In other words, in general you're far more likely to find out about your
email not getting through (and how to fix it) if it was a DNSBL hit than
most other techniques.  It's not intrinsically inherent to DNSBLs, it's
just the "overwhelming experience".

> Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist

All of the very largest email and spam filtering infrastructures use
DNSBLs (generally IP-based reputation lists) in one way or another,
whether they tell you or not.  I said "all" because I meant "all" -
that's not hyperbole for "most".

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 17:41:41 -0500

You keep citing 1.5 billion users.  I haven't asked all of them, of
course, but I keep finding that users don't trust their email to be
reliable, and they don't know how to find an email service that is
reliable.  Mostly they maintain several different email accounts and try
sending from multiple accounts in the hopes that one of those messages
will get there.  Those that haven't given up on email entirely, that is.

I really think that if you can design and standardize a protocol for
reporting reputation which includes a mechanism for making the
reputation service accountable to end users, and also is reasonably
secure, you might seriously improve email reliability.  I just don't
think that DNSBL is good enough for that and I doubt that DNS can be
stretched far enough to make that work well.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 18:21:17 -0500

Paul Hoffman wrote:

> The IETF has repeatedly tried and failed to fix the "RFC levels" problem.

Paul, our criteria for standards-track documents haven't changed in
several years.  Sure they're imperfect but that's not a justification
for abandoning them.  And this document doesn't meet them.

Keith

---

From: Theodore Tso <[email-masked]>
Date: Sat, 8 Nov 2008 18:33:06 -0500

> stretched far enough to make that work well.

Indeed; reputation system for the reputation servers!  Of course, if
DNSBL operaters were to find the that shoe was on the other foot, such
that their reputations were getting judged by the same criteria that
sites are declared "unclean" (i.e., by unauthenticated rumor), maybe
there would be more attention and care towards some secure,
accountable way for conclusions to be reached on some particular
host's reputations, whether it is running a SMTP server or a DNSBL,
and for a more secure, authenticated, and accountable way for that
reputation to be carried across the network.

					- Ted

---

From: John Levine <[email-masked]>
Date: 9 Nov 2008 00:07:24 -0000

>sites are declared "unclean" (i.e., by unauthenticated rumor), ...

Why do you assume that nobody looks at the quality of DNSBLs?  See,
for example, http://stats.dnsbl.com/

And what does this have to do with the technical details of running
and using one?  We all know that spam stinks and DNSBLs stink, too.
Unfortunately, the alternatives to DNSBLs are worse.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Sat, 8 Nov 2008 16:46:21 -0800

> Unfortunately, the alternatives to DNSBLs are worse.

This whole discussion is confusing.

I thought the role of the IETF was to define standards that facilitate  
interoperability implementations of protocols, not make value  
judgements about operational decisions made by folks who use those  
protocols.

Is the goal here to force the folks who are interested in  
standardizing DNSBLs to do so in another venue?

Thanks,
-drc

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Nov 2008 19:46:52 -0500

--On Friday, 07 November, 2008 12:10 -0500 Sam Hartman
<[email-masked]> wrote:

> It seems quite clear to me that RFC 2418 does not apply at all
> to the output of an RG.  From a process and consensus building
> standpoint, this last call needs to be treated the same as an
> individual submission, not WG output.  RGs are not required to
> maintain the level of openness, minutes, etc that WGs do.
> Thus, they don't get the presumption of consensus that a WG
> does and the comments in 2418 about last calls do not apply.
> Even if a particular RG is open, it's still not a WG; just as
> we would expect input from an external organization to be
> treated through the individual process regardless of the

Because of exactly this reasoning, there was once a time that
the IAB and ISRG Chair insisted on keeping the ISRG/IETF
boundary clear by prohibiting RGs from producing standards-track
documents.  If something got close to the point at which
standardization was appropriate, either (1) the document had to
be handled as an individual submission, with, at most, an
acknowledgment to the RG or (2) the RG got shut down with advice
to go through the IETF's WG chartering process.   Unless my
memory is failing me, one of the people who is now advocating
giving the RG status comparable to WGs was strongly supportive
of that model.

Perhaps an RG might produce a standards-track document as an
accidental side-effect of its work and the community should be
relaxed about that under the principle of not putting rigid
rules ahead of good sense.   It still wouldn't rate treatment as
a WG for the reasons Sam cites.   But, if an RG starts regularly
producing candidate documents for standards track or BCPs (and I
note that this thread has led to a discussion of at least one
"companion document" for which BCP processing is expected to be
requested RSN), then it isn't doing research as its exclusive
focus any more: at least a non-trivial amount of its effort has
become protocol engineering and its close relatives.

Independent of what happens with this document, I urge the IRTF
Chair and the IAB to bring that situation under control.

    john

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Nov 2008 20:06:16 -0500

--On Saturday, 08 November, 2008 16:46 -0800 David Conrad
<[email-masked]> wrote:

> I thought the role of the IETF was to define standards that
> facilitate interoperability implementations of protocols, not
> make value judgements about operational decisions made by
> folks who use those protocols.
> 

David,

I would be much more sympathetic to the notion that this was
just about standardizing neutral formats to facilitate
interoperability among those who had decided to use these lists
if the Security Considerations section addressed a broader range
of the issues that have been raised in this thread.  It does
not, and that leads one to wonder whether that argument from
some of the participants is a little bit disingenuous.  

And, in theory, the IETF still has a system of recommendation
levels for standards-track documents on the books that is
orthogonal to maturity levels and that includes such categories
as "recommended", "not recommended", and something like
"mandatory".  While we haven't used those categories regularly
for years, the default remains, AFAIK, "recommended" ... that
that doesn't mean a neutral "we recommend that you use this data
format if you decide to do that thing".

In addition, although we were well into the thread before it
came up, if the ASRG is planning to ask for publication of a
"companion document" that specifies how to use this stuff, as a
BCP no less, the two documents should be treated in the same way
we would normally treat WG or conventional individual submission
documents that were that closely related and put into Last Call
together.

     john

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 8 Nov 2008 20:15:31 -0500

-----Original Message-----
From: [email-masked] on behalf of Keith Moore
Sent: Sat 11/8/2008 2:50 PM
To: John Levine
Cc: [email-masked]; [email-masked]
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

>basis of unsubstantiated rumor and unreliable identifiers, they'll say no.

Keith - I encourage you to consult with several very large scale email domains around the world to see if they think that DNSxBLs are useful, effective, and in widespread use or not.

Regards
Jason

---

From: Keith Moore <[email-masked]>
Date: Sun, 09 Nov 2008 00:53:58 -0500

> Keith - I encourage you to consult with several very large scale email domains around the world to see if they think that DNSxBLs are useful, effective, and in widespread use or not.

Jason - I encourage you to consult with users whose mail isn't getting
delivered, and see whether they think DNSBLs are useful and effective,
or whether their mail is effectively being bounced by third parties who
aren't accountable for their actions.

Keith

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 09 Nov 2008 01:52:42 -0500

> aren't accountable for their actions.

DNSBL operators can and do get sued for their actions.  Sometimes
rightfully so.

Further, accountability both for the block and its remediation, rests
mostly with the admin who deploys the filters, whether it be something
they've designed themselves, or choose to delegate to someone else
(whether it be DNSBL, Brightmail filter downloads or A-V signature
downloads etc).  Which in our case is _me_.  I don't get to blame others
for _my_ choices.

So, where's this accountability gap you keep talking about?

I found out what our users thought of DNSBLs when I accidentally turned
off DNSBL queries.  We were flooded with hundreds of complaints  about
the spam.  We get _far_ fewer complaints about false positives we have.

So the real result of your suggestion is clear.  You need to do what
Jason suggests.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sun, 09 Nov 2008 12:08:53 -0500

> So, where's this accountability gap you keep talking about?

The gap is where ISPs can drop my mail without a good reason, and
without my having any recourse against them.  The gap increases when
they delegate those decisions to a third party.   It increases further
when the mail is dropped without any notice to sender or recipient.

These incidents happen one at a time.  It's rarely worth suing over a
single dropped message, and yet the aggregate amount of harm done by IP
based reputation services is tremendous.

> the spam.  We get _far_ fewer complaints about false positives we have.

You're comparing apples to oranges here.  It's not surprising that
recipients complain about an increase in the amount of spam they
receive.  But they're not as likely to know about messages that they
never receive because of false positives, so of course they're less
likely to complain about them.  And the cost (to sender or recipient) of
a message blocked for bogus reasons can be far higher than the cost to
the recipient of a spam.   And the relative number of complaints is not
a reliable indicator of those costs.

---

From: Matthias Leisi <[email-masked]>
Date: Sun, 09 Nov 2008 18:41:31 +0100

[Disclosure: I am the leader of the dnswl.org project; I provided some
input into the DNSxL draft as far as it concerns whitelists.]

> based reputation services is tremendous.

I would not want to reduce the situation to blacklists only. You use the
correct term - IP based reputation services - but fail to mention that
this includes whitelists, and that decisions other than "drop" can be
made based upon data returned by such services.

Regarding the "dropped message": While outside the scope of the DNSxL
draft, it is pretty much consensus that messages should not be dropped
in the sense of deleted or "stored in a seldomly reviewed quarantine
folder", but that a clear SMTP 5xx error code should be returned.

DNSBLs in conjunction with SMTP 5xx error codes actually increase the
value of the overall email system by enhancing it's reliability.

> the recipient of a spam.   

I believe it is generally agreed that false positives are the main risk
with spam filter solutions. This applies both to individual tools like
DNSxLs and to the "filtering machine" as a whole as perceived by the
recipient (and the sender). No automated solution can guarantee the
absence of false positives.

On the other hand, the manual solution is far worse in terms of false
positives, in my experience - the human error rate is pretty high when
eg a spammy inbox must be reviewed manually.

It is true that many spam filter solutions are short on "ham rules"
which would offset erroneous (or bogus, as you chose to call it) "spam
rules". The reason is obvious: most ham rules would be trivially to
forge for a spammer -- something which is not practical with IP
addresses. That's why IP addresses are so important for spam filter
decisions, both for black- and for whitelisting.

> And the relative number of complaints is not

It's probably the best indicator available?

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 09 Nov 2008 13:34:19 -0500

> made based upon data returned by such services.

I suspect DNSWLs have problems also, but I haven't tried to analyze the
problems with DNSWLs to the extent I have the problems with DNSBLs.

> folder", but that a clear SMTP 5xx error code should be returned.

I don't think it should be outside the scope of a standard.

> eg a spammy inbox must be reviewed manually.

Agreed.  But it is not uniform for all recipients - it depends highly on
how much legitimate mail they receive, how much spam they receive, and
the similarity between the two.  And there's a important difference in
liability between a recipient filtering his own mail and an unrelated
third party filtering it for him.

> It's probably the best indicator available?

perhaps, but that doesn't make it a compelling argument.

Keith

---

From: <[email-masked]>
Date: Sun, 9 Nov 2008 22:21:57 -0000

> And what does this have to do with the technical details of 
> running and using one?  We all know that spam stinks and 
> DNSBLs stink, too.

That's a rather narrow view. Very large numbers of people
think that Instant Messaging is a far superior alternative
to DNSBLs, not to mention VoIP, web forums and other variations
on the theme. Fortunately, the IETF has done some good work
in the area of SIP and XMPP has steadily been gaining traction.

I think it is a positive thing to document the technology
of DNSBLs but I have no idea why this has come to the IETF.
Maybe it is a veiled test of the IETF's relevance to the 
21st century Internet.

--Michael Dillon

---

From: Tony Hansen <[email-masked]>
Date: Sun, 09 Nov 2008 23:40:43 -0500

I'm personally very interested in getting the format for querying DNS
*white* lists standardized. I want to be able to use DNSWLs as part of
*positive reputation* checking: given an *authenticated* domain name
(say, with DKIM), can we say something positive about them beyond "they
send email"?

The protocol described in this draft covers both cases, both positive
and negative checking.

While the majority of the examples in the document concentrates on
negative examples, the protocol *is* useful for the positive case.

Does anyone have issues with the use of this protocol for WHITE lists?

	Tony Hansen
	[email-masked]

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 9 Nov 2008 23:51:16 -0500

On Sun, 09 Nov 2008 23:40:43 -0500
Tony Hansen <[email-masked]> wrote:

> (say, with DKIM), can we say something positive about them beyond
> "they send email"?
> 
In some sense, I have more trouble with white lists than black lists.  

My concern is centralization of power.  If used properly, white lists
are fine.  If used improperly, they're a way to form an email cartel,
forcing organizations to buy email transit from a member of the inner
circle.

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 10 Nov 2008 00:59:33 -0500

> forcing organizations to buy email transit from a member of the inner

Hi Steven, long time...

Sort of a protection racket.

This only works insofar as the mail receivers (the ones who choose to
deploy a whitelist) is willing to let them.  Receivers are driven, first
and foremost, by their users's complaint rates.

Receivers will notice increased complaint rates from a whitelist like
this, and begin to discount their input.  As they also do with FP rates
on the blacklists they use.  We see that now in take-up rates of various
DNSBL/DNSWLs.

Much as, say, people realized that TrustE logos didn't mean very much.

There's a much larger potential with proprietary reputation systems -
the buy-in costs are high, so it eventually becomes impossible for new
reputation vendors to get into the act, and receivers are reluctant to
switch vendors because they have to put yet another proprietary thingie
in their MTAs.

[A few years ago, at a MAAWG session, I caused a bit of slack-jawed
consternation when I strongly put forth the idea that reputation vendors
had to move to open protocols if they wanted acceptance at more than a
few of the very largest ISPs that could afford it.  I'm glad to report
that at least one or two have since seen the light.]

In an standard protocol environment, startup costs are minimal,
receivers find it very easy to switch or mix-and-match.

Same goes with negative reputation.

A standardized open protocol greatly reduces the likelyhood of cartelish
behaviour.

---

From: Matthias Leisi <[email-masked]>
Date: Mon, 10 Nov 2008 07:05:52 +0100

> forcing organizations to buy email transit from a member of the inner

That is fundamentally true, and is the very reason dnswl.org is _not_
built around a business model, but as an all-volunteer organisation.

The "value" of such an organisation is the trust given by the users of
the whitelist data. Abuse of this trust would very fast be sanctioned by
not using the data any more.

However, this is independent from the technical specification of the
protocol, which I think is valuable. While this draft does not specify
the only protocol available to query our data, it is by far (in the high
90%-region) the most important one (either through queries to our public
servers or through local/private mirrors).

-- Matthias

---

From: John Levine <[email-masked]>
Date: 10 Nov 2008 13:02:55 -0000

> That's a rather narrow view. Very large numbers of people think that
> Instant Messaging is a far superior alternative to DNSBLs, not to
> mention VoIP, web forums and other variations on the theme.

I can certainly believe that there are people who think that, but if
those very large numbers of people aren't even aware that IM, VoIP,
and web forums also use DNSBLs and DNSWLs to manage their abuse
problems, it's hard to see how their impressions would be helpful
here.

> I think it is a positive thing to document the technology of DNSBLs
> but I have no idea why this has come to the IETF.

As I said a few messages up in this string, although the structure of
IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs aren't
that mature yet and one of my goals was to make them interoperate
equally well so, for example, if you find you're using cruddy ones you
can easily switch to better ones.

R's,
John

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 10 Nov 2008 09:19:12 -0500

> From: Keith Moore [mailto:[email-masked]] 
>
> > Keith - I encourage you to consult with several very large 
> scale email domains around the world to see if they think 
> that DNSxBLs are useful, effective, and in widespread use or not.
> 
> Jason - I encourage you to consult with users whose mail 
> isn't getting delivered, and see whether they think DNSBLs 
> are useful and effective, or whether their mail is 
> effectively being bounced by third parties who aren't 
> accountable for their actions.

The buck ultimately stops with any mail admin (or user of any particular
technology), not the DNSxLs and any other filtering tools they may
choose to employ.  As for consulting with users, you will find me (and
my team) posting (and reading of course) almost daily on the Comcast
section of BroadbandReports and our customer support forum's email
section (http://forums.comcast.net).  I could give you countless other
examples of how I am my team works with senders and customers, and works
to increase our transparency (such as http://postmaster.comcast.net). I
work hard to be in touch with customers, and consider it a centrally
important part of my job to understand how my team's use of technology
affects our customers and other users on the Internet.  Also, I am sure
you would not be surprised to know there is a correlation betewen spam
effectiveness and user satisfaction with email.  Yes, there are always
individual sender problems, but no matter the tool or technology you
always have exceptional use cases that must be worked through.

Regards
Jason

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Nov 2008 10:18:40 -0500

> can easily switch to better ones.

I suspect it will be very difficult to make IPv6 DNSxLs work anywhere
nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use
a different address for every SMTP conversation.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 10 Nov 2008 07:22:42 -0800

> forcing organizations to buy email transit from a member of the inner

Steve,

Email reputation lists have been around for a very long time.  The current 
specification codifies this existing practice.  So we have plenty of track 
record to test your concern.

Perhaps you know of some pattern that validates that concern, but I don't.

Such services have always been easy to set up and, indeed, there is a wide range 
of reputation services. (Positive reputation services are more recent so there 
is a smaller set to evaluate... so far.)

A standard reduces switching costs, so that consumers of reputation data are not 
locked in to their current reputation provider.

Hence, standardizing the details for obtaining reputation data -- postivie or 
negative -- ought to mitigate against centralization.

d/
-- 

   Dave Crocker

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Nov 2008 17:26:05 +0000

> Does anyone have issues with the use of this protocol for WHITE lists?

DNSWLs already exist and are used by e.g. SpamAssassin.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
TYNE DOGGER FISHER: SOUTHWEST 6 TO GALE 8, BACKING SOUTH 5 OR 6 IN FISHER.
ROUGH OR VERY ROUGH, OCCASIONALLY MODERATE LATER. SHOWERS. MODERATE OR GOOD.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Nov 2008 18:25:15 +0000

> a different address for every SMTP conversation.

I expect that attack will make /48 or /64 listings common. This has the
obvious downside of an increased risk of one infected host spoiling email
connectivity for its immediate neighbours, even more than is already the
case for IPv4 DNSBLs. Perhaps ISPs and hosting providers can mitigate that
by enforcing address allocation policies.

In any case, DNSBLs should scale roughly according to the size of the
routing table, not the size of the address space.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FISHER: SOUTHWEST 6 TO GALE 8 BACKING SOUTH 5 OR 6. VERY ROUGH BECOMING
MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Nov 2008 13:38:59 -0500

> by enforcing address allocation policies.

Or perhaps enterprise networks will be forced to outsource their mail
submission to third parties with supposedly "trustworthy" addresses.
Which IMHO would not be a desirable result.

> routing table, not the size of the address space.

What does it mean for a DNSBL to "scale"?

Keith

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Nov 2008 18:42:19 +0000

> What does it mean for a DNSBL to "scale"?

I was referring to the number of entries that have to be maintained.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: CYCLONIC BECOMING NORTHWEST 7 TO SEVERE GALE 9. VERY ROUGH OR
HIGH. SQUALLY SHOWERS. MODERATE OR POOR.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Nov 2008 13:47:18 -0500

> I was referring to the number of entries that have to be maintained.

okay.  I found myself wondering if the change in address space size, and
in granularity of assignment, might make DNSBLs less reliable.  Which is
a different kind of scalability.

Keith

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Nov 2008 19:04:27 +0000

> a different kind of scalability.

IPv6's bigger address space affects more security mechanisms than just
DNSBLs, such as defensive port scanning, traffic auditing, etc.

http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-implications-02.txt

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
WIGHT PORTLAND PLYMOUTH: SOUTHWEST VEERING WEST 6 TO GALE 8. ROUGH OR VERY
ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT
FIRST.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Nov 2008 12:37:33 +0000

> http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-implications-02.txt

Thanks Tony - that draft has now emerged as RFC5157:

http://www.ietf.org/rfc/rfc5157.txt

The granularity of the address space that might appear in a blacklist is
an interesting question.   I would guess that where today a single IPv4
address appears, a whole IPv6 /64 would be required, at least, since a
client on a IPv6 link could in principle use any of the 2^64 available
host addresses.    But it may be worse, if whole /48's are assigned to 
DSL users for example (although there seems to be pushback to /56 for SOHO
type networks).    The question then is whether the single IPv6 address
or link it is on is blacklisted, or whether the blacklist includes the
'default' site prefix size.

On a related tack, I've been gathering stats on our recorded IPv6 transport 
mail volumes and identified spam since Dublin, and will analyse these soon 
and pop out a draft with appropriate observations.    We've seen a fairly
consistent figure of 50% of our IPv6 transport connections being classified
as spam by our MailScanner system since Dublin.

Tim

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Nov 2008 21:59:28 -0500

Dear colleagues,

We have read draft-irtf-asrg-dnsbl-07.  We have some comments on the
draft in response to the last call.  We wish to emphasise that, while we
currently serve as the co-chairs of the DNS Extensions working group,
these comments are merely our own, and are not representative of the
views of the working group.

We believe we understand the purpose of DNSxLs, and we think they can, in
some circumstances, provide a useful service (even though they
sometimes cause difficulty for users of Internet mail).  We also think
that describing current behaviour of DNSxLs is a good thing.  

That said, we are uncomfortable with the draft in its current form,
and are strongly opposed to adopting it as a Proposed Standard.  We
believe that most, but not all, of the draft would be an excellent
candidate for adoption as an Informational document.

One problem with the document is its outline of the way that DNSxLs
use A records to indicate reasons to accept or reject traffic from a
given site.  The trouble is that these A records are not host
addresses, even though that's the definition of an A record.  The A
records merely _look_ like host addresses.  In order to understand
that they are not host addresses, you have to know what DNS server you
are querying and interpret the owner name at the record.

What this really does is use the context of the query, plus the
content of the query and answer, as meta-data in order to add new
semantics to A records: if you happen to query server
dnsbl.example.org with just the right owner name, you get an A record
that is not a host address.  Note that merely knowing the DNS server
name is not enough: the document points out that if you query the same
server with a different owner name, you might get an A record that
_is_ a host address.  In addition, the context of the answer
determines its use: the same server can use the same zone data to
provide whitelist and blacklist services to two different groups of
querying agents.

Now, it is surely a service to the Internet community to document that
there are DNS servers where the content of the answer determines the
semantics of the record, but we don't really think this is something
that we should plan to advance on the standards track.  It seems plain
to us that the reason DNS has RRTYPEs is so that the client doesn't
need to guess what kind of record it has when it gets a resource
record.

In our view, the document really needs to make clear that DNSxLs are
violating the semantics of A records when they make this use of them.
One way to do that would be to modify the first paragraph in section
2 along the following lines:

   A DNSxL is a zone in the DNS[RFC1034][RFC1035].  The zone containing
   resource records identifies hosts present in a blacklist or
   whitelist.  Hosts were originally encoded into DNSxL zones using a
   transformation of their IP addresses, but now host names are
   sometimes encoded as well.  Most DNSxLs still use IP addresses.
   The zone accepts and responds to DNS queries in apparently standard
   ways.  The zone data, however, is not DNS data, and has special
   semantics that can be understood only in the context of the DNSxL
   service.  In particular, A records returned by the server usually
   do not contain a host address.  Instead, they usually contain a 32 bit
   value to be interpreted as bitfields.  For historical reasons,
   implementations used the DNS A RRTYPE to represent these values,
   rather than a distinct RRTYPE.

   As noted in section 5, some A records in a DNSxL zone MAY contain
   host records.  How clients interpret different A records in the
   same DNSxL zone is implementation- and context-dependent.

In addition, the document proposes to continue using the existing
mechanism in order to support IPv6 hosts.  There is little evidence of
a widespread deployment of such use, and there is therefore still time
to come up with a better solution that does not overload the meaning
of RRTYPEs before we have widespread use of IPv6 mail
infrastructure.  Therefore, in our opinion, extending the current
practice to IPv6 hosts is not a good idea.  The current draft makes
the best of a bad principle, but it should recommend an alternative
approach as preferable.  

One simple solution would be to introduce one or, better, two new
RRTYPE(s) that work(s) exactly the same way as the A RRTYPE, so that
deployed software would need to be modified only to query for the new
RRTYPE instead of an A record.  We appreciate that a long, or maybe
indefinite, transition period would be needed.  Presumably, however,
the widespread introduction of IPv6 in the mail infrastructure of
organisations will occasion the installation of new software as well.

Best regards,

Olafur Gudmundsson 
[email-masked]

Andrew Sullivan
[email-masked]

---

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

On Tue, 11 Nov 2008, Andrew Sullivan wrote:
> a widespread deployment of such use,

Exim has had support for IPv6 DNS lists as described by this draft for
many years.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHEASTERLY 5 OR 6, VEERING SOUTHWESTERLY 4 OR 5 LATER.
MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR LATER.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2008 12:33:00 -0500

> Exim has had support for IPv6 DNS lists as described by this draft for

I fail completely to see how that is even a little bit evidence that
there is widespread deployment of IPv6 mail hosts, use of them, or
anything of the sort.  I gather our point wasn't clear enough, though,
so I'll try to make it clearer.

The point is that we do not have today a large installed base of
IPv6-native networks interoperating, with large-scale spam problems
that need urgent attention, in the way that we have those problems on
IPv4-hosted mail infrastructure.  I am aware that there is some IPv6
deployment, and I am aware that in those environments there are of
course mail servers.  But deployment is nowhere near the scale of the
deployed v4 architecture.  Therefore, we have an opportunity now,
before v6 is everywhere, to do something about the deployed code.
That isn't to say there will not need to be some
backward-compatibility efforts (which you may pronounce "kludges" if
your local policy permits).  I think we said that in our original
message, however.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

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

On Wed, 12 Nov 2008, Andrew Sullivan wrote:
> anything of the sort.

Sorry, I thought you were referring to deployment of the DNSxL protocol
that the draft documents.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHEASTERLY VEERING SOUTHWESTERLY 4 OR 5, INCREASING 6 AT
TIMES, VEERING NORTHERLY 5 TO 7 LATER. MODERATE OR ROUGH. OCCASIONAL RAIN.
MODERATE OR GOOD, OCCASIONALLY POOR.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Doug Otis <[email-masked]>
Date: Thu, 13 Nov 2008 20:06:26 -0800

On Nov 10, 2008, at 7:18 AM, Keith Moore wrote:

> John Levine wrote:
>
>> As I said a few messages up in this string, although the structure  
>> of IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs  
>> aren't that mature yet and one of my goals was to make them  
>> interoperate equally well so, for example, if you find you're using  
>> cruddy ones you can easily switch to better ones.
>
> I suspect it will be very difficult to make IPv6 DNSxLs work  
> anywhere nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly  
> easy to use a different address for every SMTP conversation.

Agreed.   One might hope that the future will use DKIM domains and "on- 
behalf-of" tuples as an alternative to that of an IP address blocking  
list.  Ideally, the "on-behalf-of" would be an opaque value assigned  
by the provider, that is changed whenever a problem is corrected.   
This would eliminate the need for coordination between those that run  
reputation services and the senders.  Those that abuse this freedom  
would be at risk of finding their entire domain blocked instead.  The  
problem that needs solved is how to block compromised systems, more  
than blocking individuals.  Frankly, it would be best not to have any  
personably identifiable values used.

Unfortunately, being able to detect misbehavior at a sufficient level  
to safely conclude whether an outbound MTA is poorly managed requires  
rather extensive infrastructure. This infrastructure is often several  
times larger than the typical infrastructure of a client being  
protected.  These services address the problem of scaling email  
defenses.  Assessments are fairly difficult when the MTA being judged  
has little volume, since even an occasional misidentification of NDN  
as spam might create a profile fairly similar to those created by bot- 
nets.  Bot-nets represent a sizable portion of today's spam sources.

IMHO, the goal of the black-hole list should be to inform ISPs and  
have them remove bad actors from their network and hopefully to  
encourage them to better monitor their own traffic.  ISPs will not  
agree with this.  Even the largest decoy infrastructure sees only a  
tiny fraction of the overall traffic.  A desire to rapidly block any  
IP address that appears to be actively spamming provides bad actors a  
simple way to locate decoys and render the system less effective.   
While there are ways to deal with this problem, it both increases the  
infrastructure required, and the duration of a listing applied to  
problematic addresses.

While there may be some concern that DNSxLs use A records as a flag,  
normally these records are limited to an address range of  
127.255.255.255 - 127.0.0.2 (only  23 bits worth of data).  It seems  
unlikely that the use of these IP addresses will lead to any problem.   
The reason for suggesting that the document be published as  
Informational has to do with there not being _any_ real experience yet  
in attempting to block IPv6 addresses.  Routers will only be handling  
a faction of the total IP address space that IPv6 makes available.  
IPv6 DNSxL entries will not represent the same number of routes  
managed by routers.  This would suggest that entire networks are to be  
blocked whenever a significant level of abuse is detected that  
warrants blocking.  This would be a rather bunt tool.

There are a few points that this draft attempts to answer in a  
reasonable way.  The software used by the DNS servers is not going to  
change to support the IPv6 address space.  The servers will continue  
in the same fashion as before.  Instead of a query address of  
127.0.0.2, this draft suggest the value ::FFFF:7F00:2 to test the  
existence of the list.  Until there is some greater experience in  
handling IPv6 address space, do not get ahead of the problem by  
concluding how this service is to resolve the practical challenges  
ahead.  When a network handles a mixture of legitimate and abusive  
traffic, it may be impossible to cope with the volume of tracking data  
that will be required.

After all, evidence MUST BE retained for everything blocked to squelch  
erroneous customer complaints and the occasional law suit threat.   
While SANs are getting bigger, to scale these systems for tracking  
addresses within an IPv6 network is unlikely to be economically all  
that practical.  This might be wrong, but it should be less expensive  
for reputation services to use DKIM domains and an opaque "on-behalf- 
of" value instead.  DKIM would also create less danger with respect to  
collateral blocking.  MTAs may need to be equipped with crypto  
hardware to deal with foo signature abuse.  At least MTAs should be  
able to rate limit any IP address sending foo signatures.

-Doug

---

From: Florian Weimer <[email-masked]>
Date: Sat, 15 Nov 2008 00:54:16 +0100

> aware of existing IPv6 lists so this cannot be the current usage?

The lack of a macro capability also means that it's basically
impossible to secure DNSBL zones with DNSSEC when they contain larger
chunks of address space; see the example in section 2.1.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Mon, 17 Nov 2008 04:45:14 +1100

> chunks of address space; see the example in section 2.1.

	How so?

-- 
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: Florian Weimer <[email-masked]>
Date: Sun, 16 Nov 2008 20:28:35 +0100

>> chunks of address space; see the example in section 2.1.

The expectation is that error messages generated from TXT records
contain the actual IP addresses which triggered the DNSBL lookups.  As
a result, if you list a /16 (say), you need publish 65,536 different
TXT records.

Currently, these records are synthesized using a macro capability in
the DNS server.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 16 Nov 2008 16:34:04 -0500

> Currently, these records are synthesized using a macro capability in

How does that break DNSSEC?

A number of DNSBLs merely suggest an error message in their usage
instructions, and leave it up to the client to synthesize a combination
of the suggested error message and the IP address.  Macro expansion in
the client (either of supplied TXT or client-configured string) seems
common.

Of course, they're still only suggestions, and some DNSBL users will
generate their own.

The worst of all is the clients that don't tell you what the IP was and
no other way to remediate issues.  There are situations like this which
even leave admins scratching their heads.

[While the BCP isn't yet on the table w.r.t. the spec (it may be), this
issue is covered in the BCP.]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Florian Weimer <[email-masked]>
Date: Sun, 16 Nov 2008 22:34:42 +0100

* Mark Andrews:

> 	Which is independent of DNSSEC.  I ask again how this a
> 	DNSSEC problem.

I didn't say it was a DNSSEC problem.  I just wanted to note it's
impossible to secure some existing DNSBL zones using DNSSEC without
sacrificing some of the functionality which is mentioned in section
2.1 in the draft.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Levine <[email-masked]>
Date: 16 Nov 2008 21:46:27 -0000

>a result, if you list a /16 (say), you need publish 65,536 different

Some do, some don't.  In any event I agree that DNSSEC is not ideally
suited to signing DNSBLs, but I would think that with some judicious
partitioning into subzones the problem wouldn't be intractable.

R's,
John

---

From: Florian Weimer <[email-masked]>
Date: Sun, 16 Nov 2008 22:53:26 +0100

> How does that break DNSSEC?

You'd need online signature generation (which implies sharing the key
with all mirrors), or hundreds of millions of precomputed signatures
for some existing zones.  (Due to the prevalent attack scenario, more
frequent than usual key rollovers are needed, so this really hurts.)

> instructions, and leave it up to the client to synthesize a
> combination of the suggested error message and the IP address.
> Macro expansion in the client (either of supplied TXT or
> client-configured string) seems common.

I've been told that this approach would not be acceptable.  But my
source probably lacked your insight into the field.

With macro expansion in the client, signing and serving typical DNSBLs
is still somewhat of a challenge, but doable.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Florian Weimer <[email-masked]>
Date: Sun, 16 Nov 2008 22:59:55 +0100

* Mark Andrews:

> 	I still don't believe your claim.

I can't sign a thousand million RRsets and serve it in a DoS-resilient
manner, even with John's partitioning idea (which is rather neat,
thanks!).

Macro expansion in the client brings down the number of RRsets to a
challenging, but manageable level.  Chris says there's precedent for
that, so I think we can end this subthread (or move the discussion to
some place where the topic of DNSSEC scalability would be more
on-topic).
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 16 Nov 2008 20:34:10 -0500

> manner, even with John's partitioning idea (which is rather neat,

I may have to keep that in mind if I ever DNSSEC our internal composite
DNSBL zone, which has probably near 500M IPs listed (both "bad" and "good").

[The zone file is > 500Mbytes]

> some place where the topic of DNSSEC scalability would be more

Even more for a client-supplied string being macro-expanded in the
client.  Eg: no TXT query at all.

If I had to guess, I suspect that more than half of clients don't issue
a TXT query and synthesize their own error message instead.  The vast
majority of DNSBLs are arranged so that a single message with macro
substitution of IP is sufficient to produce a useful error message, so
why wait for a TXT query if you can configure the client to generate its
own?

Even tho I publish TXT records in our internal DNSBL zone, the filters
themselves don't query them.  The TXT records are used by administrative
tools as part of the FP process because they contain diagnostic
information on the entries.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Mon, 17 Nov 2008 08:44:57 +1100

Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 17 Nov 2008 07:13:10 +1100

Mark

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 17 Nov 2008 12:53:03 -0500

The DNSBL BCP document has been updated and submitted to the IETF
as http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-05.txt

This is not an official IETF last-call, and can't be officially
considered as being co-submitted with the last call of the DNSBL
protocol specification (draft-irtf-asrg-dnsbl), proposal as it should
have been arranged to be.

Taken for whatever it's worth, this is only minor typographical
revisions to the previous draft (04) that was deemed ready for last-call
at the ASRG session at IETF Dublin, discussed through many iterations
of the ASRG and elsewhere, and I think covers most if not
all of the "Security Considerations" type issues raised with
draft-irtf-asrg-dnsbl.

While the issues raised mostly aren't listed as "Security
Considerations" in the BCP, they comprise much of the base content of
the BCP.

I'm not exactly sure where this is all going, whether the IRTF or IETF,
etc., that will depend on the IETF ADs etc.

But I think it worth taking a look at for those interested in the
subject matter.  I guess further discussion should go to the ASRG
mailing list.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf