Re: Request for Authenticated but not Encrypted Traffic

Paul Vixie <paul@redbarn.org> Sat, 01 October 2022 07:37 UTC

Return-Path: <paul@redbarn.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 349FFC1522A9 for <quic@ietfa.amsl.com>; Sat, 1 Oct 2022 00:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=redbarn.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 L1XYhwoD49e5 for <quic@ietfa.amsl.com>; Sat, 1 Oct 2022 00:37:43 -0700 (PDT)
Received: from util.redbarn.org (util.redbarn.org [24.104.150.222]) (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 581A2C1522A0 for <quic@ietf.org>; Sat, 1 Oct 2022 00:37:43 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 0096C167A42; Sat, 1 Oct 2022 07:37:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1664609863; bh=kd1//VF3ZXH3lJFwDmhKQohi+zMH4DktfNJ2AnWJ29Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=qGxk80LFIHqaGKr+VyUFzx4Vq9rlcGaAFup3mV1qkkpBaezQVc3K00UR55D/Ji0qZ XBvBPhKrU4LH3Agwb3F7l5R2HRMbGy6GQHK2uiNZq8h+nI/O2+h2cvSfSZNvoquR3E 8JjqnKTOR199dwMzhdFDR9P7Vh4efZlEZVtqPtZ0=
Received: from [24.104.150.175] (dhcp-175.access.rits.tisf.net [24.104.150.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D5648C3FCF; Sat, 1 Oct 2022 07:37:42 +0000 (UTC)
Subject: Re: Request for Authenticated but not Encrypted Traffic
To: Lucas Pardue <lucaspardue.24.7@gmail.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> <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> <18756B86-A5A9-4166-B5D1-8C26C0FA4371@tzi.org> <5b02b637-c005-1414-cd0a-117fa74e55ee@redbarn.org> <CALGR9obigX=_S1Oi26MNZ1EBLkPt=X-W5uFA3D8wu9ZaA1D7xQ@mail.gmail.com>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <f44e6fbf-8cfa-0867-1d73-414d124349a2@redbarn.org>
Date: Sat, 01 Oct 2022 00:37:41 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.57
MIME-Version: 1.0
In-Reply-To: <CALGR9obigX=_S1Oi26MNZ1EBLkPt=X-W5uFA3D8wu9ZaA1D7xQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rxDaOuqakDI-6xNFOMVF5F341AY>
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: Sat, 01 Oct 2022 07:37:47 -0000


Lucas Pardue wrote on 2022-09-30 10:03:
> Hi,
> 
> On Fri, Sep 30, 2022 at 5:51 PM Paul Vixie 
> <paul=40redbarn.org@dmarc.ietf.org 
> <mailto:40redbarn.org@dmarc.ietf.org>> wrote:
> 
>     > ...
> 
>     i'd be fine with this, as long as it was possible for my gateway to
>     determine at line rate whether each packet trying to get through was
>     participating in the Authorized Visibility regime you're describing.
> 
> The action seems pretty trivial for QUIC. Endpoints share with trusted 
> parties (e.g. a gateway) the TLS session keys and how they are 
> associated with one or more QUIC connection IDs.

i'm pretty sure the chromecast i evicted won't be willing to do that. it 
ignored my DHCP assignment of DNS, and insisted on using 8.8.8.8, so i 
think google now believes "our device, our rules" which is in stark 
opposition to what i believe ("my network, my rules"). just sayin', but, 
this should also help explain why i want to observe the devices on my 
network and be sure i approve of what they are doing.

> Then it's a simple 
> lookup when a packet arrives. If there's no match then, log, alert, drop 
> etc. We might debate about packet decryption performance, i'm not sure 
> how much margin you have on line rate or how much processing time you 
> are willing to throw at it.

as a rule, observation is harder than reception. decryption performance 
is probably where the issues would be. if we can't decrypt all the flows 
as fast as the endpoints of each flow can collectively do, we lose. it's 
reasonable to do this for all the flows that will fit in 10GBE with 
current hardware, but that's a harsh mistress in several likely futures. 
an intended receiver has the advantage of being able to slow the sender 
down by not answering often enough or soon enough. an observer cannot.

> On my local machine, Wireshark can do these kinds of lookups via 
> SSLKEYLOGFILE files. It would require effort to build a distributed 
> system to achieve the same but the technical barriers seem low and solvable.

thanks for sharing your experiences. but so far i think i'm going to 
have to force the use of a proxy, which will be an intended recipient, 
for the reasons given above.

-- 
P Vixie