IETF Logo Mail Archive

Re: Request for Authenticated but not Encrypted Traffic

Lars Eggert <lars@eggert.org> Fri, 30 September 2022 10:39 UTC

Return-Path: <lars@eggert.org>
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 3A984C157B51 for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 03:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=eggert.org
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 O1ifg9l3byHz for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 03:39:33 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0BDC157B59 for <quic@ietf.org>; Fri, 30 Sep 2022 03:39:33 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:96d:7258:2b5c:bed0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 3F7D11DC8A4; Fri, 30 Sep 2022 13:39:23 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1664534363; bh=jqM2G3amsMsYE0zDx628xHQeolgBv1uQRBHQlXtGQfE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=wGH/yCqA7XmTMJz+lMjfTBLM/R0spKVtYUUM7Y92XoLHX+IIb1z3aYVzlnEQ87kK/ cCPXGdx9u2lwkHdTY8CNT7pz7vhk/sRQmvvydSMbpmhSBerV6nPKKiQUsGbAN6N104 X7vLiM+t3ZRHftG6laGXyn2W/vrVqXICKO3DKj2M=
Content-Type: multipart/signed; boundary="Apple-Mail=_351277E4-F17A-49D5-A266-D95A7E1B47AE"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: Request for Authenticated but not Encrypted Traffic
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <SJ0PR08MB82881B90F6E5B79F9CC56BD7FA569@SJ0PR08MB8288.namprd08.prod.outlook.com>
Date: Fri, 30 Sep 2022 13:39:23 +0300
Cc: Eliot Lear <lear@lear.ch>, Phillip Hallam-Baker <phill@hallambaker.com>, "quic@ietf.org" <quic@ietf.org>
Message-Id: <1CA45FF9-69A0-426D-B09A-F94F60990196@eggert.org>
References: <SJ0PR08MB8288DD5A44F1E2259E01BA3FFA569@SJ0PR08MB8288.namprd08.prod.outlook.com> <93C70EB8-EAB9-4394-8D9C-8E8EBDAF30F1@lear.ch> <SJ0PR08MB82881B90F6E5B79F9CC56BD7FA569@SJ0PR08MB8288.namprd08.prod.outlook.com>
To: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>
X-MailScanner-ID: 3F7D11DC8A4.A4153
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/j2KL3g_A7H4BKdwJA4otuQNnT34>
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 10:39:37 -0000

Hi,

thanks for describing scenarios!

On 2022-9-30, at 13:32, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> wrote:
> Scenario 1) A device with a trusted certificate is compromised and starts probing other devices in the network in ways that make no sense given its role.

This is detectable based on traffic matrix changes, even when all traffic is encrypted.

> Scenario 2) A connection from a device is established using a valid certificate that was not assigned to that device.

Certificates are typically tied to the identities of devices in ways that are verifiable.

> Scenario 3) A device is misconfigured and attempts a valid write to a PLC at a time when the configuration of the PLC should not be changing.

Could you explain what a PLC is?

Also, I don't understand how plaintext traffic would prevent writes at inopportune times?

Thanks,
Lars

v2.23.0 | Report a Bug | By Email