Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues)

From: SM <[email-masked]>
Date: Tue, 01 Nov 2011 00:51:15 -0700

At 19:39 31-10-2011, Chris Lewis wrote:
>While the wildcarded domain returning a non 127/8 address is a risk, 
>it seems to be mostly a theoretical one.  It's happened before, and 
>the consequences have been unnoticable on the whole.  It seems more 
>frequent that individual sites screw up their DNSBL query config to 
>the extent that it always returns what they think is a listing.  Eg: 
>misspelling the query zone, or miss-parsing received lines.

Frank mentioned "Listing the world".  This would entail returning a 
127/8 IPv4 address.  The consequences are noticeable assuming that 
unnoticeable is not defined as less than one percent of mail 
traffic.  BTW, there is a noticeable amount of "noise" that goes up 
to what some may qualify as part of the DNS infrastructure.  A "screw 
up" that leads to 2,000 qps shows up on the radar.

On an unrelated note, see 
http://www.ietf.org/mail-archive/web/ietf/current/msg67226.html  A 
second occurrence was reported on an IETF mailing list on October 2, 2011.

>All of the list-the-world instances we've heard about have been 
>_deliberate_, either by the original DNSBL operator, or by the new 
>owner of the domain, where they've arranged it to return the 
>specific 127.x.x.x address that indicates listing.

See http://www.merit.edu/mail.archives/nanog/msg02999.html to get a 
glimpse of the perceptions at the other end.

>As such, no matter how we defined a reputation service, this same 
>risk of "list the world" remains, and for much the same 
>reasons.   We could authenticate the results somehow, but that still 
>won't prevent a reputation provider deliberately going rogue.
>
>I don't think we can solve that problem in a protocol specification.

Quoting an except from Andrew's message:

   "you're not the stuckee when the protocol you're supposed to be
    maintaining grows all sorts of hairs and warts because of this
    behaviour on someone else's part.  I'd have thought, however, that the"

There are IETF WGs that do protocol maintenance.  The practice is to 
defer to such a WG when it comes to expertise about a protocol or 
else put up a fight.

Depending on how the discussion goes, "list the world" can end up 
being an issue that has to be covered.  The probability of that 
happening is higher if reputation service is equated with 
DNSBL.  BTW, the problem could be addressed in a protocol specification.

Regards,
-sm

---

From: Chris Lewis <[email-masked]>
Date: Tue, 01 Nov 2011 12:54:44 -0400

On 11-11-01 03:51 AM, SM wrote:
>> it seems to be mostly a theoretical one. It's happened before, and the
>> consequences have been unnoticable on the whole. It seems more
> Frank mentioned "Listing the world". This would entail returning a 127/8
> IPv4 address.

Correct.  But that was not the original point raised in this thread, nor 
what I was replying to - that of reclaimed domains wildcarding queries 
to a single addressible IP causing disruption.  _That_ aspect was what I 
was addressing.  I have yet to see it ever causing more than very 
limited/localized affects, and that only with implementations of DNSBL 
query that are not compliant with long-standing practise nor RFC5782.

In fact, I was agreeing with Frank.  "Expired domains" is not an issue 
of itself.  Deliberately causing it to return erroneous data is.  That 
risk is just as present with any other kind of reputation system, with 
consequences that can be just as dire.

> The consequences are noticeable assuming that unnoticeable
> is not defined as less than one percent of mail traffic. BTW, there is a
> noticeable amount of "noise" that goes up to what some may qualify as
> part of the DNS infrastructure. A "screw up" that leads to 2,000 qps
> shows up on the radar.

Those sorts of screwups that I've heard of to-date appear unrelated to 
DNSBLs.

The level of noise on port 25 that has nothing to do with actual email 
delivery attempts can be quite high too.  Occasionally crippling levels 
of bounceback, address verification probes (which very often yield the 
wrong answers anyway), TCP/IP pings, outright gibberish, mail loops etc.

>> owner of the domain, where they've arranged it to return the specific
>> 127.x.x.x address that indicates listing.
>

I'm not sure what that has to do with "list the world", and without 
wishing to start another rathole, I'll note that that's not a good 
example on a number of levels.

> Depending on how the discussion goes, "list the world" can end up being
> an issue that has to be covered. The probability of that happening is
> higher if reputation service is equated with DNSBL.

Can you explain how you come by that conclusion?

Or are you making the implicit assumption (by use of the term 
"equating") that we stop after "just doing/enshrining DNSBL-like things" 
(whatever "DNSBL-like" things are assumed to be).  I don't see that 
happening especially if you're implicitly assuming that DNSBL-like 
things can only be binary good/bad answers.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Nov 2011 11:48:27 -0700

On 11/1/11 9:54 AM, Chris Lewis wrote:
> >> While the wildcarded domain returning a non 127/8 address is a
> >> risk, it seems to be mostly a theoretical one. It's happened
> >> before, and the consequences have been unnoticable on the whole.
> >> It seems more frequent that individual sites screw up their DNSBL
> >> query config to the extent that it always returns what they think
> >> is a listing. Eg: misspelling the query zone, or miss-parsing
> >> received lines.
> > 127/8 IPv4 address.

The code returned depends on definitions imposed by the service.  
Generally speaking, _any_ answer typically blocks email acceptance.

>  Correct. But that was not the original point raised in this thread,
>  nor what I was replying to - that of reclaimed domains wildcarding
>  queries to a single addressible IP causing disruption. _That_ aspect
>  was what I was addressing. I have yet to see it ever causing more
>  than very limited/localized affects, and that only with
>  implementations of DNSBL query that are not compliant with
>  long-standing practise nor RFC5782.

This RFC should be viewed as offering just historical perspectives. The 
Internet is rapidly changing where the approach suggested by RFC5782 is 
no longer appropriate.

>  In fact, I was agreeing with Frank. "Expired domains" is not an
>  issue of itself. Deliberately causing it to return erroneous data
>  is. That risk is just as present with any other kind of reputation
>  system, with consequences that can be just as dire.

There are serious risks not yet addressed.  These should be covered 
since the REPUTE charter suggests tangential information can be used to 
establish reputations. i.e. neither SPF authorization nor DKIM 
signatures confirm actions of a domain.

1) shared resources are increasingly common

2) neither SPF nor DKIM authenticate the actions of an assessed entity

> > The consequences are noticeable assuming that unnoticeable is not
> > defined as less than one percent of mail traffic. BTW, there is a
> > noticeable amount of "noise" that goes up to what some may qualify
> > as part of the DNS infrastructure. A "screw up" that leads to 2,000
> > qps shows up on the radar.
>  Those sorts of screwups that I've heard of to-date appear unrelated
>  to DNSBLs.

With macro capabilities of SPF, it is nearly impossible to reach a 
conclusion of non-involvement.  SPF is currently a proposed basis for 
supporting REPUTE services. :^(

>  The level of noise on port 25 that has nothing to do with actual
>  email delivery attempts can be quite high too. Occasionally
>  crippling levels of bounceback, address verification probes (which
>  very often yield the wrong answers anyway), TCP/IP pings, outright
>  gibberish, mail loops etc.

Indeed, the vast majority of transactions on port 25 do not involve 
exchanges of wanted email.  Rather than creating potentially disruptive 
and sloppy assessments of millions of domain's actions, it is time to 
add a Kerberos extension to SMTP.  SMTP itself could take on the task of 
authentication, but using Kerberos seems safer.

An SMTP-Auth extension could be added to permit exchange of Kerberos 
tickets.  By leveraging the extremely low frequency transactions of 
Kerberos preceding SMTP transactions, the authentication would then 
permit address information to be forwarded to SMTP firewalls.  After 
all, IPv6 will soon be announcing a space about 400,000 times larger 
than the entire IPv4 address space.

> >> _deliberate_, either by the original DNSBL operator, or by the
> >> new owner of the domain, where they've arranged it to return the
> > See http://www.merit.edu/mail.archives/nanog/msg02999.html to get
> > a glimpse of the perceptions at the other end.

Disagree!  Currently, the ONLY weakly authenticated identity of an actor 
provided by email is the source IP address confirmed by TCP handshakes.  
Today's RBL block list strategies were developed as an alternative to 
effective BGP black-holing.  (The term Black-List leads to wasteful 
litigation clarifying why black-list laws are not applicable.)   The 
decision that authentication of an actor identified by domain is not a 
requirement for REPUTE is both troubling and is potentially highly 
disruptive!

> > happening is higher if reputation service is equated with DNSBL.
>
>  "equating") that we stop after "just doing/enshrining DNSBL-like
>  things" (whatever "DNSBL-like" things are assumed to be). I don't
>  see that happening especially if you're implicitly assuming that
>  DNSBL-like things can only be binary good/bad answers.

Attempting to report gradations of good/bad on what is currently 
becoming a DDoS in itself only increases the size of the problem.  Being 
sloppy can not be excused by saying published results represent 
aggregated statistics that are not expected to be accurate.  Rather than 
calling this the REPUTE WG perhaps it could be called the OOPS WG for 
"Out of Place Statistics". :^)

-Doug

---

From: SM <[email-masked]>
Date: Tue, 01 Nov 2011 12:02:41 -0700

At 09:54 01-11-2011, Chris Lewis wrote:
>DNSBL query that are not compliant with long-standing practise nor RFC5782.

The scope of the work has been picked to avoid some issues.  Arguing 
on the above is going to cause trouble.

>example on a number of levels.

I mentioned perceptions.

>Can you explain how you come by that conclusion?

See my comment about scope.

>DNSBL-like things can only be binary good/bad answers.

I currently have no position on DNSBLs.  If I am not mistaken, the 
work is about scoring (not binary answers) and providing some other data.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Nov 2011 16:37:33 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, October 26, 2011 6:44 AM
> To: [email-masked]
> Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues)
> 
> It would be interesting to do an evaluation of if it really is
> necessary.  At some level (and I know I'm generalizing here) both DKIM
> validation and SPF pass results output a domain that the domain owner
> have given some level of authorization to.
> 
> I don't think it's at all clear that this distinction makes enough
> difference to be worth the complexity associated with maintaining
> multiple types of identity.

In general I agree that it's unclear.  What I expect, though, is that there will be purists out there that claim one is better than the other for whatever reason, and want to ensure that their mail flow is based on one in particular.  The IDENTITY stuff provides a way to confirm that in the reply to the query.

I think this is something useful to include initially.  If it turns out to be unused because the result is mainly the same on both "sides", then we can drop it in a later version (say, when it advances to draft standard).

Having said that, I'll see if I can produce some reports from the accumulated OpenDKIM data that confirm (or are unable to confirm) a strong correlation.  Perhaps others here have databases they could tap to do the same.

-MSK