Re: [homenet] HNCP security?

Steven Barth <cyrus@openwrt.org> Fri, 19 September 2014 14:17 UTC

Return-Path: <cyrus@openwrt.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A77B1A01AC for <homenet@ietfa.amsl.com>; Fri, 19 Sep 2014 07:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] autolearn=no
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 N75gqg7R5uQS for <homenet@ietfa.amsl.com>; Fri, 19 Sep 2014 07:17:36 -0700 (PDT)
Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id DC4371A0199 for <homenet@ietf.org>; Fri, 19 Sep 2014 07:17:35 -0700 (PDT)
Received: from [192.168.178.66] (55d412ec.access.ecotel.net [85.212.18.236]) by chi.subsignal.org (Postfix) with ESMTPSA id B992A1260A7; Fri, 19 Sep 2014 16:18:02 +0200 (CEST)
Message-ID: <541C3AFC.3020507@openwrt.org>
Date: Fri, 19 Sep 2014 16:17:32 +0200
From: Steven Barth <cyrus@openwrt.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Michael Thomas <mike@mtcc.com>, homenet@ietf.org
References: <7BDD2D54-1058-4196-9BAD-770544096C93@iki.fi> <830.1410875532@sandelman.ca> <47647B8C-E3E6-4291-9F31-FBEE5FF53BFC@ecs.soton.ac.uk> <EMEW3|ba68076a23b44efccb32951649dba30aq8FLVJ03tjc|ecs.soton.ac.uk|47647B8C-E3E6-4291-9F31-FBEE5FF53BFC@ecs.soton.ac.uk> <alpine.DEB.2.02.1409170820460.14735@uplift.swm.pp.se> <5419A19F.1030808@mtcc.com> <alpine.DEB.2.02.1409180643250.14735@uplift.swm.pp.se> <541A7C1E.6090005@openwrt.org> <2D09D61DDFA73D4C884805CC7865E61130E839B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <FD0A639D-2B33-473C-9F91-5AD39B30BBF8@fugue.com> <0F4C6033-0D1F-4B5E-B47E-72F87F888C50@townsley.net> <E079CE93-BD9B-4D02-B327-DFA2EDE00602@iki.fi> <541C370D.2050704@mtcc.com>
In-Reply-To: <541C370D.2050704@mtcc.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PkZCeVFhRCcSHK1ajOglYQwR24g
Subject: Re: [homenet] HNCP security?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 19 Sep 2014 14:17:37 -0000

Am 19.09.2014 um 16:00 schrieb Michael Thomas:
> And it's extremely unlikely that
> DTLS will be a one-sentence "solution" even if it gets adopted because 
> DTLS, IPsec, etc say nothing
> about enrollment and authorization. Those are by far the hard problems 
> with homenent security.
I wouldn't really want to lock HNCP to any trust scheme at this point 
where we are not even sure what we want. I'd rather choose the 
underlying mechanism, either DTLS or IPsec/IKE and leave the rest 
out-of-scope. Maybe mention PSK-usage as baseline option and say various 
other certificate-based approached are possible but out-of-scope of the 
HNCP draft itself.

In practice users could probably run either their own in-home CA (e.g. 
like draft-behringer-homenet-trust-bootstrap) or we could add a 
web-of-trust-like extension to HNCP using transitive trust as proposed 
in draft-bonnetain-hncp-security or some weird combination. Either way 
it all stands and falls with the final user experience, e.g. the APP and 
the router's interaction with it for trust-bootstrap or the 
Web-UI/APP/Push-Button which let's you actively "trust" your peer in the 
web-of-trust approach. But user-experience isn't something we can really 
specify here.