Re: [Iot-onboarding] EXTERNAL: Re: [Anima] OPC and BRSKI

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 10 August 2019 21:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 5E4DD120121; Sat, 10 Aug 2019 14:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fFEt5D9I6-Be; Sat, 10 Aug 2019 14:16:00 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274CC12007A; Sat, 10 Aug 2019 14:15:59 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E17F73818F; Sat, 10 Aug 2019 17:15:15 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8CA72C00; Sat, 10 Aug 2019 17:15:57 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jack Visoky <jmvisoky@ra.rockwell.com>, "Randy Armstrong \(OPC\)" <randy.armstrong@opcfoundation.org>, "iot-onboarding\@ietf.org" <iot-onboarding@ietf.org>, "anima\@ietf.org" <anima@ietf.org>
In-Reply-To: <DM5PR2201MB1340BD83D6CF3F95E82518C299D60@DM5PR2201MB1340.namprd22.prod.outlook.com>
References: <BYAPR08MB4903F02A37ED9AE092A59B8EFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <BYAPR08MB4903129ECDEADF61E681DE0BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <BYAPR08MB490385B1BED4C665C79B1937FAD70@BYAPR08MB4903.namprd08.prod.outlook.com> <4671.1565279232@localhost> <BYAPR08MB49034F3B36F6979D59561FC3FAD70@BYAPR08MB4903.namprd08.prod.outlook.com> <DM5PR2201MB1340BD83D6CF3F95E82518C299D60@DM5PR2201MB1340.namprd22.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256; protocol="application/pgp-signature"
Date: Sat, 10 Aug 2019 17:15:57 -0400
Message-ID: <19592.1565471757@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/qEfCdcKoP2inTanA4SSC-KIi9NA>
Subject: Re: [Iot-onboarding] EXTERNAL: Re: [Anima] OPC and BRSKI
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: Sat, 10 Aug 2019 21:16:02 -0000

Jack Visoky <jmvisoky@ra.rockwell.com>; wrote:
    > I am also involved with OPC-UA and would like to provide my/my
    > company's perspective.  One of the major drivers of this engagement
    > with the ANIMA group was a contentious point around whether or not TLS
    > and EST are required for support of BRSKI.  Some of us had taken the
    > position that these technologies are an integral part of BRSKI and
    > shouldn't be replaced with OPC specific methods, especially given the
    > benefit of using highly adopted security technologies, as well as the
    > tight coupling of BRSKI to these.  So, I think the idea that OPC should
    > just use these technologies is very much a viable answer.

If the device is powered or has enough battery to do 802.11, then it probably
has enough power and code space to do TLS (particularly mbedtls from ARM).
If it's on a very low duty cycle on battery, and/or it does 802.15.4, then
the question is still open.  The IETF may start work on a 802.15.4
specific AKE, (see lake@ietf.org).  We believe we need these for 6tisch
(TSCH mode of 802.15.4 for deterministic industrial networks)

It appears that the OPC UA methods provide enough security to do BRSKI,
but there are significant benefits to not maintaining your own protocols,
and significant benefits to getting the extensive review that TLS gets.

    > Also, I would strongly push back on any claims that low end OPC devices
    > cannot support TLS.  Other industrial protocols have already added TLS
    > support and are shipping products, including those with TLS client
    > functionality.  TLS is no more heavy-weight than existing, OPC-specific
    > security mechanisms.

The OPC-specific mechanism appears to avoid a DH operation and therefore
lacks PFS.  I understand it uses RSA, which means that it's significantly
more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have
hardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration.

    > In any event I will be sure to join the call that has been set up for
    > later in August.

Awesome.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-