> 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).
The issue is more the additional libraries needed to support this functionality. For companies like Rockwell, which have heavily invested in CIP over TLS, these libraries are already there. For other big automation vendors this is not the case. > 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. OPC UA security is end to end security and not tied to specific transport which is preferable from an architecture perspective. While the wide use of TLS is an advantage and I can assure you that the OPC WGs have extensively debated the pros and cons of TLS vs an OPC specific mechanism before we got to where we are today. > 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. OPC also has ECDH based policies. These will be used by low end devices. The questions that the OPC WG needs to answer are: 1) Can BRSKI meet our requirements? 2) If the answer to 1) is yes then can it work with OPC UA security? 3) If the answer to 2) is no then do we use TLS or extend our own model with something like BRSKI but not BRSKI? While I cannot predict how the various participants in the OPC WGs will respond to question 3), I do know it would make collaboration a lot easier if the answer to 2) was yes. Regards, Randy -----Original Message----- From: Michael Richardson <[email protected]> Sent: August 10, 2019 2:16 PM To: Jack Visoky <[email protected]>; Randy Armstrong (OPC) <[email protected]>; [email protected]; [email protected] Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Jack Visoky <[email protected]> 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 [email protected]). 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 [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
