-Original Message-
From: Iot-onboarding On Behalf Of Toerless
Eckert
Sent: 12 August 2019 19:50
To: Jack Visoky
Cc: Michael Richardson ; Randy Armstrong (OPC)
; anima@ietf.org; iot-onboard...@ietf.org
Subject: Re: [Iot-onboarding] [Anima] EXTERNAL: Re: 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.
[ofriel] Its more accurate to say that QUIC is going to replace TCP. QUIC will
be secured using TLS: https://tools.ietf.org/html/draft-ietf-quic-tls-22
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 +, 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
> Sent: Saturday, August 10, 2019 5:16 PM
> To: Jack Visoky ; Randy Armstrong (OPC)
> ; iot-onboard...@ietf.org;
> anima@ietf.org
> Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI
>
>
> Jack Visoky 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 unde
