Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

Ted Lemon <mellon@fugue.com> Tue, 01 August 2017 15:04 UTC

Return-Path: <mellon@fugue.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 513881321A1 for <homenet@ietfa.amsl.com>; Tue, 1 Aug 2017 08:04:25 -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 rCuImt1ugczo for <homenet@ietfa.amsl.com>; Tue, 1 Aug 2017 08:04:22 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 8DE11132197 for <homenet@ietf.org>; Tue, 1 Aug 2017 08:04:22 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id x191so10604029qka.5 for <homenet@ietf.org>; Tue, 01 Aug 2017 08:04:22 -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=P1B6OIe48J/3JWuH0PStGgxGsJYYF+qfDy2zQh9AeHk=; b=IP2aTOUkDAaX/hcYBLCu3LdimucP3IX+Atu7gjJXkDEzxfWMWgTJGJ4XdsdQz4ngc3 zDgtcKNDWM7WWmJmg5PuQbUzTPWt4XgkhKO/flcXfartW9FjCKs2QgumAU3aATBmPkGv YkPPayD6XsZ6deVTzV24RPYafiFE/2LdZfzXf45SS6piktZ2NBHi1n0K4Zvm6QV2e4UR TInGWYh1MenH9068DnW+O03JpqU3KF1YGl9mDv9P1FkIuJbKdZQHtZGF/EKPFkIEZ66t pQbs0Y7642jrEAlDgKMJHdUj2AXPApLmRTCu8ohUACqap7nYmHzs4OZksbme2A6h1DKm qvww==
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=P1B6OIe48J/3JWuH0PStGgxGsJYYF+qfDy2zQh9AeHk=; b=FE2c8807SVZNeNOWT9+H3zCazvRxD97tuKmkuyqO4cizuZcEI+jTbFlQMKeGuGkIis KYGYGI0JyAMm6g4HoowbB4vfSBbgj0GMSx4yS+a0U//u2ecVUSkM236YjRgJhj0Tdl7M 4ezxPC7cAdKkrTWcjJY8thcMELjDu2X28iLbAPNTB6pYKnRDBVuervgm8w0qluVrDvgK alW6LLsOalhHLKwWOIfegy8+yNcd5keJXS0/+xkxALbgsLQFfAYAnR/UF7isz9qb1CK8 WuajmMtAQs2G7Nbk+H8Ak5HBD9+MIR4DW0abXgf7jzMMhfAXXlxzjed5PZhMiailPTEZ fLVA==
X-Gm-Message-State: AIVw112ZyzISHuL9F5G9N1P/jxkdBiHlm/+0/5kOhDFJ9U2M/kukIKgf LPBctkmuyfBis4Kj
X-Received: by 10.233.232.149 with SMTP id a143mr27682226qkg.339.1501599861517; Tue, 01 Aug 2017 08:04:21 -0700 (PDT)
Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r49sm23365526qte.34.2017.08.01.08.04.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 08:04:20 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A7DBD6C0-C7C8-4A7B-B76C-8BAFB8A4E09F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 01 Aug 2017 11:04:19 -0400
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com>
Cc: "Walter H." <walter.h@mathemainzel.info>, "homenet@ietf.org" <homenet@ietf.org>
To: "STARK, BARBARA H" <bs7652@att.com>
References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <E51998F5-8EF9-4FC8-90BE-1D0BF1805339@fugue.com> <b562a9fd0ce2d8af63109aac47d1d47a.1501567308@squirrel.mail> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/qoeeKuySUZig9qZPrmwa8E0sP9A>
Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 01 Aug 2017 15:04:25 -0000

On Aug 1, 2017, at 10:48 AM, STARK, BARBARA H <bs7652@att.com> wrote:
> The CABF is about "publicly trusted certificates". There is no need or applicability of "publicly trusted certificates" in the context of a home network. No certificate authority in the world is capable of certifying that a device inside a specific home network actually belongs there. The only entity capable of identifying devices that belong in the home network is the home (network) owner. This isn't about public trust. It's about private trust.

This distinction is meaningless, unfortunately, because it's browsers that we need to trust the network, and we absolutely do not want to install a network-specific trust anchor in every end-user browser.   Even if that were possible, it would be a gaping attack surface.

> In reading Stephen's email about what he did wrt certificates, what stood out to me were:
> (1) The primary goal was to stop the annoying browser warnings. [note that neither HNCP nor Babel would be expected to check against CAs stored in browsers, so they would not be subjected to this annoyance; but the annoyance is something to prevent when considering the broader "naming architecture"]

(1) this isn't an issue for HNCP or babel.   It's an issue for browsers.
(2) the issue with browser warnings isn't that they are annoying.   It's that if we train users to click through them when managing the homenet, we are also training them to click through them at other times.   This creates an attack surface in the user that we'd rather not create.

> (2) Stephen (the home network owner) was the assigner of trust. He was the root certificate authority.

This doesn't work because there is no grammar for ascribing different meanings to different trust anchors in browsers, as far as I know.   Attempts have been made, but it's ultimately binary: the end user doesn't perceive the difference.   Without such a grammar, we don't have a way to make Stephen the assigner of trust for his network without making him a potential assigner of trust for all networks for any device that considers him an assigner of trust.

> 1. End users would like to know that device software / firmware has no Trojans and is "good". This is not a good fit for X.509 certificates or PKI. This would be something for some logo-based certification program (like a UL, Good Housekeeping, IPv6 Ready, etc. stamp). I think this is outside the (current) scope of homenet and there are other orgs working on this sort of thing. In any case, it has nothing to do with encryption and X.509 certificates.

I think that people are talking about code signing elsewhere in the IETF; I would say that that is where this particular problem would need to be addressed.   I think there's work here relating to TEEP, but also to just regular code signing.

> 2. End users are the absolute (root) authority as to what does and doesn't belong on the home network. No one else. Even in the case of "unmanaged" home networks. Verisign and others are incapable of telling me whether or not a device belongs on my home network.

Sure.

> 3. End users want it to be very easy to add devices/services to the home network. 

Sure.

> 4. End users want it to be very easy to remove devices/services.

Sure.

> 5. End users want to know when devices on the home network are misbehaving, and they want to easily identify such devices.

Yes.

> 6. End users don't want annoying "untrusted" warnings for devices and services inside the home network that they have decided to add to it.

Yes, but s/annoying/attack-surface-generating/

> Does this seem like a reasonable list? Are there items y'all disagree with? Others to add?

I think this is a good start.

What might become interesting are the implications of this list: what it would take to actually satisfy these requirements.   :)