Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 15 December 2016 00:43 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03272129CB9; Wed, 14 Dec 2016 16:43:57 -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 9v7VhmDSM4Vy; Wed, 14 Dec 2016 16:43:55 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 C0327129BA0; Wed, 14 Dec 2016 16:43:54 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id t79so21190530wmt.0; Wed, 14 Dec 2016 16:43:54 -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=7MQBO/7M0O07ZfU1RHGDR3WfM0OvP1g8sxxBwyVQBpM=; b=W9wZepaM5knSHDzAKOQpp1xgZVNUor01sXuDWFtsNJ7Emlf/FTenNGSWPYqh01R5/I ow7O1e+glz/EInkP5m7VcKwdL9695SYt3+7xJH0YJARBfH8j16sjao2YLY9qEApT6KgA q5B5XHmzEVHCEcCfbT1czbyRVRdff/bfDKoSA5qquV9GGlFFmnWaeJwyrE77xU+Q9/bN G+/VKvzW7XRN5N6kW5yD/4ZfwmbvVwiCr+jbpxiBt7rli0JZX01EtP/4/i+rqskNmZVa 2kA6kQFaJ+QKDK6HFP18k8P1+HwzcMc2Y4NpqRTcbviJ7Zz7GR3vu5XUTW9yhjwGbUQ/ WKMw==
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=7MQBO/7M0O07ZfU1RHGDR3WfM0OvP1g8sxxBwyVQBpM=; b=ihxkxjP6Vl/AKlscGmddHshoSMvEinHULatZgW9sDaABa64Yg+cWh5lnUimB7+u/Eq j043247kg8jVHc0fpmII0f9F14LrWXtMFDp2CSX/CO2VdmrVPtk60046wnKTTMV4gr6G Yfx23VKdj+mOVvQa5y595Z/qt+1r5tMnJkhuZqcUD3oVuMZRs13mmG9MLK0njN+2NtFk E8HFaC4r/3HcEaAZYeEQcZ0zfzB40dMFRTiOe0KegmL4yGyDeyjvgsQqgVfvezsdmtsC eeTmaeJMopFJY/80UcuPt+kCQc4Q4Li9yV+QKUF8GFt7gbZDEijO33kdL254rCm+lsok z25Q==
X-Gm-Message-State: AIkVDXKP4JJNh+JfkGX1NGJmy199Tk9PjMLtpZLfZBiWC33Epm3iLZ4Lio6YZGYYdaHUv5KQ9jqxEDOe540uaQ==
X-Received: by 10.28.143.68 with SMTP id r65mr64804wmd.95.1481762633211; Wed, 14 Dec 2016 16:43:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.203.70 with HTTP; Wed, 14 Dec 2016 16:43:52 -0800 (PST)
In-Reply-To: <9EC2695D-5CC5-479F-9998-27810608E71E@fugue.com>
References: <20161214220428.1688.qmail@ary.lan> <9EC2695D-5CC5-479F-9998-27810608E71E@fugue.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 14 Dec 2016 16:43:52 -0800
Message-ID: <CAH1iCioPZiO78j478BV7t=pTN9LZXQbweeBZQF2w3O1gKwx3XA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="001a11467d6664e2fe0543a7bf0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/QUet_cQkllTW8A6ck_81yi_yKRc>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, John Levine <johnl@taugh.com>, homenet@ietf.org, msj@nthpermutation.com
Subject: Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 00:43:57 -0000

On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon <mellon@fugue.com> wrote:

> On Dec 14, 2016, at 5:04 PM, John Levine <johnl@taugh.com> wrote:
>
> But it's worse than that -- if your client software does DNSSEC
> validation it needs to understand that homenet is a special case and
> it's OK not to validate.
>
> [etc]
>
>
> That is precisely why we need an unsecured delegation.
>
>


I agree that in the current world, an unsigned delegation is required.

I would humbly suggest that use of an AS112-like set of well-known names
and IP addresses, would be the preferred way of DOING that delegation.

A well-known address set would allow homenet-aware devices to be pre-loaded
with the address of the NS, while non-aware would learn it through the
delegation.

If it were possible to have the names be served by root servers (as a
consequence of being in the set of domains served by the root servers),
then the glue data would be signed and validate-able, which is about as
good as you can get (security-wise), while making homenet strictly local.

(Within a given homenet, the well known IP(s) could be handled via anycast
or similar mechanisms, presuming the homenet mechanisms support things like
that.)

My personal recommendation would be non-RFC-1918 well known addresses.

This ensures that for queries that leak from non-1918 space sourced
queries, that the delegation is to an address that is guaranteed to be
reachable, even if the local set-up is badly broken.

That IP would be configured to give itself as the answer to any query, and
be configured to provide (rate-limed) HTTP (wild-card) responses,
that serve up the RFC for how to set up homenet. (If that RFC doesn't
exist, that really should be next on the WG milestones.)

All roads would then lead to the answer to the question, which is, "How do
I get this stuff to work?".

Brian

PS For the DNSSEC-aware humans:

I think this exposes an unforeseen edge case, not covered in the design of
DNSSEC.

I think what would have been ideal, would have been the ability to securely
delegate to a well-known name/address, but without a secure entry point.
I.e. where parent/child NS use different RRTYPEs, and the parent NS is
signed (along with glue), and there is no DS.

The child could exist as an island of security, and have a self-signed
DNSKEY (or KSK/ZSK pair).