Re: uncooperative DNSBLs, was several messages

"Chris Lewis" <clewis@nortel.com> Thu, 13 November 2008 17:53 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994493A686C; Thu, 13 Nov 2008 09:53:46 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778743A686C for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 09:53:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.584
X-Spam-Level:
X-Spam-Status: No, score=-5.584 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCzSnI2JN9TW for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 09:53:43 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 615273A6358 for <ietf@ietf.org>; Thu, 13 Nov 2008 09:53:42 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mADHree26416 for <ietf@ietf.org>; Thu, 13 Nov 2008 17:53:40 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 12:53:40 -0500
Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 13 Nov 2008 12:53:39 -0500
Message-ID: <491C699B.4000702@nortel.com>
Date: Thu, 13 Nov 2008 12:53:31 -0500
From: Chris Lewis <clewis@nortel.com>
Organization: Nortel
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
CC: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: uncooperative DNSBLs, was several messages
References: <Pine.LNX.4.33.0811121942450.12067-100000@egate.xpasc.com> <20081113112302.38928.qmail@simone.iecc.com> <e0c581530811130740g1db5cbfehbcdad361660bf48b@mail.gmail.com> <491C5339.8090801@dcrocker.net> <20081113163833.GN76118@shinkuro.com>
In-Reply-To: <20081113163833.GN76118@shinkuro.com>
X-OriginalArrivalTime: 13 Nov 2008 17:53:40.0371 (UTC) FILETIME=[C2F20630:01C945B8]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Andrew Sullivan wrote:
> On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote:
>> The difficulty is that the current line of argument is that because some 
>> DNSBLs are operated badly, DNSBLs are bad.
> 
> I think that's not quite fair.  My impression is that there is more
> than one line of argument.  Here are some different ones that I have
> observed in this discussion, some of which seem never to be getting
> answers.  (Or, sometimes, they seem to be getting answers that are
> counter-arguments the the first.  I believe philosophers would call
> those examples of the straw person fallacy.)

> 1.  Some DNSBLs are bad, therefore all DNSBLs are bad.  (The one you
> note, and which is obviously bogus.)

Obviously.

> 2.  DNSBLs are in themselves bad, because there is no way to guarantee
> that they won't contain false positives; they are nevertheless
> possibly useful, but the trade-offs are inadequeately described in the
> current document.

If all that's missing is a few sentences in the Security Considerations
section, I'm sure that we can get somewhere with that, on the other
hand, discussion of those types of tradeoffs probably don't belong in
this draft, but a BCP.

> 3.  DNSBLs are not in themselves bad, but the implementation of them
> as described in the current draft (which does describe the current
> state of the art in DNSBLs) _is_ bad.  The current behaviour and the
> desirable behaviour ought to be separated, and one described while the
> other is standardized.

Behaviour of DNSBL != information transfer protocol.  The document at
hand only describes the protocol, and should only describe the protocol,
and the security considerations should be on the protocol, not the
behaviour.  "Behaviour" is better described in another document.  Like
the BCP I'm supposed to finish the .05 revision on ASAP.

[If I can stop following this thread maybe I'll get it finished.]
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf