Re: [Masque] Proposed draft charter

Paul Vixie <paul@redbarn.org> Mon, 27 January 2020 08:26 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7ED12011B for <masque@ietfa.amsl.com>; Mon, 27 Jan 2020 00:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2UorfYd1A3k for <masque@ietfa.amsl.com>; Mon, 27 Jan 2020 00:26:13 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2E512007C for <masque@ietf.org>; Mon, 27 Jan 2020 00:26:13 -0800 (PST)
Received: from linux-9daj.localnet (dhcp-157.access.rits.tisf.net [24.104.150.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1DAA2B0591 for <masque@ietf.org>; Mon, 27 Jan 2020 08:26:08 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: "masque@ietf.org" <masque@ietf.org>
Date: Mon, 27 Jan 2020 08:26:05 +0000
Message-ID: <1917123.yJOJJviVma@linux-9daj>
Organization: none
In-Reply-To: <B5A0CBC5-6127-4F47-B1CC-2BFF4934EA62@eggert.org>
References: <845946C2-EB98-4F3A-966E-968AE349302C@ericsson.com> <B5A0CBC5-6127-4F47-B1CC-2BFF4934EA62@eggert.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/FlznAunMbHFxUFZQJQk7MPsIue8>
Subject: Re: [Masque] Proposed draft charter
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2020 08:26:14 -0000

i mostly think the same, but i'm concerned about one aspect of H3 that may be 
sufficiently far from the core protocol to warrant special focus on the proxy, 
and that is the enterprise situation where the endpoint trusts the proxy to 
either carry the transaction for it, or to refer the endpoint to a native 
flow. use case, employee doing their banking from their corporate desktop 
during their lunch break. this isn't a well-loved scenario because it's so 
close to the nation-state authoritarian situation. but i'd like to explore it 
with a group of open minded others, and i think doing it inside the QUIC or 
HTTP WG would make for big distraction.

there is, separately and precedingly, the the process by which an endpoint 
would discover, and know whether or not to trust, an enterprise outbound 
proxy.

am i in the wrong basket?

vixie

re:

On Monday, 27 January 2020 07:22:14 UTC Lars Eggert wrote:
> Hi,
> 
> what motivates a separate WG vs. doing this in the QUIC WG?
> 
> There are aspects of the charter - e.g., one-sided (transparent to the
> peer?) cooperation with middleboxes, double-encryption avoidance (does this
> translated to an "unencrypted" mode for QUIC?) - that could have a large
> impact on the base protocol. That suggests to me tight coordination with
> the base protocol is essential.
> 
> Thanks,
> Lars

-- 
Paul