RE: Request for Authenticated but not Encrypted Traffic

["Randy Armstrong (OPC)" <[e-mail]>]

  *   The problem being that a lot of systems depend on confidentiality of certain data to provide for integrity. Particularly to protect against replay attacks. So I don't think turning off encryption entirely is the right move.

When I talk of disabling encryption I am only talking about the messages sent using the session keys. Key negotiation could still be encrypted if needed for security.

I don’t understand the point about replay attacks. There are lots of ways to protect against replay without encrypting the message payload.


  *   A better approach for this particular requirement is to have a mechanism which uses encryption but explicitly provides the necessary observer decryption capabilities. But that approach has been repeatedly rejected in IETF.

I feel that putting backdoors into encryption protocols is a recipe for disaster. Encryption, once applied, should not be breakable or vulnerable to man-in-the-middle attacks. Applications should make the choice based on the tasks they need to do when a connection is established and have access to APIs that clearly tell them that they are using an unencrypted communication channel.

From: Phillip Hallam-Baker <[e-mail]>
Sent: Friday, September 30, 2022 11:51 AM
To: Randy Armstrong (OPC) <[e-mail]>
Cc: [e-mail]
Subject: Re: Request for Authenticated but not Encrypted Traffic

I see a requirement here being presented as an implementation.

The requirement is the ability of an authorized party within the network to observe network traffic for debugging purposes. That is a very normal requirement in process control. Process control networks are typically run in a fashion that most IETF-ers would find unusual. The networks are typically very quiet with absolutely no extraneous traffic. The traffic is typically unencrypted so that systems can be monitored continuously.

The overriding objective is to protect integrity and availability. Confidentiality is not (typically) considered a concern. The problem being that a lot of systems depend on confidentiality of certain data to provide for integrity. Particularly to protect against replay attacks. So I don't think turning off encryption entirely is the right move.

A better approach for this particular requirement is to have a mechanism which uses encryption but explicitly provides the necessary observer decryption capabilities. But that approach has been repeatedly rejected in IETF.



On Thu, Sep 29, 2022 at 8:31 AM Randy Armstrong (OPC) <[e-mail]<mailto:[e-mail]>> wrote:
The OPC Foundation is looking at deploying QUIC within factories as means for different OT devices to communicate with each other. In this environment, factory owners often wish to monitor traffic to check for anomalies. Encryption prevents this.

For this reason, an authentication only option is essential to making QUIC a viable choice for communication within factories.

Regards,

Randy Armstrong
OPC UA Security WG Chair