Re: [Masque] Proposed draft charter

[Eric Rescorla <[e-mail]>]

Hi folks,

I have reviewed this charter and I fear that it is going in the wrong
direction. When MASQUE was first proposed, it was conceptually simple:
effectively an HTTP CONNECT tunnel but (1) Implemented over QUIC/H3
rather than H1/H2 (2) Allowing for non-TCP protocols to be carried
over the tunnel. IOW, it was an application-level VPN. This is
something that clearly has a number of valuable uses cases. To name
two real-world applications where this would be valuable:

1. Tor has repeatedly discussed converting from their TCP-based
   protocol to something DTLS or QUIC-like.

2. Firefox Private Network (https://fpn.firefox.com/) has an
   H2-based secure proxy mode, and running it over QUIC would
   have some obvious advantages.

However, when I read this charter, that simple application is sort of
buried under a bunch of other stuff that seems more appropriate for
some other use cases, such as performance-enhancing proxies. proxy
caches, etc. While I appreciate that something like tunnel (as in
FPN/Tor) and PEPs are both technically proxies, they're fundamentally
dissimilar even though they occupy the same position in the data
stream (though not the same position in the network, given that PEPs
are typically on-path between endpoints whereas tunnel-type systems
typically are not).

It's not necessarily bad to charter work that handles multiple use
cases, but in this case, I think that it would be a severe distraction
because the requirements are totally different. In the tunnel-type
case, the point of the proxy is to a great extent to protect
client-server connection from interference by the local network
(as well as to conceal the client/server IP addresses). However, in
the PEP style case, the purpose appears to be to reestablish the
control that these network-level devices had prior to the advent
of QUIC's end-to-end encryption. This is readily apparent from the
text in this proposed charter that says:

  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.

This actually seems like an understatement.

IMO, we should simply strike all these use cases and focus on a
simple tunnel protocol, which seems comparatively straightforward.
Such a protocol should be designed to be extensible.

In parallel, those who are interested in designing protocols to
re-establish access by network intermediaries can work on those
separately, and, if there is sufficient implementor interest we
can then discuss whether those use cases should be served by
Masque extensions or by some other protocol.

-Ekr