Re: Request for Authenticated but not Encrypted Traffic

Carsten Bormann <cabo@tzi.org> Fri, 30 September 2022 07:37 UTC

Return-Path: <cabo@tzi.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 33373C15257C for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 00:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 diYVn2M1zpei for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 00:37:54 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (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 C0467C1526F4 for <quic@ietf.org>; Fri, 30 Sep 2022 00:37:54 -0700 (PDT)
Received: from [192.168.217.124] (p5089abf5.dip0.t-ipconnect.de [80.137.171.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Mf2Bk5btNzDChc; Fri, 30 Sep 2022 09:37:50 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: Request for Authenticated but not Encrypted Traffic
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1b7329fd-d447-fb76-9d3c-4e09f58ee0f0@redbarn.org>
Date: Fri, 30 Sep 2022 09:37:50 +0200
Cc: "quic@ietf.org" <quic@ietf.org>
X-Mao-Original-Outgoing-Id: 686216270.405851-5b6641435090c7590eb3ece4f5133c4e
Content-Transfer-Encoding: quoted-printable
Message-Id: <18756B86-A5A9-4166-B5D1-8C26C0FA4371@tzi.org>
References: <SJ0PR08MB82889F488CCA7D8FC4997ACEFA579@SJ0PR08MB8288.namprd08.prod.outlook.com> <CAMm+Lwh1DWyVNL7M6q0gAS77HyN5KXRa3cNn732ivbAMGSFVDg@mail.gmail.com> <SJ0PR08MB82888EE2140D219EF758CF76FA569@SJ0PR08MB8288.namprd08.prod.outlook.com> <da161bf2-2eea-77b9-c96f-e391fe867c3b@lear.ch> <fb875699-312a-497d-0b5c-2da95b26268c@redbarn.org> <140CFDE5-B5AC-4342-8A5D-41D7EE92B43E@tzi.org> <1b7329fd-d447-fb76-9d3c-4e09f58ee0f0@redbarn.org>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/g7rTnekwHjF93YkUbBn4RIw2IgQ>
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 07:37:57 -0000

On 2022-09-30, at 09:25, Paul Vixie <paul@redbarn.org> wrote:
> 
> what did you have in mind as an example of this, that i might not dislike?

I think most people who run large (I)OT networks know about the
importance of Visibility, i.e., the need for actors that are not
immediate parties to the exchange of data to be aware of some of the
characteristics of that data.

The part I do not understand is why this is always framed in terms of
uncontrolled (unrestricted) visibility, i.e., everybody who manages to
get hold of a packet has full visibility.

(Well, I do understand that uncontrolled visibility (UC) is how
systems started to inspect traffic, and that today many of these
systems are addicted to uncontrolled visibility.)

Instead, I'd prefer to pursue something that I'd call Authorized
Visibility (AV).  Here, the communication actors explicitly provide
visibility to additional justified parties, not simply to any
eavesdropper that comes along.  This of course requires modelling the
additional justified parties, and to explicitly provide the
authorization (e.g., in terms of data structured to provide visibility
and the provision of access in terms of decryption keys), making it a
larger project than just breaking security for all.

Grüße, Carsten