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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 08 February 2017 23:05 UTC

Return-Path: <brian.peter.dickson@gmail.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 D931E12941D for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 15:05:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 Mr7kWfWp2Dd2 for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 15:05:51 -0800 (PST)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 5306712A0A5 for <dnsop@ietf.org>; Wed, 8 Feb 2017 15:05:51 -0800 (PST)
Received: by mail-io0-x229.google.com with SMTP id j18so3409544ioe.2 for <dnsop@ietf.org>; Wed, 08 Feb 2017 15:05:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8mJNbQGtKJqlZyycQCuII7hYO1rf1f8cEmWn/INitjY=; b=o4IS215+wejOSmwFy5MGz+qC14Oi4LUg1OZC9XKF79569Rkz6Ag2F/bRuUm7co1BsX QshtvSYQnYCBbQ8RrNE85AYO9Yc77iSk1mnmMe4FJBXCmuKkSN8S7KIuYYtQW3Fj2mAR kt0de7jEXHkrXldsFQdF23uV/0vgE00I5yP7q4SVbFIDuvPw4mKTGv1P+sewABDKCa12 CM2as/hD8ITf8OzaiDXQ3goR2l29n5BMPLiV6yqcsJFARpLnr6Ya05SZAkfL/GymhYWm O628ORob7rrqk+5qxrv553LO6zdqGBTz+NnxDo2d3etIdLFyz+Ebk9F296oY4v/GEibq 3GQw==
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=8mJNbQGtKJqlZyycQCuII7hYO1rf1f8cEmWn/INitjY=; b=SlNIeVvU0W7w60fU6B6xTsXJ4R6H29llmOhGVYLxNBPa1BW5yWTSWNWOfE5CZ/+EIK sCmxUcwP2zn2vVtGvi1tw5HnzkHRl/Shjq6LjLpARuzmHOScSVJaBA2Jx9VSFJTDINFW bigCopgLPFgVFd18DmlIYhMOu/c6Hvm6idVEKaXtcNYTS+RlmW3yqsiGcOC+OX9lM3yD fPE4arWkNqujBCtUr9wf3C5jo0RjolRfmkLodvbVq/LlYIqH2Loo0vVnACYKPaoaQ9Rx Dn9KouK7lLFDcH2dGHNT1w5FJdStB9t1tol0SRxj4gBWfVCIeSqIjOYgryO7LUkkpfTj DZJQ==
X-Gm-Message-State: AMke39l3hoP41n0N2nHd/2KiRAedG8oS0oPnHrezZ6pZ/MecSJkNONcMhAqC8DYNaTGXpWJZpTNVcis2km69/g==
X-Received: by 10.107.131.229 with SMTP id n98mr672507ioi.39.1486595150634; Wed, 08 Feb 2017 15:05:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.133.208 with HTTP; Wed, 8 Feb 2017 15:05:49 -0800 (PST)
In-Reply-To: <20170208224131.256CC635E87D@rock.dv.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> <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> <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> <20170208203018.CF0B5635DFA1@rock.dv.isc.org> <A6839264-7054-4A08-828B-66BFA6C94352@fugue.com> <20170208224131.256CC635E87D@rock.dv.isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 8 Feb 2017 15:05:49 -0800
Message-ID: <CAH1iCirKzmjkOSKoHG56NqjgMO8SrW2ThoH47RK3VhtJ=vDM+w@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary=001a113ec5f4e0f12b05480ce78e
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SQ7aXKh1z9t1yeFhUXTP-MMgvik>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Ted Lemon <mellon@fugue.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 23:05:53 -0000

On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews <marka@isc.org> wrote:

>
> In message <A6839264-7054-4A08-828B-66BFA6C94352@fugue.com>, Ted Lemon
> writes:
> >
> > On Feb 8, 2017, at 3:30 PM, Mark Andrews <marka@isc.org> wrote:
> > > And if the service has the same privacy issues as .onion has?
> > >
> > > So we leak names until every recursive server in the world is
> > > validating (what % is that today?) and supports agressive negative
> > > caching (still a I-D).
> >
> > I feel like I am arguing with a wall, so if this doesn't work I will just
> > give up.   But if it's okay for us to ask resolvers to make a chance, it
> > is okay for us to ask resolvers to make the right change.   And if they
> > don't, yes, it's possible that some queries will leak.   There is nothing
> > we can do to prevent that other than harden caching servers and stub
> > resolvers; if we are going to do that, we might as well do it right, by
> > caching the full proof of nonexistence, rather lying about what's in the
> > root zone.
>
> Actually we can do something that doesn't require that validation
> be enabled.  We don't have to create that linkage.  It's not like
> the names are not supposed to exist.  They do/will exist and not
> as in they are/will be squatted upon.
>

I'm confused here.

The point of ALT (and/or LCL if a 2nd draft is created), and ONION, is that
they exist ONLY within their own (local) scope, if they exist at all.

>From the viewpoint of the global DNS, they do not exist, and the point of
those I-Ds/RFCs is to enforce that non-existence, in the global scope.

My problem with what you are proposes, is that it removes the mechanism for
that enforcement.

Here's a thought - for any/all validating stubs, use CD=1 for names in the
set of "things that are meant to be local", and turn off validation of
those.
That *should*, if I understand 4035's directives for CD=1, prevent
validation by the recursive resolver in use by the client, and will return
whatever answers are present, with or without DNSSEC records.

Or, perhaps the organizations that represent the requestor of the 6761
names, could establish something like a "distrust anchor" - a trust anchor
which is only to be used for signing negative assertions about the TLD
name, or assertions about its insecure status to enable local service of
the TLD name, and which can be published to the community, along with a
static DNS zone file to be served by the <name>-aware resolvers?

Again, just to reiterate, in the global root zone, and for any resolvers
which are not yet onion-aware, onion does not exist and must not exist.

For onion-aware resolvers, everything related to onion is just an
optimization; avoiding leakage for privacy reasons might be an issue for
some folks, but IMHO must not tread on the previous requirement - that
onion must not exist in the root, and must not appear to exist to any
onion-unaware resolvers.

If you want to find a way to fix that, without resulting in BOGUS or
SERVFAIL, there may be ways that aren't easy, but the one way not permitted
by the published RFCs is, an unsigned delegation in the root.

I'm not sure why you disagree with this, it is clear as day in the relevant
RFCs.

Brian




>
> Oh sorry, you can't have privacy unless you validate.  And only
> because people are too scared to ask for changes to the root
> zone to add a delegation.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>