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.
- Request for Authenticated but not Encrypted Traff… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Roberto Peon
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Salz, Rich
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- Re: Request for Authenticated but not Encrypted T… Martin Thomson
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Eliot Lear
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Carsten Bormann
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Carsten Bormann
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Eliot Lear
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Eliot Lear
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Lars Eggert
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Behcet Sarikaya
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Matt Joras
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Dave Taht
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- Re: Request for Authenticated but not Encrypted T… Christian Huitema
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Christian Huitema
- Re: Request for Authenticated but not Encrypted T… Christian Huitema
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Willy Tarreau
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- RE: Request for Authenticated but not Encrypted T… Antoine FRESSANCOURT
- Re: Request for Authenticated but not Encrypted T… Dirkjan Ochtman
- Re: Request for Authenticated but not Encrypted T… Behcet Sarikaya
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Martin Duke
- Re: Request for Authenticated but not Encrypted T… Michael Tuexen
- Re: Request for Authenticated but not Encrypted T… Roberto Peon
- Re: Request for Authenticated but not Encrypted T… Behcet Sarikaya
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Eliot Lear
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker