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

Ted Lemon <mellon@fugue.com> Fri, 10 February 2017 06:23 UTC

Return-Path: <mellon@fugue.com>
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 E82501296FC for <dnsop@ietfa.amsl.com>; Thu, 9 Feb 2017 22:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 uHXFtT-5hWV3 for <dnsop@ietfa.amsl.com>; Thu, 9 Feb 2017 22:23:27 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CD61298A6 for <dnsop@ietf.org>; Thu, 9 Feb 2017 22:23:26 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id n124so15566599lfd.2 for <dnsop@ietf.org>; Thu, 09 Feb 2017 22:23:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IoP4qGY615VLUz5t4F5AdCToSUGD2k45fsP2oAGvzHk=; b=VEc8WZfgVWmXNmoNTRB7G4XYosdtudCAgEaExC3nd1S/cJ2AAYEqruC83f+HOOJT9/ n67UeEO77N+HNGHMNID72QT5El8IvZZDoK+xfb6BlpgWJT/qQtwXWRrAlb0RVb/0rflz AlGm3wHXVNYCv2UJNHIH1sXKaTGco5Hp0zITdss47wk3C33x9b4mveFN0BlLFr+bOWJs 7DiVyExkd+QEPD01xdeYMyNT4BS40i7OgTF5+tgQG5TDaVJjd88h7JbwFoZnz2IM//1j 6A8D7ImR77nNbygInkTEEvzP9yBvhjPMnxBzdhaMEdbopVvZfHhckAXXK4ku9MzJVZl3 DY+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IoP4qGY615VLUz5t4F5AdCToSUGD2k45fsP2oAGvzHk=; b=Z62mv6+J8OPsy7Dp98X5q/1PyUVXUKuvW/SORSMTOQ/4bZ7oazKVNM0lzUHEyWmrKD BFMKQnsLmmm0e27NQjQWTkeOvswhAQ6k6+GeAcoM10d0PKjk0Ih6XSsETTiVjkLcqzCP nvcJICsJTcBNW2ktLEAEbnPpm/jsV2EZqXT9ySGnoqKeK2bypH21hqSaByoyx3b5qV+J v21YEQKMpp1xyD+OSU7hCxH1TsyIfVx8OxzCvrLdrWwx9/1stiUzdzTZPtz+SAiabYgL e/zYkyR2PkA7czVtovxXBgPDighTLLLXtleMB/0eOycRgFtOBavJZvWhOa9B4LlJ5WP7 ExnA==
X-Gm-Message-State: AMke39nDZOFLocSy//P+eD1vNPDTEMQPzlhO8v45hiXkbTpHfKZj3RKJdArNM4TckY/ZX2QTr3+mU/vuIR0kJQ==
X-Received: by 10.46.69.215 with SMTP id s206mr2651127lja.26.1486707804974; Thu, 09 Feb 2017 22:23:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.20.67 with HTTP; Thu, 9 Feb 2017 22:23:23 -0800 (PST)
Received: by 10.25.20.67 with HTTP; Thu, 9 Feb 2017 22:23:23 -0800 (PST)
In-Reply-To: <20170210050701.704E56371DBB@rock.dv.isc.org>
References: <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> <20170208052544.862956356F33@rock.dv.isc.org> <FFAFD844-824C-44EA-A4B1-1AD28B4FE95C@fugue.com> <20170208060208.8C8E1635864D@rock.dv.isc.org> <E0A42577-0984-4ADD-8658-91413CBE783D@fugue.com> <20170208194208.DB02C635DD72@rock.dv.isc.org> <CAH1iCipA5nvWJqjdGUwJeeT_eU8EH8VYJU2hX1hJoiTb617K8Q@mail.gmail.com> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <CAPt1N1nLmdoZ_3Kb8Kfp9sTsN-GYqo1A9CF3j4zb7QCvO3SLew@mail.gmail.com> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <CFB6BEB2-4110-406A-A917-FC6361061B1C@fugue.com> <20170210004801.EEFE9636B89C@rock.dv.isc.org> <20170210015725.BF777636C97F@rock.dv.isc.org> <E5AB0A08-0DDA-496A-811E-25C1BA2765BA@nominum.com> <20170210050701.704E56371DBB@rock.dv.isc.org>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 10 Feb 2017 01:23:23 -0500
Message-ID: <CAPt1N1n1ShS0+5LpAHodRZ4wQF5QPpi2kAGx5kBE_DF8Hpv7rA@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary=001a114b162899d0e505482722be
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uLMMLLkIrzR2H-XI4kejCfdWfo8>
Cc: dnsop WG <dnsop@ietf.org>, Ted Lemon <ted.lemon@nominum.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: Fri, 10 Feb 2017 06:23:29 -0000

Could your concern be addressed with secure denial of existence plus the
right text about how to configure recursive resolvers?

On Feb 10, 2017 1:02 AM, "Mark Andrews" <marka@isc.org> wrote:

>
> In message <E5AB0A08-0DDA-496A-811E-25C1BA2765BA@nominum.com>, Ted Lemon
> writes
> :
> >
> > On Feb 9, 2017, at 8:57 PM, Mark Andrews <marka@isc.org> wrote:
> > > I'm developing software that will be run on private internets with
> > > various degrees of compentence from the adminitrators as well as
> > > the public Internet.  That private internet may have a ENT for ALT
> > > that returns NXDOMAIN.  The server has to work in that environment.
> >
> > I don't know what an ENT is.
>
> Empty Non Terminal which is a quite common acronym in this group.
>
> >   In any case, I don't see what this has to do with what we are talking
> > about.   It is an absolute fact that if you want ALT queries not to leak
> > you need to have a specially-configured recursive resolver,
>
> Pray tell what specially-configured recursive resolver works?
>
> > or else one that is really quite up to date.
>
> Actually one from the future.  We don't have a RFC that say to perform
> agressive negative caching.
>
> > If you have one that is really quite
> > up to date, a secure denial of existence will do the right thing.
>
> Only if you also validate.
>
> You are putting the "you can play bar" for privacy at the ceiling.
>
> > So we are really just arguing about how to specially configure
> > out-of-date resolvers.   This is really out of scope.   There is nothing
> > dnsop can do to make sure that these queries do not leak, so we should
> > just decide what the right design is assuming that all the moving parts
> > are working correctly, and leave it at that.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>