Re: Request for Authenticated but not Encrypted Traffic

Eliot Lear <lear@lear.ch> Fri, 30 September 2022 09:49 UTC

Return-Path: <lear@lear.ch>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8730C157B39 for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 02:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1LpNsmSAMLg for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 02:49:07 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1254CC157B34 for <quic@ietf.org>; Fri, 30 Sep 2022 02:49:06 -0700 (PDT)
Received: from smtpclient.apple ([178.197.204.249]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPA id 28U9mwdK849611; Fri, 30 Sep 2022 11:48:58 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1664531339; bh=O+Cs8FF3wv61rlkI2KjRLRNmGVPoTZ9rPwFakuJ5CYA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=eyzJR/NhGEGVMXldhRpH9DqM1dQ+Lh3aWQySi9zBuSkPGyeecqg9izL+c7uPV1jSH jJ9z1GccrY7Dz+ZFdfxvkZPYmZup2+X9G7AyctlSS1/XzvTJl5UXJN7kQRcWzzoezw 3JvcXskTcnkahW749v7nZUFYdLJ0zIV1p8uZ5tt4=
Content-Type: multipart/alternative; boundary="Apple-Mail-B578B8E1-F863-4F36-8F08-D1B9E1117D93"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: Request for Authenticated but not Encrypted Traffic
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <SJ0PR08MB8288DD5A44F1E2259E01BA3FFA569@SJ0PR08MB8288.namprd08.prod.outlook.com>
Date: Fri, 30 Sep 2022 11:48:47 +0200
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, quic@ietf.org
Message-Id: <93C70EB8-EAB9-4394-8D9C-8E8EBDAF30F1@lear.ch>
References: <SJ0PR08MB8288DD5A44F1E2259E01BA3FFA569@SJ0PR08MB8288.namprd08.prod.outlook.com>
To: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>
X-Mailer: iPhone Mail (20A380)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/WcAL8rcsDqH0wtbGKP4I8C6J8cQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2022 09:49:15 -0000

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) <randy.armstrong@opcfoundation.org> wrote:
> 
> 
> The requirement is that factory owners need to use tools to monitor network traffic to detect anomalies.
>  
> From: Eliot Lear <lear@lear.ch> 
> Sent: Friday, September 30, 2022 5:44 PM
> To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>; Phillip Hallam-Baker <phill@hallambaker.com>
> Cc: quic@ietf.org
> 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.