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

Mark Andrews <marka@isc.org> Tue, 07 February 2017 06:31 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 E0810129A94 for <dnsop@ietfa.amsl.com>; Mon, 6 Feb 2017 22:31:55 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uiOv4bkZw4xu for <dnsop@ietfa.amsl.com>; Mon, 6 Feb 2017 22:31:54 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 C080A1270B4 for <dnsop@ietf.org>; Mon, 6 Feb 2017 22:31:54 -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 53E053493EF; Tue, 7 Feb 2017 06:31:52 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 318EF160048; Tue, 7 Feb 2017 06:31:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1B980160054; Tue, 7 Feb 2017 06:31:52 +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 tPzV3z7tiWzR; Tue, 7 Feb 2017 06:31:52 +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 B9401160048; Tue, 7 Feb 2017 06:31:51 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BC04763357A9; Tue, 7 Feb 2017 17:31:46 +1100 (EST)
To: Brian Dickson <brian.peter.dickson@gmail.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>
In-reply-to: Your message of "Mon, 06 Feb 2017 21:50:24 -0800." <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com>
Date: Tue, 07 Feb 2017 17:31:46 +1100
Message-Id: <20170207063146.BC04763357A9@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Q5NrqvBqwfU6O0L_Ibl-wrSgObA>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
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: Tue, 07 Feb 2017 06:31:56 -0000



In message <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com>, Brian Dickson writes:
> Mark,
>
> I don't think the use cases for most of the sandbox involving alt, and/or
> the homenet use case, requires support for validating stubs. If stubs
> aren't already validating, the incremental addition of a local alt, only
> requires distribution of the trust anchor to the resolvers. That is a
> solvable problem for most values of "local".

It's not just stubs.

> If use cases for non-local or validating stubs exits, IMHO that rises to
> the level of requiring something real, not an alt name.
>
> If you think that is something that there is a demand for, I don't know
> if it might belong in a separate domain.
>
> An insecure delegation from the root may be seen as an invitation for
> exploitation by squatters.

And if they could find a way to squat here (which requires intercepting
queries) what would be the problem?  We are expecting the namespace
to be squatted.  Thats the whole point of the namespace.  In fact
we are going to tell nameserver vendors to squat on .alt by default*
to generate the NXDOMAIN responses.

There is absolutely no need for a secure NXDOMAIN here.  Just as
there is zero need for secure NXDOMAINs in COM, ORG, NET or any
other gTLD.  The gTLDs prevent secure delegations being spoofed
away.  The don't prevent names being spoofed into existence between
the secure delegations.

There is absolutely no need for a secure delegation here.

I have not seen anyone demonstrate a technical need for a secure
delegation for alt.  There are no formal delegation in alt so there
can be no secure delegations from alt.

Mark

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