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

Ted Lemon <mellon@fugue.com> Mon, 20 March 2017 22:27 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 D64C1124B0A for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 15:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 gVulQ33d7AN0 for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 15:27:49 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 294AF126DFB for <dnsop@ietf.org>; Mon, 20 Mar 2017 15:27:48 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id i34so119007911qtc.0 for <dnsop@ietf.org>; Mon, 20 Mar 2017 15:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MALxngT0hJUixg5mX05hOrsL4kTBeQ12dsDnBYQJXpA=; b=XIzcWiHk0NmoomOD0rweJS/vjEME8/0xr/QySXhpuojA7Z4Wy8mWtwu/HQZ5qzyaCG 7OvcUUZuSHNDLV4juJeTR1Ju1icgJKme1ewko9hyWRBYXdFEQmCTrjCzsm8sF8Hu4nYc uyjNDq1a9x4kyUXxvCyhzstRe8Sycamw6s+eKHY3pAOpNKUa6yqPXSyAOMujVX0LXyTC 0HiqQPgYrNYiomYsIu4qwgeDOfr/i6ntawdsGHcqWUMdHLsvSOewWCarUw/Snj4EuyVX z12PaM0IHXjmkG2zP8JnO3iVuq1KhID/eOGe4HfEwMXMiDbL/OqIzZPTbEUkRtSWR/4G 7f8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MALxngT0hJUixg5mX05hOrsL4kTBeQ12dsDnBYQJXpA=; b=DLicpLwgMOLz7xBfSh2XDYWz2B6YlHCdFX04++8rbTbtKssykY418vrwrONrV5DTM3 2f+sPsxUkb5YqMw3MSCDljDaw+vU93MdOSJeDHfn4m89erIz7wqrN/N9IkgmfJzlwMcB bmVFfNvGHtMi/5G5sGby2qCwkCiZyVifu+zd1sdC+5paaoEuW5uNUXStEdoFzA/+WNHm Yk29MIjPt0ncn+O2p9/bswoUsspv3nV5bcmDxbB8Vwt6B6moIowYIYjTu4cKOb0yVEgm O/fxlNYAmcF17iBgYprUuDGOPGCggi7kGmEKAvEzACspyH0v6D7ZZjNCy1bE6u4cc4NH xikA==
X-Gm-Message-State: AFeK/H2HS46X9MAlzp7PCNBgR3WhQIl7D99BUyXlB0h8USL83TNbCR+wyzlpFmDrSQjmzQ==
X-Received: by 10.200.47.161 with SMTP id l30mr29363046qta.248.1490048867236; Mon, 20 Mar 2017 15:27:47 -0700 (PDT)
Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i125sm13371130qkf.52.2017.03.20.15.27.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 15:27:46 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <95935A30-9B77-4B7A-A0CE-4409134B6163@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C3E236A1-A829-45DD-8D0F-698DD94CA093"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 20 Mar 2017 18:27:42 -0400
In-Reply-To: <572B4EBA-F37F-4E92-A252-44BAF5DE7FF5@shinkuro.com>
Cc: dnsop <dnsop@ietf.org>, Russell Housley <housley@vigilsec.com>, Ralph Droms <rdroms.ietf@gmail.com>, Terry Manderson <terry.manderson@icann.org>
To: Steve Crocker <steve@shinkuro.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> <3134EDC2-FB00-41EA-8338-6E6B196137F1@fugue.com> <572B4EBA-F37F-4E92-A252-44BAF5DE7FF5@shinkuro.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7L9qt6uqj0BxoKmM-G_Fx7TebGQ>
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 22:27:52 -0000

On Mar 20, 2017, at 5:44 PM, Steve Crocker <steve@shinkuro.com> wrote:
> If you assume the local environment is going to get complicated and that signing of the local domain will become important in order to guard against hijacking by errant devices inside the perimeter, it looks to me there will have to be a local trust anchor. For devices brought into the environment, DHCP already assigns the IP address and the DNS servers.  It can “easily” be augmented to hand out the public key of the local hierarchy.  Or, I suppose, since I’ve just posited that the DHCP server will tell the new device which DNS server to use, the device could then query the DNS server to find out if it has a signed .homenet domain and what its public key is.

My theory for how to do the trust anchor is ToFU.   When you first notice you're on a homenet, query a well-known name in the homenet domain; that name will have a UUID attached to it.   That UUID identifies the homenet; if you've seen that homenet before, you look for the KSK that you stashed for it, and use that as a trust anchor.   If you don't recognize the UUID, you're on a different homenet, so you fetch a new KSK and set up a new chain of trust.

Of course, this assumes a certain sort of threat model which may not be the right one.

What I would expect to see happen is actually that very few stub resolvers validate until something egregiously bad happens that validation would have helped with. and then suddenly practically everything will start validating.   So I think it's pretty dangerous to have a situation where that will suddenly break service discovery on the homenet.