Re: [homenet] HNCP security?

Michael Thomas <mike@mtcc.com> Fri, 19 September 2014 14:29 UTC

Return-Path: <mike@mtcc.com>
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 912031A019C for <homenet@ietfa.amsl.com>; Fri, 19 Sep 2014 07:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.754
X-Spam-Level:
X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 TxJ9QGBSodH6 for <homenet@ietfa.amsl.com>; Fri, 19 Sep 2014 07:29:40 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845F71A0193 for <homenet@ietf.org>; Fri, 19 Sep 2014 07:29:40 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s8JETc32010031 for <homenet@ietf.org>; Fri, 19 Sep 2014 07:29:39 -0700
Message-ID: <541C3DD2.30908@mtcc.com>
Date: Fri, 19 Sep 2014 07:29:38 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: 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> <541C3AFC.3020507@openwrt.org>
In-Reply-To: <541C3AFC.3020507@openwrt.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PMMWbVWlCR6qYcPxsx9-MJ-IzRw
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:29:42 -0000

On 09/19/2014 07:17 AM, Steven Barth wrote:
> 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.
>

Let's be clear: the enrollment and authorization problems are The hard 
problems. How the bits one the
wire are encrypted/authenticated is straightforward in comparison. Not 
having a standardized way of
setting this up will lead to chaos and the high likelihood that homenet 
devices will not interoperate. Doubly
so because the homenet architecture requires as little operator 
intervention as possible.

Punting on one of the hardest problems would be a travesty. There are 
plenty of people in IETF that are
plenty smart about this subject; we will never get an opportunity to do 
the right thing again if we loose
this into the wild and say "figure it out yourself." We know what 
happens then.

Mike