Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Ted Lemon <mellon@fugue.com> Mon, 20 March 2017 21:14 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 F02C012896F for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 14:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 TZTHrcnsVwDY for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 14:14:41 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 F02251293DF for <dnsop@ietf.org>; Mon, 20 Mar 2017 14:14:40 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id y76so121193570qkb.0 for <dnsop@ietf.org>; Mon, 20 Mar 2017 14:14:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dgY+X8jblrfqm0w0GpN09o7YZi82m+5KBso6JmhSK/Y=; b=oih8IKmvGyczKs1Q3zXS+1vrBLp8Gy7YXuqJIXQ5p1Wjjm72NsNLEDrYmSzMfw2Tr4 +co/zAAk4nM80kMh33whwTb5Z2fctTRJhTUFTaFjqegVDKi8CkpSwjuDqkf0STItmD4z Z4Jsyf4zw/rX7FpZKitB+grtf7Vmb/cNnCCSAW092fK3MmGPrXOz8nypJBinZ7x9XlhO VgHcFomKKF77W/3ZeCwY6dmnW1DYKqkAbH91MYgsJswHsqPwvssgE0GbVVxAttpnWANu 7DpD2Y+ZvHOK/6kPbp7vJqoVy53mnPi+bvFoPGDB28dVpif5eUUe+syXO4GXBaeOCziW ssDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dgY+X8jblrfqm0w0GpN09o7YZi82m+5KBso6JmhSK/Y=; b=WOBXlq+vjnUU9PtzIzjJJOduPV6LFCeWrL/x/EIvwS4pOn1eGbYdVPOpFTVnWVqxNz FD6scJ23kOBJANeczN2oqX+lCYWM/6iarnLazvnT58D3verQi3uNo14LGtKq09Ep1vhb 2CaEMnMfuVxvDGqXA2C3IIXPWb+PCeA+qeNoZRN1p54Mbqn2wDiCZ5aGRG3AdykRjrws E5AlugvLczBjKi1uPkOO9uTORdTHqb6LVeke9E4kXySuSkmCvPFs92g2D+H6PAR97NRP 2+X0iT39OjwjubbJza9xjs9FwMJuHvz/UgKdPAVhrHmudQwfIeIzBHItzip4dMvZAOoi R/qA==
X-Gm-Message-State: AFeK/H2dgugjDzuUkoF7RGN0sZEHXYx5FqhsUINuQ4nabCRcRkVI9z3t+qugzoIkCBGoWA==
X-Received: by 10.55.186.67 with SMTP id k64mr27587556qkf.232.1490044479896; Mon, 20 Mar 2017 14:14:39 -0700 (PDT)
Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j1sm13257928qkf.57.2017.03.20.14.14.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 14:14:39 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <203D2BEA-1008-48A0-9CE2-1FD621C6117F@shinkuro.com>
Date: Mon, 20 Mar 2017 17:14:36 -0400
Cc: Russell Housley <housley@vigilsec.com>, dnsop <dnsop@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>, Terry Manderson <terry.manderson@icann.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3134EDC2-FB00-41EA-8338-6E6B196137F1@fugue.com>
References: <1E14B142-680B-4E30-809B-68E03EB6E326@gmail.com> <61FD3EE3-3043-4AB1-9823-6A9D61B1438C@vigilsec.com> <BE2A3845-D8AA-433A-9F00-1056ECFD335F@fugue.com> <21C8F856-FE3F-42A6-A8ED-888D0797B68B@vigilsec.com> <60C85486-E351-4C42-ADEB-FCBB56F4EA27@fugue.com> <AB11455F-7E43-4CB3-9F13-DB6A09F739EB@vigilsec.com> <CEC8CC6A-861A-471C-B7FA-4BB05C81CCF0@gmail.com> <F7AA49EF-2708-4948-9B60-6660DA6BC841@vigilsec.com> <734EC35A-4B1F-43EB-BE37-C34CA46BDA26@fugue.com> <203D2BEA-1008-48A0-9CE2-1FD621C6117F@shinkuro.com>
To: Steve Crocker <steve@shinkuro.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tPH73QpL6ygNJ0gdxRdu8q8e9eA>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
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: Mon, 20 Mar 2017 21:14:43 -0000

On Mar 20, 2017, at 4:57 PM, Steve Crocker <steve@shinkuro.com> wrote:
> First, neither my opinion as an individual nor my opinion as an official of ICANN should be considered definitive, normative or otherwise compelling except and unless the substance of what I say makes sense

I was being facetious, in case it wasn't obvious. :)

> Second, speaking as an observer and with some familiarity with DNS, DNSSEC and with the process related to entering strings into the root zone, the homenet sequence seems backwards to me.  I would have expected the coordination to happen before or during the working group.  If the homenet spec is approved as a proposed standard but there’s no agreement to put .homenet into the root or there is a glitch somewhere else in the coordination, the IETF will be in the position of having published an unimplementable standard.  Running code is the hallmark of the IETF and a primary distinguishing characteristic, so I’m surprised and puzzled if this is the path the IETF is taking.

It is a bit backwards.   The name '.home' got allocated in the HNCP RFC without due process, so we wound up suddenly needing to fix that.

> Third, having now read the homenet spec, I see what the point is, but I can also see a bunch of questions.  It looks like the idea is to establish a local DNS tree that is good only within a home or similar contained environment.  This is analogous to a 192.168.x.x environment.  To make this work, ignoring DNSSEC for a minute, it seems to me the DNS queries have to go to a DNS resolver that is acting as a local authoritative server for .homenet.  This is problematic because there are often multiple DNS stub resolvers operating within a single machine, and there’s no guarantee they will send their queries to a particular local DNS server.  The only way I see to force the issue is to intercept all queries headed for port 53 outside the local environment and examine them for .homenet.

You should bear in mind that homenet is assuming the Internet of maybe five years from now, more so than the Internet of now, although obviously we'd like to get done sooner than that.   So you should assume that stub resolvers never, ever do anything so foolish as to trust a recursive resolver to validate for them.  And, indeed, as you say, any resolver that doesn't use the host's resolver configuration to figure out which resolver to talk to isn't going to be able to resolve queries in the .homenet domain.

We don't consider this to be a serious problem.   Are you aware of some reason to think it is?

> Fourth, I’m not sure I understand what the issue is with DNSSEC.  If the queries are intercepted locally and if you trust the internal environment — an assumption you might want to ponder carefully as internal environments become ever more complicated and populated by devices and software from many, many sources — DNSSEC doesn’t come into play.  If the queries are not intercepted locally, you’ll get the official answer, viz NXDOMAIN.  I gather you want something else, and perhaps I didn’t read carefully enough to understand what that something else is and why it would be helpful.

The queries are being resolved by a local resolver.  But they are being validated by the stub.   So if the local resolver gives an answer that doesn't come with a secure denial of existence, it'll work.   If not, the stub will find any answer for .homenet to be invalid, because there is a chain of trust, and the chain of trust says that .homenet doesn't exist.

> What emerged most clearly for me in reading the homenet spec is the apparent desire to have a locally served domain, which seems similar in some respects to a classic split domain, and the real challenge, as best I can see, is characterizing the perimeter and internal topology.

We are addressing a problem with locally-served zones that existing documents do not address.

> And returning to the first point, let’s do indeed get people together to understand how the parts are supposed to fit together.  Over at ICANN we try very hard to be of service and we also take the security and stability of the DNS, and particularly the root, very seriously.  A non-standard request is almost going to be the beginning of lengthy discussion.  Our mind set will be aimed at getting it right, not arguing about who’s in charge.

Understood and appreciated.   If the document reads as suggesting something other than this, I apologize, since I probably wrote that text.   The working group's intention matches what you have said here.