Re: [dane] Network errors ARE attacks - on the end-to-end-principle

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 16 May 2012 15:19 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CCF21F85C5 for <dane@ietfa.amsl.com>; Wed, 16 May 2012 08:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599]
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 j-ysJSlIRpoP for <dane@ietfa.amsl.com>; Wed, 16 May 2012 08:19:49 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 17BDD21F852E for <dane@ietf.org>; Wed, 16 May 2012 08:19:49 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 834AE1ECB41C for <dane@ietf.org>; Wed, 16 May 2012 15:19:48 +0000 (UTC)
Date: Wed, 16 May 2012 11:19:46 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dane@ietf.org
Message-ID: <20120516151946.GJ26714@mail.yitter.info>
References: <CABcZeBMY26xrfvAx=UsYN2XnuONZ2vPy9tNwHQALudd=yQDvgA@mail.gmail.com> <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <alpine.LFD.2.02.1205142229552.10990@bofh.nohats.ca> <CABcZeBMS9cJ3m6JwJED7XAqdsF=zbTUUU_o3-opiZvqMyr7mdw@mail.gmail.com> <alpine.LFD.2.02.1205142352010.10990@bofh.nohats.ca> <20120515112154.GA20521@mail.yitter.info> <alpine.LFD.2.02.1205150816001.14601@bofh.nohats.ca> <201205160213.q4G2DGcF017008@new.toad.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201205160213.q4G2DGcF017008@new.toad.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 May 2012 15:19:49 -0000

On Tue, May 15, 2012 at 07:13:16PM -0700, John Gilmore wrote:

> "Genuine network errors" from buggy proxies or intentional firewalls
> or intentional or accidental censorship systems ARE attacks.  They are
> attacks on the fundamental end-to-end premise of the Internet.

But (1) bugs are different from intentional blockage and (2) not all
of this is strictly speaking buggy.  The fact that some ancient
gateway can't cope with RRTYPEs it doesn't know is, IMO, a disgrace;
but they can say (correctly) that they just don't implement that RFC,
and be quite right.  I would like the market to reject such devices as
useless, but it hasn't yet.

> But the end result will be that (1) users will realize they are being
> censored; (2) providers will clean up the accidental and whim-related
> censorship; and (3) users will migrate to providers who offer them
> reliable end-to-end service without interruptions for the provider's
> convenience or profit.

I suppose that the above is intended to argue that the market will
reject such devices as useless.  I think we have a first mover
principle in the way, however.  These "users" of which you speak would
need to form a fairly detailed theory of operation of the Internet in
order to understand what the problem is.  I don't believe that most of
them will, and I don't think they ought to need to either.  Therefore,
I would prefer that we build documents that permit useful incremental
addition of features to the network.

To drag this back on topic, in light of the above I need to think
harder about the argument, elsewhere in this thread, that uses 2 and 3
are also undermined by the no-answer attack, because if that's the
case then I suspect DANE is undeployable as it stands.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com