Re: Request for Authenticated but not Encrypted Traffic

Eliot Lear <lear@lear.ch> Fri, 30 September 2022 05:45 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 AF247C1524CE for <quic@ietfa.amsl.com>; Thu, 29 Sep 2022 22:45:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level:
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 m66cYI1qPFbJ for <quic@ietfa.amsl.com>; Thu, 29 Sep 2022 22:45:15 -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 36FB1C152586 for <quic@ietf.org>; Thu, 29 Sep 2022 22:45:13 -0700 (PDT)
Received: from [192.168.0.223] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 28U5j5Ub828776 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 30 Sep 2022 07:45:07 +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=1664516707; bh=7b8ASuMGNCuSVitbyhpf7EIMlM63WH+qo8cBY2MY2PU=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=N7YCijrUC8VCnJRRtOrG86VOdKLgTbUbZwB/JTb+MAOuJU6+vY9Ws7TqNjnFMN5FE PQkdbJtVWdHI6Re7EsPL2QTFzfjH1MCv3x9HF4blvUjMYhvpQiCTNndx54wgVruoEd 35TDxcerc8D26j59l+tpqdKLtly3zZc9lA7Pyk8c=
Message-ID: <da161bf2-2eea-77b9-c96f-e391fe867c3b@lear.ch>
Date: Fri, 30 Sep 2022 07:45:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.0
Content-Language: en-US
To: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>, Phillip Hallam-Baker <phill@hallambaker.com>
Cc: "quic@ietf.org" <quic@ietf.org>
References: <SJ0PR08MB82889F488CCA7D8FC4997ACEFA579@SJ0PR08MB8288.namprd08.prod.outlook.com> <CAMm+Lwh1DWyVNL7M6q0gAS77HyN5KXRa3cNn732ivbAMGSFVDg@mail.gmail.com> <SJ0PR08MB82888EE2140D219EF758CF76FA569@SJ0PR08MB8288.namprd08.prod.outlook.com>
From: Eliot Lear <lear@lear.ch>
Subject: Re: Request for Authenticated but not Encrypted Traffic
In-Reply-To: <SJ0PR08MB82888EE2140D219EF758CF76FA569@SJ0PR08MB8288.namprd08.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------Fuf2J64jdiIG4RZXCz7R0Ud0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/xr2Ly6knCalXgIpvD5uAtnKm_Fk>
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 05:45:19 -0000

On 30.09.22 05:56, Randy Armstrong (OPC) wrote:
>
>   * 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.
>
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.

Eliot