Hi Toerless, Just responding to one of your points, a colleague of mine from Cisco (Nancy Cam-Winget) and I have created a draft for authentication-only data protection for TLS 1.3. We've registered the cipher suites and will be going through the Independent Review for this RFC soon. If you, Michael, or even others would like to serve as reviewers we'd be grateful.
Link to RFC: https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-04 Thanks, --Jack -----Original Message----- From: Anima <anima-boun...@ietf.org> On Behalf Of Toerless Eckert Sent: Monday, August 12, 2019 2:50 PM To: Jack Visoky <jmvisoky=40ra.rockwell....@dmarc.ietf.org> Cc: Michael Richardson <mcr+i...@sandelman.ca>; Randy Armstrong (OPC) <randy.armstr...@opcfoundation.org>; anima@ietf.org; iot-onboard...@ietf.org Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI Agreeing to what Michael and you said, but also wanted to point out that TLS as defined by IETF is on a trajectory which may or may not be desirable for e.g.: industrial automation (where OPC is used) or other regulated/ critical environments. For example the total elimination of any non-encryption option in the TLS1.3 profile and the removal of the ability for passive observers to see the certificates exchanged impeeds severely on the ability to do passive diagnostics. I at least think there are good reasons to also have a strong and independent reviewed authentication scheme without encryption that can well be diagnosed by passive observers. Aspects like these are easily fixed IMHO by creating different profiles of TLS. Whether or not one could get such profiles through the TLS WG in the IETF is of course a different question given what seems to be a highly contentuous nature of the topic. There also seems to be a desire of areas of industrial automation to avoid the overhead of a perceived to be redundant network layer. This was a thing back in the days of OSI where TP4 was often run in factories without CLNS, and given how IP hasn't really improved on simplified, automated address management vs. L2 switched ethernet, this still seems to be a thing. Aka: Someone would need to define TLS on top of just ethernet instead of IP/IPv6. And there may be other similar L2 "transport" technologies where its not clear if simple ethernet mappings would suffice (bluetooth, wifi,...). Last but not least, QUIC is on a path to replace TLS and that too puts a dent into the belief that TLS as it stands would be a long term stable most-widely used protocol. Finally: There is something said to not simply trust a design like TLS which you do not really understand just because its widely used, and thus hopefully well reviewed, but rather make sure you have a design based on solid understanding of the cryptographic principles employed and a well defined review/control process of implementations. Incidents like with OpenSSL show how badly reviewed even the most widely deployed crypto mechanisms can be. Cheers Toerless On Sun, Aug 11, 2019 at 09:31:22PM +0000, Jack Visoky wrote: > > but there are significant benefits to not maintaining your own protocols, > > and significant benefits to getting the extensive review that TLS gets. > > I could not agree more with this statement. > > Thanks, > > --Jack > > > -----Original Message----- > From: Michael Richardson <mcr+i...@sandelman.ca> > Sent: Saturday, August 10, 2019 5:16 PM > To: Jack Visoky <jmvis...@ra.rockwell.com>; Randy Armstrong (OPC) > <randy.armstr...@opcfoundation.org>; iot-onboard...@ietf.org; > anima@ietf.org > Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI > > > 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 =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
