Ok. So a bit more detail, please. For example, people are suggesting that clients report keys to authorized parties. This is a no-code solution from a standards perspective. But does it meet your members’ needs in terms of monitoring, auditing, etc? If not why not? For instance, what happens if one end is hacked? Could it report incorrect keys that would be spotted in a timely fashion?
Eliot > On 30 Sep 2022, at 11:37, Randy Armstrong (OPC) > <[email protected]> wrote: > > > The requirement is that factory owners need to use tools to monitor network > traffic to detect anomalies. > > From: Eliot Lear <[email protected]> > Sent: Friday, September 30, 2022 5:44 PM > To: Randy Armstrong (OPC) <[email protected]>; Phillip > Hallam-Baker <[email protected]> > Cc: [email protected] > Subject: Re: Request for Authenticated but not Encrypted Traffic > > Randy, > > I'm not discussing backdoors, but requirements. State your requirements. > > Eliot > > On 30.09.22 10:38, Randy Armstrong (OPC) wrote: > I think the key point here is that sometimes observability is a feature and > not a bug. This is particularly important in industrial/critical > infrastructure. That observability can be achieved in many ways. One > question is whether the observability itself should itself be authorized. > Putting backdoors into protocols is not equivalent to letting applications > decide to skip encryption. > > A backdoor is like giving law enforcement codes to break into a cellphone and > hoping that they will never abuse the power or the codes will never fall into > the hands of criminals. Letting applications decide is equivalent to an owner > of a cellphone choosing not to lock their screen because they decide there is > nothing that needs protecting. > > IOW, the fact that some users might be willing to live with the risk of a > compromised system by allowing for backdoors is not a reason to refuse to > allow other users to make a decision send data in clear text when and only > when they decide it is safe.
