Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

Paul Vixie <paul@redbarn.org> Sun, 16 February 2014 19:44 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C571A03EE for <dnsop@ietfa.amsl.com>; Sun, 16 Feb 2014 11:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPvrN_tJfGfr for <dnsop@ietfa.amsl.com>; Sun, 16 Feb 2014 11:44:36 -0800 (PST)
Received: from ss.vix.su (ss.vix.su [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1F1A0276 for <dnsop@ietf.org>; Sun, 16 Feb 2014 11:44:36 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:e06b:8433:a508:56ec] (unknown [IPv6:2001:559:8000:c9:e06b:8433:a508:56ec]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.su (Postfix) with ESMTPSA id B286FEBDA4; Sun, 16 Feb 2014 19:44:33 +0000 (UTC) (envelope-from paul@redbarn.org)
Message-ID: <5301152A.2090800@redbarn.org>
Date: Sun, 16 Feb 2014 11:44:42 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 3.0.9 (Windows/20140128)
MIME-Version: 1.0
To: Joe Abley <jabley@hopcount.ca>
References: <CAESS1RPh+UK+r=JzZ9nE_DUqcvNtZiS6TNt1CDN-C0uiU7HP=A@mail.gmail.com> <52FEF407.30405@redbarn.org> <20140215140133.GA6990@sources.org> <alpine.LFD.2.10.1402151449280.23619@bofh.nohats.ca> <D82F49E8-9A06-4F52-8E3E-DF5C8D0B7549@virtualized.org> <53006595.5010207@frobbit.se> <784CF51A-937B-4131-85BC-AED579FA746D@vpnc.org> <5300E9C5.9090702@frobbit.se> <DB47354C-AEBA-4861-8177-94993377E3E8@hopcount.ca>
In-Reply-To: <DB47354C-AEBA-4861-8177-94993377E3E8@hopcount.ca>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/tWR8BPNk_d1rMaPgv7mWPO6ssXU
Cc: dnsop <dnsop@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Feb 2014 19:44:38 -0000

Joe Abley wrote:
> ...
> If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them.

reflection attacks aren't a fact of life. DNS RRL does not require a
forklift upgrade of the infrastructure, isn't stopped by middleboxes,
and does not change the protocol. i think you should discriminate more
finely as to what we ought and ought not give up about.

> What I would prefer, though, is a more entrepreneurial approach where the likelihood of short-term operational problems (or even long-term failure of the work) should not stop us from trying. ...

those were my exact words upon the publication of RFC 2671. it's been
fifteen years. i think if any change to the dns protocol was going to be
useful enough to overcome edge corruption and edge inertia, it would be
EDNS0.

however, it's heartening to see another generation of cannon fodder
lining up to enter the trenches. you go, joe. i'll cheer you on. but
i'll be working on a RESTful/JSON API to hide DNS edge traffic inside
TLS, in sessions not managed by any X.509 CA, while cheering you on.

> So, how about a starting point where we assume that if a particular extension has value to anybody, the operators (the market) will adjust to allow it to work, and if it doesn't, then adjustments are not necessary?
>
> Anybody else feel like working on the specification for SCTP transport? :-)

go, joe, go!

vixie