Re: [Masque] Updated proposed charter text

Hi Chris,

My only feedback is that it would be good to be a bit more crisp about deliverables -- the "such as" in "such as IP, UDP, and TCP proxying" makes me nervous.

Cheers,

> On 1 Apr 2020, at 3:42 am, Christopher Wood <caw@heapingbits.net> wrote:
> 
> Based on last week's meeting, it seems folks are generally enthusiastic about some form of MASQUE moving forward. To help scope that particular form, here's an update to the proposed charter. 
> 
> ~~~
> 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 it provides secure connectivity, multiplexed streams, and migration for a single connection while taking advantage of a unified congestion controller. HTTP/3 datagrams provide for unreliable data transmission, which enables transporting UDP and other unreliable flows via a proxy without introducing potentially redundant or unnecessary recovery mechanisms. Further, HTTP/3 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 mechanisms that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside a HTTP/3 connection. The group will specify an HTTP-based signaling protocol for creating and configuring each service flow. The group will first focus on a limited set of client-initiated services such as IP, UDP, and TCP proxying. Specifying proxy server discovery mechanisms is out of scope for the group. However, the group may specify techniques for identifying proxy servers to aid future discovery mechanisms.
> 
> The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS.
> ~~~
> 
> This should address most of the issues raised during the meeting [1]. We'd like to hear what people think about this as a viable path forward.
> 
> Thanks,
> Chris, on behalf of the chairs
> 
> [1] These issues include, though are not limited to:
> 
> 1. Whether or not this is a new protocol or an extension of an existing protocol must be clear before moving forward.
> 2. Motivation for proxy technologies requires improvement. In particular, there’s no mention of privacy objectives.
> 3. The proxy threat model is unclear or underspecified. Does it model Tor’s threat model, or is it something simpler? (Meta question: should this be part of an existing document?)
> 4. Why are services beyond simple “CONNECT for UDP or IP” in scope? Should we focus on the simple datagram proxy case first and carve out room for extensibility?
> 5. To what extent is discovery out of scope?
> 6. Framework is perhaps not the best word to describe MASQUE.
> 
> Any errors or omissions from this list are entirely my fault!
> 
> -- 
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque

--
Mark Nottingham   https://www.mnot.net/