Subject: Re: [Masque] Updated proposed charter text

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Apr 2020 13:35:13 +1100

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque

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

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 02 Apr 2020 07:01:53 -0700

On Tue, Mar 31, 2020, at 4:34 PM, Spencer Dawkins at IETF wrote:
> Hi, Christopher, 
> 
> Thanks for getting this update out so quickly. 
> 
> I have thoughts, but wanted to start with the first couple of paragraphs. 
> 
> On Tue, Mar 31, 2020 at 11:43 AM Christopher Wood <[email-masked]> wrote:
> If I remember correctly, somewhere between the audio conference and the 
> active jabber conversation, there were people who mentioned
>  * proxies
>  * relays
>  * tunnels
>  * VPNs
>  * NATs, and 
>  * now that I look at the second paragraph, maybe even firewalls
> Is it possible to agree on the functionalities that this community of 
> interest is thinking of, as part of the charter discussion? 
>
> ISTM that if we're talking about "connect for IP", we're closer to a 
> tunnel than a proxy, and I don't think that's what most of the MASQUE 
> folk were thinking of. 
>
> Perhaps this will fall out of the use cases people have been collecting?

Yep, I expect that to be the case! While the use cases in the charter are not meant to be exhaustive, more specificity would probably help frame the rest of the content. 

Meta question: are you looking for a specific change in the text, and if so, what might that be?

Best,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 02 Apr 2020 07:04:59 -0700

On Wed, Apr 1, 2020, at 7:35 PM, Mark Nottingham wrote:
> 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.

Thanks for the feedback, Mark! 

While I don't share your nervousness here, I'm also not opposed to the change. What do others think?

Best,
Chris

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Apr 2020 07:09:04 -0700

I don't think the diversity of naming here is that useful as a guide to the
diversity of the use cases. For instance, 2817, which defines CONNECT uses
the term both "proxy" and "tunnel" in the same sentence.

"A CONNECT method requests that a proxy establish a tunnel connection on
its behalf."

And yet TURN, which provides a similar service, calls itself "Traversal
Using Relays around NAT".

As a practical matter, the TCP and UDP use cases focus on establishing an
association with the server in which packets are forwarded to and from a
given destination and the IP use case seems to focus on forwarding IP
datagrams from the client to and from arbitrary destinations (this last
might use some fleshing out, I suppose).

-Ekr

On Thu, Apr 2, 2020 at 7:03 AM Christopher Wood <[email-masked]> 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.
> >
> Yep, I expect that to be the case! While the use cases in the charter are
> not meant to be exhaustive, more specificity would probably help frame the
> rest of the content.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 2 Apr 2020 10:34:25 -0500

Replying to Chris via Ekr's reply to me :-)

On Thu, Apr 2, 2020 at 9:09 AM Eric Rescorla <[email-masked]> wrote:

> I don't think the diversity of naming here is that useful as a guide to
> the diversity of the use cases. For instance, 2817, which defines CONNECT
> uses the term both "proxy" and "tunnel" in the same sentence.
>

This is the kind of thing I was also thinking about - not that we weren't
using the right terms, but that we were vague enough that people during the
BOF were guessing at what MASQUE would be most like (
https://en.wikipedia.org/wiki/Blind_men_and_an_elephant). So, yes, fleshing
out what we expect to happen, and not to happen, makes sense to me.

Just to start where Ekr started, do people think we're forwarding to
arbitrary destinations, or only to destinations that were explicitly set up?

Best,

Spencer

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Apr 2020 10:32:24 -0700

On Thu, Apr 2, 2020 at 8:34 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> https://en.wikipedia.org/wiki/Blind_men_and_an_elephant). So, yes,
> fleshing out what we expect to happen, and not to happen, makes sense to
> me.
>

I think it depends on the protocol.

- For TCP you can only really forward to destinations that were explicitly
set up
- For UDP you could in principle forward to arbitrary destinations but the
return path is problematic (you need the server to be a stateful NAT) so
explicitly set up seems better
- For IP I understand that what people want is arbitrary destinations in
both directions, which is the source of the additional complexity

-Ekr

>>> Yep, I expect that to be the case! While the use cases in the charter
>>> are not meant to be exhaustive, more specificity would probably help frame
>>> the rest of the content.
>>>

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Thu, 2 Apr 2020 15:40:46 -0400

On Thu, Apr 2, 2020 at 11:36 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> What does "arbitrary destinations" mean here? For QBONE, we have built the
ability to route between networks, including setting a default that can be
for reaching the public internet. Is that arbitrary, or is that a
destination that was explicitly set up because a route was configured? I'm
not sure I understand the implication of the distinction.

Sincerely,
-Alex

Best,

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Apr 2020 13:26:06 -0700

On Thu, Apr 2, 2020 at 12:40 PM Alex Chernyakhovsky <[email-masked]>
wrote:

>>> As a practical matter, the TCP and UDP use cases focus on establishing
>>> an association with the server in which packets are forwarded to and from a
>> What does "arbitrary destinations" mean here? For QBONE, we have built
> the ability to route between networks, including setting a default that can
> be for reaching the public internet. Is that arbitrary, or is that a

So, you have a tunnel between point A and point B.

In TCP CONNECT (and hypothetically UDP CONNECT) you set up an association
to a given destination. You then inject datagrams labelled with the
association ID and it gets routed to that destination and packets in the
return direction get labelled with the same association ID on the way to
the client. Incoming messages not coming from any association are discarded.

In a pure IP VPN, there aren't any destination associations and packets
just get routed based on the IP header in both directions, regardless of
what state has been created. Note that a TURN relay occupies a sort of
intermediate state where associations are implicitly created and destroyed.

-Ekr

>>>> > >  Many network topologies lead to situations where transport
>>>> protocol proxying is beneficial. For example, proxying enables endpoints to

---

From: Marcus Ihlar <[email-masked]>
Date: Fri, 3 Apr 2020 13:06:08 +0000

Hi,
The previous charter proposal, shown in the BoF slides, refers to using QUIC as a candidate protocol for proxying traffic.
In the text you propose below, all mentions of QUIC are replaced with HTTP/3.
I'm afraid that specifying that HTTP/3 should serve as the substrate for the proxied traffic at this point will limit the possible solutions the working group can consider. Using the word QUIC instead of HTTP/3 in the charter text would allow the wg to consider a broader solution space, including something based on HTTP/3.

Marcus

-----Original Message-----
From: Masque <[email-masked]> On Behalf Of Christopher Wood
Sent: den 31 mars 2020 18:43
To: [email-masked]
Subject: [Masque] Updated proposed charter text

~~~

Thanks,

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?

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Fri, 3 Apr 2020 09:17:36 -0400

On Thu, Apr 2, 2020 at 4:26 PM Eric Rescorla <[email-masked]> wrote:

>>>> "A CONNECT method requests that a proxy establish a tunnel connection
>>>> on its behalf."
>>>>
>>> This is the kind of thing I was also thinking about - not that we
>>> weren't using the right terms, but that we were vague enough that people
>>> during the BOF were guessing at what MASQUE would be most like (
> I don't think this is a meaningful distinction. If I understand correctly,
you're identifying that CONNECT is actually two actions that have to happen
in sequence: establish a tunnel to some destination, then relay bytes to
that destination. The first step allows you to connect to arbitrary
destinations, unless you have some sort of firewall or ACL system to limit
the scope.

You can do the same with a VPN, you just need to have connection tracking
implemented in the VPN terminator. The only real difference I see here is
with a traditional TCP connection, you can't avoid having the connection
state, as that's inherent to the protocol, whereas with a VPN one could
choose to not implement connection tracking and therefore not have an easy
filtering capability. (You could, of course, use stateless firewall rules,
even without changing the VPN terminator implementation and relying on the
OS native features).

Sincerely,
-Alex

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 Apr 2020 12:11:52 +1000

On Sat, Apr 4, 2020, at 00:17, Alex Chernyakhovsky wrote:
> I don't think this is a meaningful distinction. If I understand 
> correctly, you're identifying that CONNECT is actually two actions that 
> have to happen in sequence: establish a tunnel to some destination, 
> then relay bytes to that destination. The first step allows you to 
> connect to arbitrary destinations, unless you have some sort of 
> firewall or ACL system to limit the scope.

I think that this has less to do with the arbitrariness than it has to do with what level of prearrangement.

When I send an IP packet, I might set an arbitrary source and destination address.  The forwarding entity probably needs to have the source address prearranged or bad things happen.  But it might be happy to allow a range of different addresses to be used.  For destination addresses, the level of predetermination is something we could decide is attached to every unit of communication.  Or it might require that every possible destination be prearranged.

An advantage of prearrangement is that you can create a context and compress, reducing or maybe even reversing the overhead of tunneling.  And servers get a clearer channel for expressing their policy constraints.  The disadvantage is that you pay a round trip for the setup, and maybe the tunneling protocol pays in complexity for that ability to be expressive.

What we see with CONNECT is that the destination is prearranged.  The headers on CONNECT are that prearrangement.  That simplifies operation a great deal as the client doesn't have to provide TCP or IP headers on every frame it sends.  The round trip is parallel with the TCP socket establishment from proxy to server, so the latency hit is negligible; more so because clients can send a TLS ClientHello without waiting for the outcome of the CONNECT request.
 
> You can do the same with a VPN, you just need to have connection 
> tracking implemented in the VPN terminator. The only real difference I 
> see here is with a traditional TCP connection, you can't avoid having 
> the connection state, as that's inherent to the protocol, whereas with 
> a VPN one could choose to not implement connection tracking and 
> therefore not have an easy filtering capability. (You could, of course, 
> use stateless firewall rules, even without changing the VPN terminator 
> implementation and relying on the OS native features).

Whatever happens here, we will need to encode some of these assumptions either into limitations of a protocol specification, or as protocol elements that are signaled or negotiated.

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 06 Apr 2020 06:42:39 -0700

Hi Marcus,

For what it's worth, this change reflects the mechanism currently proposed in [1]. This seemed to have some measure of rough consensus based on comments we (chairs) heard before, during, and after the meeting. There are of course pros and cons with this change, e.g., it can re-use existing machinery (pro!), but that machinery might not always exist or can be too complex (con!).

Best,
Chris

[1] https://tools.ietf.org/html/draft-schinazi-masque-protocol-01

On Fri, Apr 3, 2020, at 6:06 AM, Marcus Ihlar wrote:
> Hi,
> The previous charter proposal, shown in the BoF slides, refers to using 
> QUIC as a candidate protocol for proxying traffic.
> I'm afraid that specifying that HTTP/3 should serve as the substrate 
> for the proxied traffic at this point will limit the possible solutions 
> the working group can consider. Using the word QUIC instead of HTTP/3 
> in the charter text would allow the wg to consider a broader solution 
> space, including something based on HTTP/3.
> 
> Marcus
> 
> 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.
> 
> ~~~
> 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.
> 
> 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 
> 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,
> 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?

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 6 Apr 2020 15:43:29 +0000

Hi Chris,

In draft-schinazi-masque-protocol I would say that the QUIC, UDP, and IP proxying services run directly on top of QUIC without any HTTP in between (HTTP is only used only for the negotiation part but not for the forwarding/multiplexing). Therefore I think it would be more correct to actually change this one occurrence of HTTP3 back to  QUIC in the following sentence:

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

Mirja

On 06.04.20, 15:43, "Masque on behalf of Christopher Wood" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Marcus,

    Best,
    Chris

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Apr 2020 08:47:26 -0700

On Mon, Apr 6, 2020 at 8:43 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> Hi Chris,
>
> In draft-schinazi-masque-protocol I would say that the QUIC, UDP, and IP
> proxying services run directly on top of QUIC without any HTTP in between
> (HTTP is only used only for the negotiation part but not for the
> forwarding/multiplexing).

Philosophy aside, do we agree that these messages would be carried in QUIC
Datagram frames (https://tools.ietf.org/html/draft-ietf-quic-datagram-00)?

Therefore I think it would be more correct to actually change this one
> occurrence of HTTP3 back to  QUIC in the following sentence:
>
> "The primary goal of this working group is to develop mechanisms that
> datagram-based flows inside a HTTP/3 connection"
>

I'm not sure that this is right. If you use the H3 ALPN token and then use
H3 to negotiate but also negotiate datagram, this seems like an H3
connection to me.

-Ekr

Mirja
>
>
>
>
>
> On 06.04.20, 15:43, "Masque on behalf of Christopher Wood" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi Marcus,
>
>     For what it's worth, this change reflects the mechanism currently
> proposed in [1]. This seemed to have some measure of rough consensus based
> on comments we (chairs) heard before, during, and after the meeting. There
> are of course pros and cons with this change, e.g., it can re-use existing
> machinery (pro!), but that machinery might not always exist or can be too
> complex (con!).
>
>     Best,
>     Chris
>
>     > In the text you propose below, all mentions of QUIC are replaced
> with
>     > HTTP/3.
> enthusiastic
> albeit

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 6 Apr 2020 16:58:52 +0100

> H3 to negotiate but also negotiate datagram, this seems like an H3
I would find using "QUIC" in place of "HTTP/3" confusing. QUIC requires an
authenticated negotiation of the application protocol and we use ALPN for
that today. There is no mechanism to my knowledge that would allow the
creation of just a QUIC connection, and I don't even think MASQUE requires
that.

IMO it be more accurate for us to say, "The primary goal of this working
group is to develop HTTP mechanisms that allow configuration of QUIC
transport features inside an HTTP/3 connection, with the aim to
concurrently run multiple proxied stream- and datagram-based flows."

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Apr 2020 10:03:31 -0700

On Mon, Apr 6, 2020 at 8:59 AM Lucas Pardue <[email-masked]>
wrote:

> QUIC requires an authenticated negotiation of the application protocol and
> we use ALPN for that today. There is no mechanism to my knowledge that
> would allow the creation of just a QUIC connection, and I don't even think
> MASQUE requires that.
>

If I am reading RFC 7301 correctly, the way to do that would be register an
appropriate protocol identifier, which specifically disclaimed it being an
application identifiable by the QUIC-layer protocol machinery.  The MIME
Media Type parallel would be application/octet-stream.

Including such a thing in the set of supported protocols would have all of
the problems previous identified, so this is hardly going to solve MASQUE's
problem, but we should note that it is not impossible and that there may
arise some need for this at a later time.

regards,

Ted Hardie

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 6 Apr 2020 17:24:44 +0000

Hi Lucas, hi Ekr,

see inline.

From: Lucas Pardue <[email-masked]>
Date: Monday, 6. April 2020 at 17:59
To: Eric Rescorla <[email-masked]>
Cc: Mirja Kuehlewind <[email-masked]>, Christopher Wood <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Masque] Updated proposed charter text

On Mon, Apr 6, 2020 at 4:48 PM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Apr 6, 2020 at 8:43 AM Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc..ietf.org<mailto:[email-masked]>> wrote:
Hi Chris,

In draft-schinazi-masque-protocol I would say that the QUIC, UDP, and IP proxying services run directly on top of QUIC without any HTTP in between (HTTP is only used only for the negotiation part but not for the forwarding/multiplexing).

Philosophy aside, do we agree that these messages would be carried in QUIC Datagram frames (https://tools.ietf.org/html/draft-ietf-quic-datagram-00)?

[MK] Yes, for datagram-based flows. And QUIC stream frames for stream-based flows.

Therefore I think it would be more correct to actually change this one occurrence of HTTP3 back to  QUIC in the following sentence:

I'm not sure that this is right. If you use the H3 ALPN token and then use H3 to negotiate but also negotiate datagram, this seems like an H3 connection to me.

[MK] I guess it gets a bit philosophical now: If we would have an own ALPN token for masque (which is reasonable for some use cases) but still use the HTTP-based scheme as proposed in draft-schinazi-masque-protocol by POSTing for configuration parameters, would that still be H3?

[MK] I mean I think we are aligned here what we want. I just don’t want to be over-restrictive in the charter by calling it there a H3 connection while calling it a QUIC connection would be fine as well.

-Ekr

I would find using "QUIC" in place of "HTTP/3" confusing. QUIC requires an authenticated negotiation of the application protocol and we use ALPN for that today. There is no mechanism to my knowledge that would allow the creation of just a QUIC connection, and I don't even think MASQUE requires that.

IMO it be more accurate for us to say, "The primary goal of this working group is to develop HTTP mechanisms that allow configuration of QUIC transport features inside an HTTP/3 connection, with the aim to concurrently run multiple proxied stream- and datagram-based flows."

[MK] I think we need more than just “configuration of QUIC transport features“ as the forwarding part itself and any operations needed for the forwarding part e.g. address translation or some kind of header compression are not a QUIC transport feature.

[MK] However basically asking you the same again: draft-schinazi-masque-protocol proposed a POST-based mechanism to exchange configuration parameter. Is that really a HTTP mechanism for you? For me that a new protocol that uses HTTP underneath.

Mirja

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Apr 2020 10:37:04 -0700

On Mon, Apr 6, 2020 at 10:24 AM Mirja Kuehlewind <
[email-masked]> wrote:

> Hi Lucas, hi Ekr,
>
>
>
> see inline.
>
>
>
> *From: *Lucas Pardue <[email-masked]>
> *Date: *Monday, 6. April 2020 at 17:59
> *To: *Eric Rescorla <[email-masked]>
> *Cc: *Mirja Kuehlewind <[email-masked]>, Christopher Wood <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Masque] Updated proposed charter text
>
>
>
>
>
>
>
> 40ericsson.com@dmarc..ietf.org <[email-masked]>> wrote:
>
> Hi Chris,
>
OK.

> [MK] I guess it gets a bit philosophical now: If we would have an own
> ALPN token for masque (which is reasonable for some use cases) but still
> use the HTTP-based scheme as proposed in draft-schinazi-masque-protocol by
> POSTing for configuration parameters, would that still be H3?
>
> Well, ISTM that if we are using H3 for negotiation, then we should be
using the H3 ALPN token.

-Ekr

>
> [MK] I mean I think we are aligned here what we want. I just don’t want to
> be over-restrictive in the charter by calling it there a H3 connection
> while calling it a QUIC connection would be fine as well.
>
>

> [MK] I think we need more than just “configuration of QUIC transport
> features“ as the forwarding part itself and any operations needed for the
> forwarding part e.g. address translation or some kind of header compression
> are not a QUIC transport feature.
>
>
>
> [MK] However basically asking you the same again:
> draft-schinazi-masque-protocol proposed a POST-based mechanism to exchange
> configuration parameter. Is that really a HTTP mechanism for you? For me
> that a new protocol that uses HTTP underneath.
>
>
>
> Mirja
>
>
>
>
>
>

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 6 Apr 2020 18:52:42 +0100

I think there is some philosophical difference and view of the layering
here.

Another way to look at it is that we want to use the HTTP semantic over one
QUIC connection to bootstrap proxied stream- or datagram-based flows within
that connection[1]. HTTP/3 is today the specification of HTTP over QUIC,
and it uses the "h3" ALPN. It might be desirable to define a different HTTP
over QUIC mapping, e.g. "masque", that uses the same serialization as
HTTP/3 but includes some extra features, constraints etc.

This seems like a good point to consider BCP56bis[2] and decide where on
the spectrum of HTTP/non-HTTP MASQUE falls.

Lucas

[1] Without specifying the same connection, one could imagine using an
HTTP/3 connection to bootstrap a new QUIC connection that uses some other
ALPN ID. I don't think that is what we want.
[2] https://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#used

On Mon, Apr 6, 2020 at 6:37 PM Eric Rescorla <[email-masked]> wrote:

>> *Cc: *Mirja Kuehlewind <[email-masked]>, Christopher Wood
>> <[email-masked]>, "[email-masked]" <[email-masked]>
>> Philosophy aside, do we agree that these messages would be carried in
>> QUIC Datagram frames (
>> https://tools.ietf.org/html/draft-ietf-quic-datagram-00)?
>>
>>
>>
>> I'm not sure that this is right. If you use the H3 ALPN token and then
>> use H3 to negotiate but also negotiate datagram, this seems like an H3
>> connection to me.
>>
>>
>>
>> [MK] I mean I think we are aligned here what we want. I just don’t want
>> to be over-restrictive in the charter by calling it there a H3 connection
>> I would find using "QUIC" in place of "HTTP/3" confusing. QUIC requires
>> an authenticated negotiation of the application protocol and we use ALPN
>> for that today. There is no mechanism to my knowledge that would allow the
>> features“ as the forwarding part itself and any operations needed for
>> the forwarding part e.g. address translation or some kind of header
>> compression are not a QUIC transport feature.
>>
>>
>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 6 Apr 2020 18:07:34 +0000

Hi Lucas,

see below.

Date: Monday, 6. April 2020 at 19:52

I think there is some philosophical difference and view of the layering here.
Another way to look at it is that we want to use the HTTP semantic over one QUIC connection to bootstrap proxied stream- or datagram-based flows within that connection[1].

[MK] Yes I think we agree here.

HTTP/3 is today the specification of HTTP over QUIC, and it uses the "h3" ALPN. It might be desirable to define a different HTTP over QUIC mapping, e.g. "masque", that uses the same serialization as HTTP/3 but includes some extra features, constraints etc.

[MK ]And I guess we will need to have some discussion about this in the working group. So coming back to the original point about the wording in the charter: I still think saying QUIC connection (as you just did above) would be more generic/correct and would also be more clear about allowing this discussion to happen in the working group rather than prematurely precluding it now.

This seems like a good point to consider BCP56bis[2] and decide where on the spectrum of HTTP/non-HTTP MASQUE falls.

Lucas

[1] Without specifying the same connection, one could imagine using an HTTP/3 connection to bootstrap a new QUIC connection that uses some other ALPN ID. I don't think that is what we want.
[2] https://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#used<https://protect2.fireeye.com/v1/url?k=7d7ed50c-21aadd4f-7d7e9597-86a1150bc3ba-fe685d39dbe6fef0&q=1&e=5f8eaa70-762d-4d24-ad87-cb1c21b4c56f&u=https%3A%2F%2Fhttpwg.org%2Fhttp-extensions%2Fdraft-ietf-httpbis-bcp56bis.html%23used>

On Mon, Apr 6, 2020 at 6:37 PM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Apr 6, 2020 at 10:24 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lucas, hi Ekr,

see inline.

From: Lucas Pardue <[email-masked]<mailto:[email-masked]>>
Date: Monday, 6. April 2020 at 17:59
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>, Christopher Wood <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Masque] Updated proposed charter text

OK.

[MK] I guess it gets a bit philosophical now: If we would have an own ALPN token for masque (which is reasonable for some use cases) but still use the HTTP-based scheme as proposed in draft-schinazi-masque-protocol by POSTing for configuration parameters, would that still be H3?
Well, ISTM that if we are using H3 for negotiation, then we should be using the H3 ALPN token.

-Ekr

-Ekr

Mirja

---

From: Martin Duke <[email-masked]>
Date: Mon, 6 Apr 2020 11:16:05 -0700

(all hats off) There may be another way to encrypt the ALPN. If the server
issues each client a different version and salt, subsequent requests will
be unreadable by observers.

I know we've kicked this around in quicwg but it might be good for someone
to drop a draft, possibly in masque.

This has some issues but it may be a quicker path forward than waiting for
ECHO to fully bake.

On Mon, Apr 6, 2020 at 10:53 AM Lucas Pardue <[email-masked]>
wrote:

> Another way to look at it is that we want to use the HTTP semantic over
> one QUIC connection to bootstrap proxied stream- or datagram-based flows
> within that connection[1]. HTTP/3 is today the specification of HTTP over
> QUIC, and it uses the "h3" ALPN. It might be desirable to define a
> different HTTP over QUIC mapping, e..g. "masque", that uses the same
> serialization as HTTP/3 but includes some extra features, constraints etc.
>
> [2]
> https://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#used
>
>>> *Cc: *Mirja Kuehlewind <[email-masked]
>>> <mirja.kuehlewind@ericsson..com>>, Christopher Wood <[email-masked]>,
>>> "[email-masked]" <[email-masked]>
>> using the H3 ALPN token..
>>
>> -Ekr
>>
>>
>>
>>>