Re: IP-based reputation services vs. DNSBL (long)

[TS Glassey <[e-mail]>]

Keith Moore wrote:
> Tony Finch wrote:
>   
>> On Sun, 9 Nov 2008, Keith Moore wrote:
>>     
>>> It is worth repeating that just because the notion of a reputation
>>> service has value, and such services are widely used, does not imply
>>> that using IP addresses as identifiers or the DNS protocol as a means of
>>> transmitting reputation are technically sound.  There is reason to doubt
>>> both of these assumptions, and there is no evidence that these design
>>> questions have been given due consideration and resolved - as our
>>> process would normally require.
>>>       
>> Could you give us a reference to an explanation of why the DNS might not
>> be a sound choice of protocol for reputation services?
>>     
>
> My concerns are along the following lines:
>
> 1. suitability of the DNS data and query model.  right now this protocol
> essentially communicates one bit of information to be used in a decision
> - i.e. whether the address or domain name is good or bad.  I suspect
> that more information is needed to really make a good reputation
> service.  I have doubts about whether DNS lends itself to including that
> much information.  (It also bugs me that multiple queries are required
> to  get the information necessary to perform a bounce/relay decision and
> to bounce a message... granted that this is a flaw in the DNS protocol
> design but using DNS for unintended purposes exacerbates the problem)
>   
I agree - these Identity Protocols need to be stronger meaning that 
UDP/IP transports are by their very capability, not the right animal IMHO.
> 2. this is a very different use case than DNS was intended to address,
> and implicit and explicit assumptions in the DNS design might not hold
> for this case.  e.g. assumptions about how long information remains
> valid and how widely it should be replicated.
>   
Agreed. And again - the design of UDP based DNS is unacceptable for this.
> 3. security.  it might be that mechanisms already defined or used with
> DNS (DNSSEC, source port randomization) are adequate, but I'd like to
> see more analysis done.
>   
For moving DNS resolutions possibly but NO credible security expert has 
been willing to sign off on the trust-model that DNSSEC uses...
> 4. effects of DNS caching.  if a host is removed from a blacklist it
> should arguably be removed from all caches instantly, but DNS isn't
> designed to facilitate that.  

The use of the term "SHOULD" here has legal implications - since many of 
these hosts were put into the BL's by Address Spoofing they were in fact 
NOT where the offensive SPAM was coming from and so placing those hosts 
there when the real issue is the refusal of the EMAIL Admin to do proper 
Header Filtration and Validation creates a direct liability.

I assure you RBL.ORG doesnt have enough money to pay a lawyer for a 
damage claim against it for its actions in 'putting in place a method 
and process specifically to prevent the addresses misrepresented in 
fraudulent headers, to the RBL.

> again, blacklisting someone else's IP
> address is a different use case from managing the addresses associated
> with your own hosts.  

YEP!
> If you manage your own hosts' DNS RRs then you can
>  tailor your operations to accommodate changes in DNS records, and you
> can (at least in theory) adjust your TTLs in advance of any changes to
> minimize the potential for disruption when you do need to change things.
>
> 5. slippery slope.  DNS is a vital service, and one that is very
> difficult to replace.  It needs to remain focused on a narrow goal.  The
> more we overload DNS, the more we threaten to add complexity that will
> make it more fragile.
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM
>
>   
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf