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
Ietf(_at_)ietf(_dot_)org
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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf