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

[Ben Schwartz <[e-mail]>]

Thanks for sharing your experience, Tommy.

On Thu, Apr 14, 2022 at 12:08 PM Tommy Pauly <tpauly=
[e-mail]> 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.
> - 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=[e-mail]> 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 <[e-mail]> 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/
>> .
>>
>> --Ben Schwartz
>>
>> ---------- Forwarded message ---------
>> From: <[e-mail]>
>> 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 <[e-mail]>
>>
>>
>>
>> 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
>>
>>
>> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>
>
>