Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 30 March 2017 17:54 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 057B612952F; Thu, 30 Mar 2017 10:54:55 -0700 (PDT)
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 Dna2d0N-T3ot; Thu, 30 Mar 2017 10:54:52 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 EBE15128D19; Thu, 30 Mar 2017 10:54:51 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id b140so24487209iof.1; Thu, 30 Mar 2017 10:54:51 -0700 (PDT)
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=z7GNuBzKawqmBMhUX04y/xRfhnlcG6aZcfJ5Kh+A09A=; b=uVoVW/T5BWFX8t4fZSNp4k8VwkfAc01ozfqYcFftRB2VfSHKH4N4sG6nAO2SaqL8ar 0DT5/t1jd7KQYLM/cUH0FTO/GA9YQZdMiI2P9FXFiUpgNYDbkCfG31QI21NOm0oPgMTj x2+zaYrRfsEtnA5g0CENkjP5Rs3XR4pmAKR8QWrbnR8JLQwSjPS0ToMwKJz5go2+CxtY rQ6mJlwhdFlFmX59Bof4ZwEE/hfCwZ1EjAYBMyocdHC/dNZrc7sYnMLT5MNFZD2D27+1 +Vc4yZdb/wnV+d4X2kTUY7SIyKwRBOJHfN30ls/Khx27zo3Pt7DN5G6K/tPmI4Ulb8QH k0ag==
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=z7GNuBzKawqmBMhUX04y/xRfhnlcG6aZcfJ5Kh+A09A=; b=d+SOK2XSUUKNrbaikzJYaznmDSev6cS/Myr+bfMoZtSIA4bPGHvVm6ZSGOa5YRYoN2 dNMlRtqgt7DJQJ2KM56mqFsks8G5oAdQf3xo08hI0NLL8/b+R3cbppUDzH4ggEP/3tSN LZqTkGLw56wqZ+QVknqCJNJ58IARSDWUHDTBHKvBKjkUOGvN8lew0uVMR5OLRyvU6tVE h1aKspGoc0wltnT0AdVCRqcx0NdkcA2Doff2fRiX94zvisgoKjKDqw63qIcJb/bGUvww cmyXNtO5YF5k5jmFbJ6UfQFHlIPiAs2H3QLBuroEmOgLS/k3n1jQzeZvdFzgw/Kb0+nl XUsg==
X-Gm-Message-State: AFeK/H3bMbHP6a81T56tkaQ+cS1UrlnRR3irqVXJRvWJCeMmRhKFTNG18WiX6wo6Z6CHRApa/kPOTRRTe/6QSw==
X-Received: by 10.107.136.41 with SMTP id k41mr2124251iod.160.1490896491177; Thu, 30 Mar 2017 10:54:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.46.151 with HTTP; Thu, 30 Mar 2017 10:54:50 -0700 (PDT)
In-Reply-To: <20170330052006.008D66A4B0BE@rock.dv.isc.org>
References: <DAC83E33-A206-4EAA-BC96-E26ACCC013A6@icann.org> <29150.1490800075@obiwan.sandelman.ca> <D04E5190-AEE4-4F0A-9879-A913D5E65C28@townsley.net> <CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__+34BRowwUw@mail.gmail.com> <20170330052006.008D66A4B0BE@rock.dv.isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 30 Mar 2017 12:54:50 -0500
Message-ID: <CAH1iCir+ymEPi31f+ynCrPT4kfumPTLFMuyG4HdnnxYbbfg82w@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Mark Townsley <mark@townsley.net>, Michael Richardson <mcr+ietf@sandelman.ca>, HOMENET <homenet@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Terry Manderson <terry.manderson@icann.org>
Content-Type: multipart/alternative; boundary=001a113ec618c0ed6c054bf663af
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3UwuLDvGu088njy8PVEsd6G4r4Y>
Subject: Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 30 Mar 2017 17:54:55 -0000

Mark,

When I say, "never reaches the roots", this is what I mean:
Resolution of "example.<homenet-label>" is, by design, intercepted by
homenet resolvers, and never reaches the outside world.
Do you concur with this statement?

Please stop conflating the issue of "the homenet namespace is local" (and
thus not resolvable from outside starting at the DNS root) from the issue
of the need for an insecure delegation IF homenet end systems do their own
DNSSEC validation AND those same end systems don't special-case homenet
from validation AND IF homenet is not signed with a separate trust anchor.

Yes, IF validating stubs need to confirm the unsigned nature of homenet,
THEN there is a need for retrieving the appropriate DNSSEC proof showing
that there is a delegation out of the chain of trust anchored at the DNS
root.

What that proof looks like is dependent on the issue under discussion,
which is what the domain name for homenet should be, and why.

If the domain for homenet is "homenet." anchored in the root zone, then
yes, "homenet/DS" will need to be obtained (or more correctly,
"homenet/NSEC" proving no DS exists), signed by the ZSK of the root, along
with the signed DNSKEY set (signed by the KSK of the root, i.e. the ICANN
root trust anchor).

If the domain for homenet is something else, such as "homenet.arpa.", then
the proof contains more elements, such as the DS for arpa, and the NSEC for
homenet.arpa (proving no homenet.arpa/DS exists).

Brian

On Thu, Mar 30, 2017 at 12:20 AM, Mark Andrews <marka@isc.org> wrote:

>
> In message <CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__+34BRowwUw@mail.
> gmail.com>, Brian Dickson writes:
> > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley <mark@townsley.net>
> wrote:
> >
> > >
> > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson
> > <mcr+ietf@sandelman.ca>
> > > wrote:
> > > >
> > > >
> > > > Terry Manderson <terry.manderson@icann.org> wrote:
> > > >> B) seek a .homenet special use domain WITHOUT the delegation request
> > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
> > > >> community to achieve an insecure delegation
> > > >
> > > >> c) seek a <SOMETHING>.arpa insecure special use delegation
> > > >
> > > >> d) go for "B" and if that doesn't work shift to "C"
> > > >
> > > > Is there some reason we can not proceed with "C", concurrently with
> (B).
> > >
> > > I think that would require a new consensus call. There was a lot of
> work
> > > done to get to the point of agreeing on a path forward at the last
> IETF,
> > > and this path would be rather different than that.
> > >
> > > > This might cause stub resolvers to have to have two cases
> > > > (SOMETHING.arpa, and .homenet) eventually, but at least we could
> deploy
> > > > and attempt interop with SOMETHING.arpa NOW, and it would more
> clearly
> > > > permit "home." to be removed from code.
> > > >
> > >
> > > /chair-hat-off
> > >
> > > I don’t think we want to have two defaults in our specs. It’s bad
> enough
> > > that we are already going to end up with .home and .homenet depending
> on
> > > the version of code used or forked from, I really don’t want to do
> anything
> > > that could lead to a third if we can avoid it.
> > >
> > > - Mark
> > >
> >
> > Taking a STRICTLY devil's advocate position here:
> >
> > Isn't it the case that the thing that knows what the <homenet> label is,
> > should be able to masquerade on behalf of anything that isn't aware of
> the
> > divergence of the three possible values for <homenet>? If you end up with
> > some boxes thinking it is ".home", some ".homenet", and some
> > ".homenet.arpa", as long as one of them knows about all three, it should
> > be possible to resolve the differences.
> >
> > The scope of the namespace is "the home network", and never reaches the
> > real DNS (roots), so at worst it would be folding the three fake
> > namespaces into a unified (three-headed) fake namespace.
>
> Can we please stop with this "and never reaches the real DNS (roots)"
> garbage.  Queries for homenet/DS *will* reach the roots.  That is
> how DNSSEC validation is designed to work.  They *need* to be
> answered with a signed NOERROR NODATA response.  Lots of Linux
> distributions ship with DNSSEC validation enabled for on machine
> clients and they are also configured to forward to the nameservers
> that are returned by DHCP.
>
> These machines behave *exactly* like a validating stub resolver from
> the DNSSEC perspective.  This isn't something that will be in the
> future.  It is the PRESENT.
>
> > I.e. avoid it if you can, but if you can't, I think the issues are
> > solvable, even if they get a little funky/ugly under the hood.
> >
> > None of that should be visible to users, I don't think.
> >
> > Brian
> >
> > P.S. Guide to implementers - never expose multiple handles for the same
> > object; over-exuberant users may be tempted to try to "clean up" the
> > duplicates.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>