Re: [DNSOP] Review of draft-livingood-dns-redirect-00

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 15 July 2009 18:34 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2953A6A6C for <dnsop@core3.amsl.com>; Wed, 15 Jul 2009 11:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 j+WFgWac4+ia for <dnsop@core3.amsl.com>; Wed, 15 Jul 2009 11:34:46 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8FD6828C10A for <dnsop@ietf.org>; Wed, 15 Jul 2009 11:34:18 -0700 (PDT)
Received: from [10.20.30.158] ([12.130.118.18]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6FIYept023149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 11:34:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p062408adc683d0a46ecb@[10.20.30.158]>
In-Reply-To: <alpine.LFD.1.10.0907142351170.30778@newtla.xelerance.com>
References: <C680B730.EB2C%Jason_Livingood@cable.comcast.com> <alpine.LSU.2.00.0907131506280.30197@hermes-2.csi.cam.ac.uk> <alpine.LFD.1.10.0907131347330.8917@newtla.xelerance.com> <p06240806c681347afdd5@[10.20.30.158]> <alpine.LFD.1.10.0907142351170.30778@newtla.xelerance.com>
Date: Wed, 15 Jul 2009 11:34:33 -0700
To: Paul Wouters <paul@xelerance.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: dnsop@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 15 Jul 2009 18:34:47 -0000

At 12:08 AM -0400 7/15/09, Paul Wouters wrote:
>On Mon, 13 Jul 2009, Paul Hoffman wrote:
>
>>>>I think you need to widen that caveat: anything that isn't a web browser
>>>>should not use a DNS server that misbehaves as described in this draft.
>>>
>>>I think you need to widen that caveat: anything should not use a DNS server
>>>that misbehaves as described in this draft.
>>
>>Paul: that's over the top. Some of the services defined in the draft are highly desired by some Internet users. You may not like them, and that's fine. Your statement is akin to, and as useful as, the "NATs are bad so we shouldn't talk about them" debate that flares in the IETF approximately biannually.
>
>There is a huge difference here. With NAT, one is putting some
>inconvenience to the end user and the server administrator that requires
>some clarifications in protocols and some support with detecting it
>and working with it. With manipulating my laptop's DNS asking for MY
>OWN cryptographically signed data, you are asking me to throw out the
>crypto protection and make me accept a downgrade attack.

Then use a different DNS resolver. This document is about how to do one type of resolution, not all types.

>The IETF allowing or endorsing any kind of DNS forging in the age of
>DNSSEC is simply wrong.

This is more hyperbole that does not help the discussion. The IETF is not in the position to "not allow" anything, and it never has been. An Informational RFC is not "endorsing" anything.

If you want to endorse not doing what this proposed Informational RFC describes, write such a document and have it on standards track, or BCP.

--Paul Hoffman, Director
--VPN Consortium