Jack Visoky <jmvis...@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 l...@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 [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
