IETF Logo Mail Archive

Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 05 March 2022 19:44 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B663A0B0D; Sat, 5 Mar 2022 11:44:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 IAbYgFYyHTG5; Sat, 5 Mar 2022 11:43:59 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AEA3A0AFE; Sat, 5 Mar 2022 11:43:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 94A8538CA9; Sat, 5 Mar 2022 14:53:10 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j-ph8OPEw8Ps; Sat, 5 Mar 2022 14:53:09 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E3EED38CA8; Sat, 5 Mar 2022 14:53:08 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1646509988; bh=3B6Fj53Lm7D403dvp8pM2fc5zyjWXKpcasOuFBfUa4I=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=xNK9wtrkovnpLkGWfKnHPehl1N6vxoyHXHz5dvDFz5q/ZboCv2v3AoLEYR66HLJVS ioSP/oFIfL6B+ssfEjUNOEzKB24mSKIRX3zurbEXCJVZwDAIpq9vAze+mzTBdBZJb2 QQbeHnYdB/LZobeBEYh0c8h5KG7TeLYryXyM86mkNcOJck9aRVEaFvrvuchFpGPI8U pJFJhtZx4w5i52F2pC378KEqB83ASasbSyoebQzVtV42ie+UF5eUawPTmaTDGh51kb rRfy0aZjwvg0MRIl9nUM5FlOHdaNqQdG+962KWnSgmkMDdij2cIX8ub2N56k5lNwR3 CU1gmAfz15Sig==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8A2457CD; Sat, 5 Mar 2022 14:43:56 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "secdispatch@ietf.org" <secdispatch@ietf.org>, Jim Zubov <ietf-list@commercebyte.com>
cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "iotops@ietf.org" <iotops@ietf.org>, "anima@ietf.org" <anima@ietf.org>
In-Reply-To: <665685D3-B9AA-4A5E-B5B0-33D313A40716@commercebyte.com>
References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com>, <1865.1644434146@localhost> <E1nHwaz-0000LM-I5@ocean1.commercebyte.com> <4026.1644516168@localhost> <685366A1-01F4-4788-B025-0F5F4CE7947F@commercebyte.com> <DBBPR08MB591577EC79C3D11114AA747CFA3C9@DBBPR08MB5915.eurprd08.prod.outlook.com> <FC43EB7C-5ABF-4061-89BA-1503F0B6340D@commercebyte.com> <DBBPR08MB59159BFB36A926DA8E851723FA3D9@DBBPR08MB5915.eurprd08.prod.outlook.com> <665685D3-B9AA-4A5E-B5B0-33D313A40716@commercebyte.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 05 Mar 2022 14:43:56 -0500
Message-ID: <6296.1646509436@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/87DkBirFvH2Z2LF7D7mUoIgKfWI>
Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Mar 2022 19:44:05 -0000

Jim Zubov <ietf-list@commercebyte.com> wrote:
    > I just want to emphasize once again that the relay is end to end TLS.
    > There are some IoT management solutions on the market, both open source
    > and proprietary, but as far as I can tell none of them fully follows
    > the end to end paradigm. I believe it's worth having a universal
    > cross-vendor solution that handles SNIF device onboarding, maintains
    > the credentials in a local secure storage, and consolidates https based
    > management interface hosted by individual devices through SNIF.

Even if SNIF winds up "just" being a standardized way to call-home, I think
that has value.    I think that some text needs to be added contrasting SNIF
to UPnP and RFC6887 (Port Control Protocol).

What I haven't heard any comments in on the SECDISPATCH point of view about
what to do with this document.    Have the SECDISPATCH chairs put it on the
agenda, or is there any agreement that maybe IOTOPS should dispatch it?

Hannes: what do you think?


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email