Re: [Masque] Proposed draft charter

Lars Eggert <lars@eggert.org> Mon, 27 January 2020 07:22 UTC

Return-Path: <lars@eggert.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 B48CD12010F for <masque@ietfa.amsl.com>; Sun, 26 Jan 2020 23:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 oVF8OaqbJXu7 for <masque@ietfa.amsl.com>; Sun, 26 Jan 2020 23:22:39 -0800 (PST)
Received: from vs21.mail.saunalahti.fi (vs21.mail.saunalahti.fi [193.64.193.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B9112008C for <masque@ietf.org>; Sun, 26 Jan 2020 23:22:39 -0800 (PST)
Received: from vs21.mail.saunalahti.fi (localhost [127.0.0.1]) by vs21.mail.saunalahti.fi (Postfix) with ESMTP id 589E82050D; Mon, 27 Jan 2020 09:22:37 +0200 (EET)
Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs21.mail.saunalahti.fi (Postfix) with ESMTP id 313372063C; Mon, 27 Jan 2020 09:22:25 +0200 (EET)
Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw03.mail.saunalahti.fi (Postfix) with ESMTPSA id E6F4520051; Mon, 27 Jan 2020 09:22:22 +0200 (EET)
Received: from stickers.eggert.org (Stickers.eggert.org [172.24.110.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 272196001DE; Mon, 27 Jan 2020 09:22:15 +0200 (EET)
From: Lars Eggert <lars@eggert.org>
Message-Id: <B5A0CBC5-6127-4F47-B1CC-2BFF4934EA62@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_D0EED9DF-FC7E-422C-990F-8138B97D6D8A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Mon, 27 Jan 2020 09:22:14 +0200
In-Reply-To: <845946C2-EB98-4F3A-966E-968AE349302C@ericsson.com>
Cc: "masque@ietf.org" <masque@ietf.org>
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>
References: <845946C2-EB98-4F3A-966E-968AE349302C@ericsson.com>
X-MailScanner-ID: 272196001DE.A5D9C
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/4fftHJaJ_Vv9JQCnsO6hRjdnUYo>
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 07:22:42 -0000

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

On 2020-1-25, at 1:29, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi everybody,
> 
> as already indicated by David in his last mail, some of us worked on a proposed draft charter for a new group. Please find the text below and provide comments!
> 
> Thanks!
> Mirja
> 
> ---------------------------------
> MASQUE draft charter text
> 
> 
> Many network topologies lead to situations where transport protocol proxying is beneficial. For example: helping endpoints to communicate when end-to-end connectivity is not possible, applying additional encryption where desirable (such as a VPN), or accommodating differences in network segment characteristics (e.g. long paths such as satellite, or high-loss links). Many existing proxy solutions deployed today rely on transparent intermediation. However, an increasing amount of traffic is using QUIC, and QUIC's improved security model prevents transparent proxies. In order to allow transport protocol proxying when QUIC is in use, we will need a mechanism where at least one of the QUIC endpoints actively collaborates with the proxy. QUIC is a good candidate protocols for tunneling or forwarding this kind of traffic, as QUIC provides secure connection establishment, multiplexed streams, and connection migration. Further, use of HTTP/3 on top of QUIC enables HTTP-level proxying and caching.
> 
> This working group will work on MASQUE (Multiplexed Application Substrate over QUIC Encryption) - a framework that allows concurrently running multiple networking applications inside a QUIC connection. The MASQUE framework will specify the actions and processes for establishing tunneled proxy connectivity as well as a signaling protocol that is used between the endpoint(s) and the MASQUE server to negotiate and request proxy service capabilities and parameters, and realize services that require communication between endpoints and proxies. A proxy may provide simple forwarding with optional address translation only, or more advanced services like name resolution, multipath support, or assistance for congestion control on link segments with challenging characteristics, such as high loss or strongly varying delays.
> 
> As use-cases for deploying MASQUE have different security or performance requirements, the working group may define multiple MASQUE services for proxying to suit these disparate use-cases. In particular, some deployments may want to avoid double-encryption to reduce computational costs if the inner connection as well as the outer QUIC tunnel connection use encryption, while others might prefer to keep the double-encryption of user data to sure strong privacy guarantees. Such options will need to produce documentation of the resulting security and privacy properties.
> 
> Alongside the definition of the MASQUE framework, the group will further work on discovery mechanisms for MASQUE servers and which MASQUE services they support, taking into account deployment across network segments with different operability and end-user relationship characteristics.
> 
> Proxy services that extend the signaling of the base MASQUE protocol can be adopted by the group by creating a new milestone with AD review.
> 
> If MASQUE requires any extensions to existing protocols, the group will coordinate closely with the respective group responsible for maintaining that protocol, such as the HTTPBIS, QUIC, or TLS working groups.
> 
> Milestones
> 
> July 2021 MASQUE framework and base protocol to be submitted to the IESG for publication as PS
> Nov 2021 Discovery mechanism for MASQUE servers to be submitted to the IESG for publication as PS
> Nov 2021 [Example WG Item] Use Case specific extension to the MASQUE protocol be submitted to the IESG for publication as EXP or PS
> 
> 
> 
> 
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque