Re: [Asrg] Development of an object assessment format/protocol

"Emanuele Balla (aka Skull)" <skull@bofhland.org> Mon, 04 March 2013 16:59 UTC

Return-Path: <skull@bofhland.org>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB78521F8C2A for <asrg@ietfa.amsl.com>; Mon, 4 Mar 2013 08:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DafkCIiyVXEL for <asrg@ietfa.amsl.com>; Mon, 4 Mar 2013 08:59:56 -0800 (PST)
Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0921F8C20 for <asrg@irtf.org>; Mon, 4 Mar 2013 08:59:55 -0800 (PST)
Received: from enlil.local (baggins.skullkrusher.net [147.123.72.2]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id C6BFD6C376 for <asrg@irtf.org>; Mon, 4 Mar 2013 17:59:51 +0100 (CET)
Message-ID: <5134D304.5040702@bofhland.org>
Date: Mon, 04 Mar 2013 17:59:48 +0100
From: "Emanuele Balla (aka Skull)" <skull@bofhland.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20130304132924.GA27928@gsp.org> <0D79787962F6AE4B84B2CC41FC957D0B20C05A58@abn-exch1b.green.sophos>
In-Reply-To: <0D79787962F6AE4B84B2CC41FC957D0B20C05A58@abn-exch1b.green.sophos>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Development of an object assessment format/protocol
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2013 16:59:56 -0000

On 3/4/13 4:46 PM, Martijn Grooten wrote:
e protocol? Or is it a
> mere consequence of the fact that sources have different things they
> are willing and able to share?
> 
> I think the idea is nice. Whether such a format is really needed I'm
> not sure. I can see how having more information available makes for
> better decisions, but I am worried the accuracy gained isn't worth
> the performance lost.


As someone who's been thinking and experimenting on this for maybe the
last 3 or 4 years: yes (IMHO) the protocol would be useful.

IMHO (read this post like I had filled it with "IMHO" all over the
place), the reason why a similar protocol won't be a big performance
loss is that probably DNS cache in DNSBL-like lookups is not as useful
as most people would expect...

The problem why it's not been built so far is that those who are mostly
interested in such a protocol being available (data providers, as they
have data they could provide through it) rarely have the resources to
create something like that.

Partly because creating protocols is not their main job.

Partly because they would have to provide both server and client
implementation, otherwise nobody will be able to use their data.

Partly because - to be as smart as DNS- the client needs to be as
"complex" as DNS: redundacy, load-balancing, lowest-latency server
selection, etc.: all the logic has to go in the client, not in the
servers layout (like in "let's run anycast and forget about the
client"), for several reasons

Partly because, if the rest of the industry doesn't follow their lead,
the service will be unusable for most users and will simply never get
traction.

Partly because there're lots of issues about providing/looking_up data
with extreme granularity (privacy, exposure, etc), so these data
providers are not sure the service would be so useful, after all, and
they prefer to just provide the data in a raw format to those who are
smart enough to figure out on their own how to use them.


> Perhaps you can come up with examples of where such a protocol would
> be useful?

Straight to the point: abusive URLs on legit domains
. There's no (easy/effective) way to encode an entire URL in a DNS request.
At least, that's the reason why I've been thinking about this topic for
the last 4 years... :-\