Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG

Kent Watsen <kent+ietf@watsen.net> Wed, 04 September 2019 16:18 UTC

Return-Path: <0100016cfd11fc06-cacd955b-653b-4b31-996a-275c83b63dce-000000@amazonses.watsen.net>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC721200B9; Wed, 4 Sep 2019 09:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 ZxPbbc5xLtGx; Wed, 4 Sep 2019 09:18:32 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90685120912; Wed, 4 Sep 2019 09:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567613910; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=pOJpy6xK2PpZ5rwoXmTz+U+lgFlomcHLF6sqzn8e3P0=; b=XNyLHfSCoS9DcdgNnlFrtyqZlIc9Co9HkMDEMMCA/lduRwotNt1rJLP2faWRm3Qn PXPwXudeRQj7KUvmsoFzQMc4KyBXDeGNUPMQf228VgaT7z7aqEUkJOooCgju8WDSwGu O1Ke4J54RUN4xYC6rrJboc2TXjLJopxvPcp0M9A4=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016cfd11fc06-cacd955b-653b-4b31-996a-275c83b63dce-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_562AB405-328D-4ACF-B980-170526FC1774"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 04 Sep 2019 16:18:30 +0000
In-Reply-To: <30978.1567609932@dooku.sandelman.ca>
Cc: iot-onboarding@ietf.org, mud@ietf.org
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> <30978.1567609932@dooku.sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.04-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/nCYPeJRhTkahxNnZboHhXILJ_kE>
Subject: Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 16:18:34 -0000


> Kent: I am feeling a bit of "my protocol vs your protocol" in your reply.

Fair point.  I just want to ensure what you say at bottom...


>      It is not my intention to do that.  I think that we did an awesome
>      job getting to the commonalities with 8366.  I'm not sure that this
>      is as visible to others.

Indeed, as witnessed by the plethora of activity brought forth since.  :thumbs-up:


> Yes, but is that really appropriate?  Are the right people there in ANIMA,
> and is it actually disruptive to the ANIMA effort beyond onboarding?
> In particular the constrained document is not getting enough attention.

Unsure.  It's a blurred line to me where ANIMA stops and this might begin...



> Sure.  I put it there so that people could find it.

Okay, but folks should know that, while produced by NETCONF WG, it really has nothing to do with NETCONF protocol.


>> and later the text says that it's "not limited
>> to just that protocol" (being BRSKI), but the general tone, and
>> specifically the Milestones, are very BRSKI-specific.
> 
> I would very much like to have more, but I don't know what the next steps for
> SZTP are.

Mapping to DTLS, CBOR, CoAP, and MUD would be a good milestones.  Unsure how many drafts that might entail.  Each topic is likely a small document, since it's mostly mapping onto other existing work.



> I actually rather believe that SZTP is probably a better starting point for a
> cloudless solution.
> If SZTP can do a better job for constrained environments, it is *precisely*
> this kind of stuff that I'd like to have in this group.

Yes, it would be good if this group could cast a wide net.



> I'm okay with the WG producing 3 or 4 mechanisms

Perfect.   Importantly, some of these mechanisms can be run in parallel, as they offer similar level of security, and hence a DoS doesn't result in a degradation attack.


> (and then, of course, an
> n+1th in four years to converge them, applying
> https://www.explainxkcd.com/wiki/index.php/927:_Standards)
> Some have attributed this method to Scott Bradner, imaging a meadow of
> many wild flowers.

Never heard the meadow part before, but the "wild" part seems apt.  ;)


Kent