Re: [DNSOP] ALT-TLD and (insecure) delgations.

Mark Andrews <marka@isc.org> Wed, 08 February 2017 05:25 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEC5129980 for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 21:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 OxKhf8UDZ4re for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 21:25:55 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E4412997F for <dnsop@ietf.org>; Tue, 7 Feb 2017 21:25:55 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2452D3493CF; Wed, 8 Feb 2017 05:25:49 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 04BFD16004F; Wed, 8 Feb 2017 05:25:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DA6E5160054; Wed, 8 Feb 2017 05:25:48 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GpB9GmNzf75B; Wed, 8 Feb 2017 05:25:48 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5B3E216004F; Wed, 8 Feb 2017 05:25:48 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 862956356F33; Wed, 8 Feb 2017 16:25:44 +1100 (EST)
To: Ted Lemon <mellon@fugue.com>
From: Mark Andrews <marka@isc.org>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <CAH1iCipKwcOsMQY3kjvSZ42LMK37GLD6GP2AVtnWK0c83k-RiA@mail.gmail.com> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <D4C0D518-A3ED-4555-93DA-2EA12D82A662@fugue.com> <CAHw9_iK7Vt+ZNw8=E-b+w9gGhwB9fZNqHYp2pqKqT__RgcDttQ@mail.gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <FB835756-2C46-40A9-88ED-2F8ADF812BA6@fugue.com>
In-reply-to: Your message of "Tue, 07 Feb 2017 23:51:03 -0500." <FB835756-2C46-40A9-88ED-2F8ADF812BA6@fugue.com>
Date: Wed, 08 Feb 2017 16:25:44 +1100
Message-Id: <20170208052544.862956356F33@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Y9WEf5C--EIQqiMfonXuKHMx98w>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Feb 2017 05:25:57 -0000

In message <FB835756-2C46-40A9-88ED-2F8ADF812BA6@fugue.com>, Ted Lemon writes:
>
> On Feb 7, 2017, at 4:48 PM, Mark Andrews <marka@isc.org> wrote:
> > Go add a empty zone (SOA and NS records only) for alt to your
> > recursive server.  This is what needs to be done to prevent
> > privacy leaks.
>
> No, the recursive server can just cache the proof of nonexistence.   I
> didn't query the root when I did my test—I ran the query through
> comcast's servers.   Worked just fine.   Yes, if you configure your local
> server to lie, that won't work.   That's by design.

And how does the server get the proof of non-existence?  It needs
to leak a query.  You server asked comcasts servers.  They in turn
asked the root servers.  By doing so you leaked the query to both
comcast and the root.

Unless you have aggressive negative caching or qname minimisation
you will leak all the leaked *.alt names.  Are you requiring that
every recursive nameserver on the planet older than a couple of
months be upgraded rather than reconfigured to get privacy?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org