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... :-\
- [Asrg] Development of an object assessment format… Rich Kulawiec
- Re: [Asrg] Development of an object assessment fo… Martijn Grooten
- Re: [Asrg] Development of an object assessment fo… Emanuele Balla (aka Skull)
- Re: [Asrg] Development of an object assessment fo… Dave Crocker
- Re: [Asrg] Development of an object assessment fo… Rich Kulawiec
- Re: [Asrg] Development of an object assessment fo… Martijn Grooten
- Re: [Asrg] Development of an object assessment fo… Paul Smith
- Re: [Asrg] Development of an object assessment fo… Barry Shein
- Re: [Asrg] Development of an object assessment fo… Emanuele Balla (aka Skull)
- Re: [Asrg] Development of an object assessment fo… John Levine