Re: [Masque] New Version Notification for draft-schwartz-masque-access-descriptions-00.txt

Hi Ben,

Speaking from the experience we’ve had in actually configuring clients to use MASQUE, I agree that the right thing to do is to use a single URL to identify the proxy service that can support CONNECT/CONNECT-UDP/CONNECT-IP. It’s useful to be able to have other attributes configurable too, of course, such as keying material for authentication/pinning.

I don’t think that it makes sense to overload DoH into this directly. A proxy server doesn’t necessarily have any relation to a DoH server — you may access your DoH servers (or ODoH/OHTTP) servers through a proxy. Having a MASQUE proxy URL also be able to handle being an OHTTP/ODoH proxy is more useful, in my opinion, and is what we are currently doing.

To that end, it may be useful to have some markings to say what set of HTTP proxying protocols a proxy URL supports (CONNECT / CONNECT-UDP / CONNECT-IP / POST for oblivious). That may also be something you could just ask the proxy via some query.

To the other questions:
- Trying to express split tunnels sounds like the wrong thing — even a VPN config doesn’t generally tell you up front if it is full or split.
- Certainly we should avoid the complexity of PAC files!
- A proxy becomes a PvD in that it has a self-consistent way of accessing other hosts; the question is if we have a way to access it’s broader metadata, which may that way to query properties I mentioned above.

Best,
Tommy

> On Apr 14, 2022, at 8:19 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> In the interest of stimulating discussion, the key question for this draft is: how does one configure a client to use MASQUE?  I would like the answer to be "copy a single URL into a field on the settings page".  The question then becomes: what does this URL need to convey?  I think it needs to convey both CONNECT-UDP and CONNECT-IP (in case the client only supports one or the other), DoH (to ensure that DNS queries get the same treatment as other network traffic), and possibly other proxy-like services as they are  invented.
> 
> There are many interesting open questions here:
> - Should we have less flexibility (e.g. keeping all services on a single origin)?
> - Do we need more flexibility, to express things like split tunnels?
> - Can we avoid, or at least separate out, the turing-complete expressiveness of PAC files?
> - Should this somehow integrate with the Provisioning Domain (PvD) concepts?
> 
> Please review,
> Ben Schwartz
> 
> On Thu, Apr 7, 2022 at 5:20 PM Ben Schwartz <bemasc@google.com <mailto:bemasc@google.com>> wrote:
> Hi MASQUE,
> 
> I've written a very short draft that describes how to find a MASQUE server if (1) you're starting with an HTTP CONNECT proxy or (2) you want to use multiple services in combination (e.g. CONNECT-UDP + CONNECT-IP + DoH + ...).
> 
> This design can also serve as a building block for a solution to the key consistency problem in Oblivious HTTP, which I've written up separately: https://datatracker.ietf.org/doc/draft-schwartz-ohai-consistency-doublecheck/ <https://datatracker.ietf.org/doc/draft-schwartz-ohai-consistency-doublecheck/>.
> 
> --Ben Schwartz
> 
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> Date: Thu, Apr 7, 2022 at 4:20 PM
> Subject: New Version Notification for draft-schwartz-masque-access-descriptions-00.txt
> To: Benjamin M. Schwartz <bemasc@google.com <mailto:bemasc@google.com>>
> 
> 
> 
> A new version of I-D, draft-schwartz-masque-access-descriptions-00.txt
> has been successfully submitted by Benjamin Schwartz and posted to the
> IETF repository.
> 
> Name:           draft-schwartz-masque-access-descriptions
> Revision:       00
> Title:          HTTP Access Service Description Objects
> Document date:  2022-04-07
> Group:          Individual Submission
> Pages:          6
> URL:            https://www.ietf.org/archive/id/draft-schwartz-masque-access-descriptions-00.txt <https://www.ietf.org/archive/id/draft-schwartz-masque-access-descriptions-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-schwartz-masque-access-descriptions/ <https://datatracker.ietf.org/doc/draft-schwartz-masque-access-descriptions/>
> Html:           https://www.ietf.org/archive/id/draft-schwartz-masque-access-descriptions-00.html <https://www.ietf.org/archive/id/draft-schwartz-masque-access-descriptions-00.html>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-schwartz-masque-access-descriptions <https://datatracker.ietf.org/doc/html/draft-schwartz-masque-access-descriptions>
> 
> 
> Abstract:
>    HTTP proxies can operate several different kinds of access services.
>    This specification provides a format for identifying a collection of
>    such services.
> 
> About This Document
> 
>    This note is to be removed before publishing as an RFC.
> 
>    Status information for this document may be found at
>    https://datatracker.ietf.org/doc/draft-schwartz-masque-access- <https://datatracker.ietf.org/doc/draft-schwartz-masque-access->
>    descriptions/.
> 
>    Source for this draft and an issue tracker can be found at
>    https://github.com/bemasc/access-services <https://github.com/bemasc/access-services>.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> -- 
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque