Re: [Roll] home-building-requirements section 7.1

peter van der Stok <stokcons@xs4all.nl> Mon, 24 November 2014 08:50 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740421A1DFA for <roll@ietfa.amsl.com>; Mon, 24 Nov 2014 00:50:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 xaQrPbEEu7pj for <roll@ietfa.amsl.com>; Mon, 24 Nov 2014 00:50:29 -0800 (PST)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03B61A1DBD for <roll@ietf.org>; Mon, 24 Nov 2014 00:50:28 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud3.xs4all.net with ESMTP id KLqS1p00G4NtgTm01LqSvB; Mon, 24 Nov 2014 09:50:26 +0100
Received: from [2001:983:a264:1:64eb:3bd9:ee99:d867] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 24 Nov 2014 09:50:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 24 Nov 2014 09:50:26 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl>
References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl>
Message-ID: <60a7b1e9499ecc8895750534e0cbfd4e@xs4all.nl>
X-Sender: stokcons@xs4all.nl (//AcwV7VW9RQH6/kVB35PoIHtbyxcG10)
User-Agent: XS4ALL Webmail
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Z_u0T9PqQQUQnFq5pgztUy4wVUg
Cc: roll@ietf.org, mcr@sandelman.ca, Anders Brandt <abr@sdesigns.dk>
Subject: Re: [Roll] home-building-requirements section 7.1
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 08:50:30 -0000

Hi Michael, rereading section 7.1, I suggest the following replacement:

A new DTLS protocol is proproposed in [dtls-relay]
  To be replaced with:
New approaches to initial security deployment are being developed in 
[dtls-relay] and [6tisch bootstrap]. Other initiatives are likely to 
emerge in the context of minimal intervention configuration.
At this moment it is not clear what the final most widely deployed 
solution will be.


peter van der Stok schreef op 2014-11-24 08:17:
> HI Michael,
> 
> thanks for the encouragement.
> Concerning bootstrap and security in general. Many things are going on
> and there are two approaches to this document:
> 1) a conservative one; restrict to what exists and is is proven to work
> 2) leaving the doubt that exists today.
> 
> For the moment I like to leave the doubt, because in 5 years, what is
> sure today will not be implemented is my conviction
> 
> Concerning switching on/off:
> That is SDO stuff; KNX , BACnet , etc... are preparing additional 
> standards.
> 
> What are enrollment tools?
> 
> Peter
> 
> 
> Michael Richardson schreef op 2014-11-23 22:16:
>> I am very pleased with the document; I hope the WG is reading it, and 
>> is
>> also happy with it.
>> 
>> In secton 7.1 you mention use of PANA to secure new nodes.
>> The reference seems very hesistant, and the DTLS relay is just kind of
>> thrown in.   Can you make this recommendation more concrete? Or remove 
>> it.
>> 
>> If it's PANA, I assume EAP is involved, and so what what EAP methods 
>> should
>> be used?
>> 
>> I think that, having read this document, I ought to be able to create 
>> a
>> light-bulb or light switch --- I think that I can make it function in 
>> the
>> network, but I don't think it will use the same enrollment tools at 
>> all, and
>> I'd sure like to change that.  I don't mind being really really 
>> specific
>> here: I encourage it.
>> 
>> I also don't know what protocol to use for turning lights on/off, but 
>> I
>> acknowledge that is out of scope for the ROLL WG to specify.  Perhaps 
>> there
>> is an informative reference I missed.
>> 
>> I think that unless you have a specific way to use the DTLS relay, you 
>> should
>> remove the reference -- it doesn't help anyone trying to implement an
>> interoperable device.