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

From: Ben Schwartz <[email-masked]>
Date: Thu, 7 Apr 2022 17:20:03 -0400

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/
.

--Ben Schwartz

---------- Forwarded message ---------
From: <[email-masked]>
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 <[email-masked]>

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
Status:
https://datatracker.ietf.org/doc/draft-schwartz-masque-access-descriptions/
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

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-
   descriptions/.

   Source for this draft and an issue tracker can be found at
   https://github.com/bemasc/access-services.

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 14 Apr 2022 11:19:12 -0400

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

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 14 Apr 2022 09:07:48 -0700

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=[email-masked]> 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.
> 
> - Should we have less flexibility (e.g. keeping all services on a single origin)?
> - Can we avoid, or at least separate out, the turing-complete expressiveness of PAC files?
> On Thu, Apr 7, 2022 at 5:20 PM Ben Schwartz <[email-masked] <mailto:[email-masked]>> 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
> 
> From: <[email-masked] <mailto:[email-masked]>>
> Subject: New Version Notification for draft-schwartz-masque-access-descriptions-00.txt
> To: Benjamin M. Schwartz <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> 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:
>    https://datatracker.ietf.org/doc/draft-schwartz-masque-access- <https://datatracker.ietf.org/doc/draft-schwartz-masque-access->
>    descriptions/.
> 
>    https://github.com/bemasc/access-services <https://github.com/bemasc/access-services>.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> -- 
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 14 Apr 2022 16:00:19 -0400

Thanks for sharing your experience, Tommy.

On Thu, Apr 14, 2022 at 12:08 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> 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.
>

I agree that DoH and MASQUE don't "necessarily" have any relation, but I do
think this will be a common and useful arrangement.  If you want to use
HTTPS records along with MASQUE, you need a DNS server.  It makes sense for
the MASQUE operator to offer clients a corresponding DNS server, to ensure
that they have one.  Otherwise, clients would have to choose a third-party
DNS resolver.  Some clients will be able to identify a suitable third-party
resolver automatically,  but many will not.

> 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).
>

Agreed, and that's what this draft offers.  (Except that it doesn't cover
CONNECT, because (1) that is already implicit in the relevant
configurations and (2) I would like a URI-template-driven "CONNECT-TCP" for
parallelism with MASQUE.)

> That may also be something you could just ask the proxy via some query.
>

I would argue that this is also a good description of the draft.

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.
> - 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=[email-masked]> wrote:
>
>> 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 +
>> ...).
>>