[secdir] [new-work] WG Review: Multiplexed Application Substrate over QUIC Encryption (masque)
The IESG <iesg@ietf.org> Fri, 22 May 2020 18:14 UTC
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6693A0D4B; Fri, 22 May 2020 11:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1590171299; bh=7PrmU4QoMVcu9SmGfJ4BRjEou2xIY3l17RUAJrG2Qw8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=AXHe8YtKfB7dU9bMAOD/DdhvLL2qhiXaH3a11MVqVNF3zJYNvnkU4k7do3H1OcXAh vLr61whPMwRDk57OkB8bJTB3Ewlp7XozilGt7ePRtJrg1lVkDrfn+8tWTDHtp/Pazn Fx24pRTQtsnfo5gswf97z6ET/PXe/EEtv0ve3cXY=
X-Mailbox-Line: From new-work-bounces@ietf.org Fri May 22 11:14:52 2020
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D4E3A0D44; Fri, 22 May 2020 11:14:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1590171291; bh=7PrmU4QoMVcu9SmGfJ4BRjEou2xIY3l17RUAJrG2Qw8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=OSIqmSl6AllHdJFgjwS654UqBwgWNb2HpUE3A9ZC3I3mG9Jh9FCzlppka225RQYpE /kEPyjiyU45+6/h92AChLumGhSnLnLZ9PhZXvdmry8//m/EwSTa6BRhj53N5z2/ETb S2VpLE7QnjYdO7Z3M1BUZQlSGhFgH+WUIOEV85V0=
X-Original-To: new-work@ietf.org
Delivered-To: new-work@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C87C13A0D0B for <new-work@ietf.org>; Fri, 22 May 2020 11:14:41 -0700 (PDT)
MIME-Version: 1.0
From: The IESG <iesg@ietf.org>
To: new-work@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0
Reply_to: <iesg@ietf.org>
Message-ID: <159017128179.9391.3728952311424438613@ietfa.amsl.com>
Date: Fri, 22 May 2020 11:14:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/new-work/__xya7Tj9cLKY1G4xCnkyptDIPs>
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.29
Reply-To: iesg@ietf.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: new-work <new-work-bounces@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jSuzKFrshVsRAdAvfa7pIgIcWNk>
X-Mailman-Approved-At: Fri, 22 May 2020 18:29:59 -0700
Subject: [secdir] [new-work] WG Review: Multiplexed Application Substrate over QUIC Encryption (masque)
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2020 18:15:07 -0000
A new IETF WG has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-06-01. Multiplexed Application Substrate over QUIC Encryption (masque) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Christopher Wood <caw@heapingbits.net> Eric Kinnear <ekinnear@apple.com> Assigned Area Director: Martin Duke <martin.h.duke@gmail.com> Transport Area Directors: Magnus Westerlund <magnus.westerlund@ericsson.com> Martin Duke <martin.h.duke@gmail.com> Mailing list: Address: masque@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/masque Archive: https://mailarchive.ietf.org/arch/browse/masque/ Group page: https://datatracker.ietf.org/group/masque/ Charter: https://datatracker.ietf.org/doc/charter-ietf-masque/ Many network topologies lead to situations where transport protocol proxying is beneficial. For example, proxying enables endpoints to communicate when end-to-end connectivity is not possible and can apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client's IP address from a target server. Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT is currently limited to TCP. In contrast, HTTP/3 is a viable candidate protocol for proxying arbitrary traffic, as in a single connection it provides secure connectivity, multiplexed streams, migration, and a unified congestion controller. An HTTP/3 datagram construct built on top of QUIC datagram frames would provide for unreliable data transmission and enable transporting UDP and other unreliable flows via a proxy. Moreover, it would not introduce potentially redundant or unnecessary recovery mechanisms. Lastly, HTTP supports an established request/response semantic that can set up and configure flows for different services. The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTPS connection. These mechanism(s) are collectively called MASQUE. The group will specify HTTP and/or HTTP/3 extensions to enable this functionality. The group will focus on a limited set of client-initiated services: (1) UDP CONNECT and (2) IP proxying. Server-initiated services are out of scope. The working group will first deliver a protocol solution for UDP CONNECT and a requirements document for IP proxying. Once both are complete, the working group will focus on a protocol solution for IP proxying. The working group will consider fallback to versions of HTTPS that operate over TCP as a mitigation to UDP or HTTP/3 blocking. Moreover, the working group will consider implications of tunneling protocols with congestion control and loss recovery over MASQUE, and may issue recommendations accordingly. New congestion control and loss recovery algorithms are out of scope. Multicast support is out of scope. However, the group may specify extension points that would enable future work on multicast. Specifying proxy server discovery mechanisms is also out of scope. However, the group may consider features, such as proxy server identifiers, that aid future discovery mechanisms. Impacts on address migration, NAT rebinding, and future multipath mechanisms of QUIC are not anticipated. However, the working group should document these impacts, or those of any other QUIC developments, if they arise. The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with ICCRG and TSVWG on congestion control and loss recovery considerations. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work