Subject: [Masque] Masque needs its own encrypted ALPN

From: Christian Huitema <[email-masked]>
Date: Thu, 2 Apr 2020 13:05:58 -0700

I hear the argument that Masque should use the H3 ALPN, in the name of
"not sticking out". But that argument would not apply if the ALPN was
encrypted, which I think it needs to be.

In the absence of encrypted ALPN, the "do not stick out" argument leads
to running every protocol on top of H3, then possibly doing strange
things with H3. For example, some application protocols care a lot about
the mapping of their protocol elements to QUIC frames and packets. But
if you run these protocols on top of H3, you should only use H3 frames,
whose mapping to QUIC frame is in theory arbitrary. If you insist on
running on top of H3, then you end up having to implement some QUIC kind
of frame mapping control inside the H3 stack. If multiple applications
have slightly different needs, that can become ugly quickly.

The ECHO proposal will encrypt the ALPN as well as the SNI. I understand
that we don't want to tie Masque development and ECHO development, but
we don't really have too. We just have to assume that when ALPN
encryption will become a concern, solutions like ECHO will enable ALPN
encryption. For now, it is sufficient to define a Masque specific ALPN,
and to specify frame mapping to QUIC  without being encumbered with H3
compatibility.

-- Christian Huitema

---

From: David Schinazi <[email-masked]>
Date: Thu, 2 Apr 2020 13:20:51 -0700

Hi Christian,

ECHO will stand out for many years to come, so I don't think we
can just say that this problem will be solved when we'll need it to be.

That said, not sticking out isn't the only motivation for using HTTP/3.
HTTP semantics provide features like routing through HTTP proxies,
which are useful in deployments where you use HTTP reverse
proxies as load balancers.

HTTP/3 is going to have to define how it uses DATAGRAM frames
regardless of what MASQUE needs, as they're used by things such
as Httptransport over in WEBTRANS.

David

On Thu, Apr 2, 2020 at 1:06 PM Christian Huitema <[email-masked]>
wrote:

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 2 Apr 2020 21:26:25 +0100

Thanks for bringing this up on the list.

Using a different ALPN also raises challenges for advertising the service
using Alt-Svc. Yes, you can protect the handshake itself as you mention but
the proxy would still be broadcasting its ability to support MASQUE
connections to whomever decides to probe it.

Lucas

---

From: Mike Bishop <[email-masked]>
Date: Thu, 2 Apr 2020 20:52:57 +0000

The anonymity of using ECHO really depends on what your anonymity set is.  Relative to all web traffic, yes, ECHO handshakes will stand out until it’s widely deployed.  But on a given server, if it supports ECHO, I think you can reasonably expect a substantial fraction of its incoming handshakes to employ ECHO once there’s browser support for it.  If a MASQUE server also serves web content, MASQUE handshakes to that server would not stand out from web handshakes to that server.  (If the server only does MASQUE, then by definition all traffic to it stands out.)

I think secretly advertising a server’s support for Masque will be a challenge regardless; again, it matters what your target threat model is.  If you’re trying to hide from an attacker who can make connections to your site, then a broad advertisement is right out.  If it’s advertised to all clients, a crawler can see it.  If it’s advertised as an HTTP/3 setting, then a crawler can still see it.  If it’s used only in response to a client that sends an HTTP/3 setting first, you’ve introduced a dependency between the client and server SETTINGS frames, which we’ve tried really hard not to do and a crawler could send that setting and see if it gets a response.  If it’s something the client just tries (e.g. send the CONNECT), an interested crawler could do the same thing.  Even if you challenge the client for authentication, getting a challenge when it attempts MASQUE discloses that the server speaks MASQUE, whatever that winds up being.

If a discrete protocol is needed, I agree with Christian that the most fruitful path forward is to define an ALPN token and encourage that it not be used in an unencrypted Client Hello.  Obviously, if we’re just defining UDP CONNECT for HTTP, that’s a smaller change.  And that leads back to the blind-man-and-elephant problem: we seem to have widely assorted views of what we want to accomplish and under what circumstances.

From: Masque <[email-masked]> On Behalf Of Lucas Pardue
Sent: Thursday, April 2, 2020 4:26 PM
To: David Schinazi <[email-masked]>
Cc: Christian Huitema <[email-masked]>; MASQUE <[email-masked]>
Subject: Re: [Masque] Masque needs its own encrypted ALPN

Using a different ALPN also raises challenges for advertising the service using Alt-Svc. Yes, you can protect the handshake itself as you mention but the proxy would still be broadcasting its ability to support MASQUE connections to whomever decides to probe it.

Lucas

On Thu, 2 Apr 2020, 21:21 David Schinazi, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Christian,

David

On Thu, Apr 2, 2020 at 1:06 PM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:
I hear the argument that Masque should use the H3 ALPN, in the name of
"not sticking out". But that argument would not apply if the ALPN was
encrypted, which I think it needs to be.

-- Christian Huitema

--
Masque mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/masque
--
Masque mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/masque

---

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

On Thu, Apr 2, 2020, at 1:52 PM, Mike Bishop wrote:
>  
> The anonymity of using ECHO really depends on what your anonymity set 
> is. Relative to all web traffic, yes, ECHO handshakes will stand out 
> until it’s widely deployed. But on a given server, if it supports ECHO, 
> I think you can reasonably expect a substantial fraction of its 
> incoming handshakes to employ ECHO once there’s browser support for it. 
> If a MASQUE server also serves web content, MASQUE handshakes to that 
> server would not stand out from web handshakes to that server. (If the 
> server only does MASQUE, then by definition all traffic to it stands 
> out.)
> 
> 
> I think secretly advertising a server’s support for Masque will be a 
> challenge regardless; again, it matters what your target threat model 
> is. If you’re trying to hide from an attacker who can make connections 
> to your site, then a broad advertisement is right out. If it’s 
> advertised to all clients, a crawler can see it. If it’s advertised as 
> an HTTP/3 setting, then a crawler can still see it. If it’s used only 
> in response to a client that sends an HTTP/3 setting first, you’ve 
> introduced a dependency between the client and server SETTINGS frames, 
> which we’ve tried really hard not to do *and* a crawler could send that 
> setting and see if it gets a response. If it’s something the client 
> just tries (e.g. send the CONNECT), an interested crawler could do the 
> same thing. Even if you challenge the client for authentication, 
> getting a challenge when it attempts MASQUE discloses that the server 
> speaks MASQUE, whatever that winds up being.

In case you've not seen it, David describes one possible way to do this here:

   https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-02#section-4

> If a discrete protocol is needed, I agree with Christian that the most 
> fruitful path forward is to define an ALPN token and encourage that it 
> not be used in an unencrypted Client Hello. Obviously, if we’re just 
> defining UDP CONNECT for HTTP, that’s a smaller change. And that leads 
> back to the blind-man-and-elephant problem: we seem to have widely 
> assorted views of what we want to accomplish and under what 
> circumstances.

As David pointed out, there were other reasons for focusing on an HTTP-based mechanism. (That doesn't mean it's right!)

Best,
Chris

---

From: Mike Bishop <[email-masked]>
Date: Mon, 6 Apr 2020 15:27:24 +0000

That section describes a way that establishing a connection might work, assuming that both client and server have been pre-provisioned with knowledge about each other, which leaves advertisement unsolved.  But yes, that mechanism gives you an option for "clients just try" without showing any difference on failure to a crawler.

-----Original Message-----
From: Masque <[email-masked]> On Behalf Of Christopher Wood
Sent: Monday, April 6, 2020 9:27 AM
To: [email-masked]
Subject: Re: [Masque] Masque needs its own encrypted ALPN

On Thu, Apr 2, 2020, at 1:52 PM, Mike Bishop wrote:
> until it’s widely deployed. But on a given server, if it supports 
> ECHO, I think you can reasonably expect a substantial fraction of its 
> which we’ve tried really hard not to do *and* a crawler could send 
> that setting and see if it gets a response. If it’s something the 
> client just tries (e.g. send the CONNECT), an interested crawler could 
> do the same thing. Even if you challenge the client for 
> authentication, getting a challenge when it attempts MASQUE discloses 
> that the server speaks MASQUE, whatever that winds up being.

Best,
Chris

---

From: David Schinazi <[email-masked]>
Date: Mon, 6 Apr 2020 18:42:00 -0700

Having MASQUE depend on ECHO would be a deal breaker for me. ECHO brings
along an incredibly large set of dependencies that are not viable in some
scenarios. For example, ECHO requires you to have significant control over
DNS infrastructure to make sure the ECHO keys are delivered to the client
via HTTPSSVC, a work-in-progress custom DNS RRTYPE. While I really believe
ECHO is great technology that will improve users' privacy on the Internet,
we are very far from it magically working for all clients and all servers.
MASQUE has no need for ECHO, and we shouldn't require it and all its
baggage.

David

On Mon, Apr 6, 2020 at 8:29 AM Mike Bishop <[email-masked]> wrote:

> That section describes a way that establishing a connection might work,
> assuming that both client and server have been pre-provisioned with
> knowledge about each other, which leaves advertisement unsolved.  But yes,
> that mechanism gives you an option for "clients just try" without showing
> any difference on failure to a crawler.
>
> As David pointed out, there were other reasons for focusing on an
> HTTP-based mechanism. (That doesn't mean it's right!)
>
> Best,
> Chris
>
> --
> Masque mailing list
> [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Apr 2020 18:59:01 -0700

I agree with David. Is there any particular reason to avoid using the H3
ALPN for MASQUE?

-Ekr

On Mon, Apr 6, 2020 at 6:42 PM David Schinazi <[email-masked]>
wrote:

>> https://tools..ietf.org/html/draft-schinazi-masque-obfuscation-02#section-4
>> <https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-02#section-4>
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 7 Apr 2020 11:14:39 +0000

Hi,

My individual view and not that I am a positive to forming a WG, we just need 
to nail down these questions.

On Mon, 2020-04-06 at 18:59 -0700, Eric Rescorla wrote:

> ALPN
> for MASQUE?

My counter question that might help answer this question is:

Is it acceptable that an HTTP request converts some of the QUIC streams or the 
datagram sequence / streams into a non-HTTP based transmission of tunneled 
data (packets). For a high performance masque server implementation, will it 
be possible to avoid having a HTTP aware implementation in the fast path 
performing the tunneling operation of packets?

My maybe too simplified view of the above would be that within something that 
is declared an HTTP/3 QUIC connection at least all the reliable streams MUST 
be following the HTTP/3 stream mapping, which forces the payload of the HTTP 
request to be the encapsulation protocol if one is transmitting things over 
the reliable stream. Which is something I expect to be useful in some cases. 
To me it appears that it is a policy related to proxy if it will use a 
reliable or unreliable transport (datagram). A proxy in a satellite link 
receiver station may actually use the reliable mode to repair local WIFI 
losses to avoid end-to-end retransmissions of locally lost packets knowing the 
high asymmetry in latency. While other proxies will use datagrams between 
clients and masque server as that will provide the best performance in their 
deployment.

Then we have the question of what are datagrams status inside a HTTP/3 QUIC 
connection. I have not yet grasped my head around what implications datagram 
has on HTTP semantics and what changes and dependencies that would have on the 
Masque protocol. Having a normative dependency on HTTP semantics for datagrams 
appears similarly potentially problematic as David's concerns over ECHO.

So isn't HTTP/3 going to constrain the protocol realization quite 
significantly?

Cheers

Magnus Westerlund

----------------------------------------------------------------------

Networks, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: [email-masked] 
<mailto:[email-masked]>

----------------------------------------------------------------------

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 7 Apr 2020 12:49:12 +0100

Hey Magnus,

See replies inline:

On Tue, Apr 7, 2020 at 12:14 PM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> Hi,
>
>
>
> My individual view and not that I am a positive to forming a WG, we just
> need to nail down these questions.
>
>
>
> > I agree with David. Is there any particular reason to avoid using the
> H3 ALPN
> > for MASQUE?
>
> Is it acceptable that an HTTP request converts some of the QUIC streams or
> the datagram sequence / streams into a non-HTTP based transmission of
> tunneled data (packets).
>
For a high performance masque server implementation, will it be possible to
> avoid having a HTTP aware implementation in the fast path performing the
> tunneling operation of packets?
>
My maybe too simplified view of the above would be that within something
> that is declared an HTTP/3 QUIC connection at least all the reliable
> streams MUST be following the HTTP/3 stream mapping, which forces the
> payload of the HTTP request to be the encapsulation protocol if one is
> transmitting things over the reliable stream.
>

In HTTP/3, only client-initiated bidirectional streams have an implicit
use, which is for requests. This aspect of HTTP/3 can be extended, draft 27
section 9 [1] provides some general guidance for such extension. This is
very similar to HTTP/2, which has precedence for being extended by RFC
8441. It defines changes that allow the client to repurpose a request
stream by using CONNECT in tandem with a new ":protocol" pseudo-header. If
an HTTP/3 request stream were converted similarly, the only encapsulation
overhead comes from the HTTP/3 DATA frame header (type and length as
variable-length integer). One can make DATA frames large in order to
minimise that overhead.

HTTP/3 also has unidirectional streams, that all start with a type ID.
HTTP/3 defines a few types that it requires but doesn't prevent other
stream types from being used. So it would be possible to build
bidirectional channels using a pair of these, although that may require
more complexity to coordinate.

> Which is something I expect to be useful in some cases. To me it appears
> that it is a policy related to proxy if it will use a reliable or
> unreliable transport (datagram). A proxy in a satellite link receiver
> station may actually use the reliable mode to repair local WIFI losses to
> avoid end-to-end retransmissions of locally lost packets knowing the high
> asymmetry in latency. While other proxies will use datagrams between
> clients and masque server as that will provide the best performance in
> their deployment.
>
> Then we have the question of what are datagrams status inside a HTTP/3
> QUIC connection. I have not yet grasped my head around what implications
> datagram has on HTTP semantics and what changes and dependencies that would
> have on the Masque protocol. Having a normative dependency on HTTP
> semantics for datagrams appears similarly potentially problematic as
> David's concerns over ECHO.
>

In my opinion, HTTP/3 datagram creates no new dependency HTTP semantics.
They become a feature of the HTTP wire image (a bit like unidirectional
streams) that can be assigned some meaning by the application using HTTP,
or safely unused.

[1] https://tools.ietf.org/html/draft-ietf-quic-http-27#section-9

---

From: Mike Bishop <[email-masked]>
Date: Wed, 8 Apr 2020 14:05:32 +0000

I’ll second the bulk of what Lucas said.  QUIC provides client- and server-initiated unidirectional and bidirectional streams.  All client-initiated bidirectional streams are owned by the HTTP/3 mapping, and broadly redefining their use would constitute a large enough change to the protocol that I would (again) encourage the use of a different protocol.  The use of server-initiated bidirectional streams are explicitly undefined in HTTP/3, and could be leveraged by an extension (at the cost of likely being incompatible with any other extension which also defined a use for them).  Unidirectional streams begin with a type identifier, and an extension could define new types easily.  Building a bidirectional channel from a pair is simply a matter of identifying the partner streams in each direction.

For datagrams, I’d caution about considering them totally independent.  There are several instances where frames are currently sent on the control streams (a defined unidirectional stream type) that would have been candidates for datagrams if that extension were part of the core QUIC spec; datagrams might be used by a future update to HTTP/3.  I would treat the datagram flow IDs as similar to the stream ID space, in that you might want to have a framework for sharing it with other parallel uses.

If building on top of HTTP/3, it seems like a lot of what MASQUE is after could be achieved by defining a UDP_CONNECT and/or QUIC_CONNECT method which establishes a Flow-ID, then uses DATAGRAM frames to carry the actual datagrams to be transferred.  There’s good precedent for the HTTP layer “getting out of the way” following a CONNECT or Upgrade.

More broadly, I think we have a broad scenario set and a broad solution space without regard to each other.  Supporting TCP and UDP relays over HTTP/3 with a consenting server is a well-scoped problem that can be solved with some judicious extensions to HTTP/3 and/or HTTP.  But the suite of services described in David’s draft starts looking a lot like its own independent protocol.  Which brings us back to the start of this thread:  *IF* a full independent protocol is defined, please don’t claim it’s HTTP/3.

From: Lucas Pardue <[email-masked]>
Sent: Tuesday, April 7, 2020 7:49 AM
To: Magnus Westerlund <magnus.westerlund=[email-masked]>
Cc: Eric Rescorla <[email-masked]>; David Schinazi <[email-masked]>; Mike Bishop <[email-masked]>; Christopher Wood <[email-masked]>; [email-masked]
Subject: Re: [Masque] Masque needs its own encrypted ALPN

Hey Magnus,

See replies inline:

On Tue, Apr 7, 2020 at 12:14 PM Magnus Westerlund <magnus.westerlund=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

My individual view and not that I am a positive to forming a WG, we just need to nail down these questions.

On Mon, 2020-04-06 at 18:59 -0700, Eric Rescorla wrote:
> I agree with David. Is there any particular reason to avoid using the H3 ALPN
> for MASQUE?
My counter question that might help answer this question is:
Is it acceptable that an HTTP request converts some of the QUIC streams or the datagram sequence / streams into a non-HTTP based transmission of tunneled data (packets).
For a high performance masque server implementation, will it be possible to avoid having a HTTP aware implementation in the fast path performing the tunneling operation of packets?
My maybe too simplified view of the above would be that within something that is declared an HTTP/3 QUIC connection at least all the reliable streams MUST be following the HTTP/3 stream mapping, which forces the payload of the HTTP request to be the encapsulation protocol if one is transmitting things over the reliable stream.

In HTTP/3, only client-initiated bidirectional streams have an implicit use, which is for requests. This aspect of HTTP/3 can be extended, draft 27 section 9 [1] provides some general guidance for such extension. This is very similar to HTTP/2, which has precedence for being extended by RFC 8441. It defines changes that allow the client to repurpose a request stream by using CONNECT in tandem with a new ":protocol" pseudo-header. If an HTTP/3 request stream were converted similarly, the only encapsulation overhead comes from the HTTP/3 DATA frame header (type and length as variable-length integer). One can make DATA frames large in order to minimise that overhead.

HTTP/3 also has unidirectional streams, that all start with a type ID. HTTP/3 defines a few types that it requires but doesn't prevent other stream types from being used. So it would be possible to build bidirectional channels using a pair of these, although that may require more complexity to coordinate.

Which is something I expect to be useful in some cases. To me it appears that it is a policy related to proxy if it will use a reliable or unreliable transport (datagram). A proxy in a satellite link receiver station may actually use the reliable mode to repair local WIFI losses to avoid end-to-end retransmissions of locally lost packets knowing the high asymmetry in latency. While other proxies will use datagrams between clients and masque server as that will provide the best performance in their deployment.
Then we have the question of what are datagrams status inside a HTTP/3 QUIC connection. I have not yet grasped my head around what implications datagram has on HTTP semantics and what changes and dependencies that would have on the Masque protocol. Having a normative dependency on HTTP semantics for datagrams appears similarly potentially problematic as David's concerns over ECHO.
So isn't HTTP/3 going to constrain the protocol realization quite significantly?

In my opinion, HTTP/3 datagram creates no new dependency HTTP semantics. They become a feature of the HTTP wire image (a bit like unidirectional streams) that can be assigned some meaning by the application using HTTP, or safely unused.

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 08 Apr 2020 10:59:48 -0700

On Wed, Apr 8, 2020, at 7:05 AM, Mike Bishop wrote:
>  
> I’ll second the bulk of what Lucas said. QUIC provides client- and 
> server-initiated unidirectional and bidirectional streams. All 
> client-initiated bidirectional streams are owned by the HTTP/3 mapping, 
> and broadly redefining their use would constitute a large enough change 
> to the protocol that I would (again) encourage the use of a different 
> protocol. The use of server-initiated bidirectional streams are 
> explicitly undefined in HTTP/3, and could be leveraged by an extension 
> (at the cost of likely being incompatible with any other extension 
> which also defined a use for them). Unidirectional streams begin with a 
> type identifier, and an extension could define new types easily. 
> Building a bidirectional channel from a pair is simply a matter of 
> identifying the partner streams in each direction.
> 
> 
> For datagrams, I’d caution about considering them totally independent. 
> There are several instances where frames are currently sent on the 
> control streams (a defined unidirectional stream type) that would have 
> been candidates for datagrams if that extension were part of the core 
> QUIC spec; datagrams might be used by a future update to HTTP/3. I 
> would treat the datagram flow IDs as similar to the stream ID space, in 
> that you might want to have a framework for sharing it with other 
> parallel uses.
> 
> 
> If building on top of HTTP/3, it seems like a lot of what MASQUE is 
> after could be achieved by defining a UDP_CONNECT and/or QUIC_CONNECT 
> method which establishes a Flow-ID, then uses DATAGRAM frames to carry 
> the actual datagrams to be transferred. There’s good precedent for the 
> HTTP layer “getting out of the way” following a CONNECT or Upgrade.
> 
> 
> More broadly, I think we have a broad scenario set and a broad solution 
> space without regard to each other. Supporting TCP and UDP relays over 
> HTTP/3 with a consenting server is a well-scoped problem that can be 
> solved with some judicious extensions to HTTP/3 and/or HTTP. But the 
> suite of services described in David’s draft starts looking a lot like 
> its own independent protocol. Which brings us back to the start of this 
> thread: **IF** a full independent protocol is defined, please don’t 
> claim it’s HTTP/3.

Putting David's draft aside for a moment, do you think the proposed charter also sets this up as a "full independent protocol"? The relevant text reads:

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

To me, this says that MASQUE aims to support TCP and UDP relays or proxies over HTTP/3. Per your claim above, this seems quite achievable! If you read it differently, how might you change the text?

Thanks,
Chris

---

From: Mike Bishop <[email-masked]>
Date: Wed, 8 Apr 2020 18:45:15 +0000

I agree that the charter looks more conservative in scenario scope.  "An HTTP-based signaling protocol" still implies the creation of a new protocol, which may not be needed.  I think there are three general approaches you could pursue within that language:

  *   Defining HTTP endpoints and payloads for particular services, i.e. a protocol on top of HTTP (like RPC over HTTP)
  *   Defining HTTP and/or HTTP/3 extensions to enable this functionality within an HTTP/3 connection
  *   Defining a new protocol over QUIC, where that new protocol is based on HTTP/3

The middle one seems like the one we’d want and intend.  Perhaps reword it to “The group will specify a set of extensions to HTTP/3 and HTTP which permit creating and configuring….”

-----Original Message-----
From: Masque <[email-masked]> On Behalf Of Christopher Wood
Sent: Wednesday, April 8, 2020 2:00 PM
To: [email-masked]
Subject: Re: [Masque] Masque needs its own encrypted ALPN

On Wed, Apr 8, 2020, at 7:05 AM, Mike Bishop wrote:

> client-initiated bidirectional streams are owned by the HTTP/3

> mapping, and broadly redefining their use would constitute a large

> enough change to the protocol that I would (again) encourage the use

> of a different protocol. The use of server-initiated bidirectional

> streams are explicitly undefined in HTTP/3, and could be leveraged by

> an extension (at the cost of likely being incompatible with any other

> extension which also defined a use for them). Unidirectional streams

> begin with a type identifier, and an extension could define new types easily.

> would treat the datagram flow IDs as similar to the stream ID space,

> in that you might want to have a framework for sharing it with other

> More broadly, I think we have a broad scenario set and a broad

> solution space without regard to each other. Supporting TCP and UDP

> relays over

> its own independent protocol. Which brings us back to the start of

> this

Thanks,

Chris

--

Masque mailing list

---

From: David Schinazi <[email-masked]>
Date: Wed, 8 Apr 2020 15:09:05 -0700

In my understanding, the intent was to mean "Defining HTTP and/or HTTP/3
extensions to enable this functionality within an HTTP/3 connection". We're
not trying to build a different application protocol here. I'd suggest we
tweak the charter to clarify that.

David

On Wed, Apr 8, 2020 at 11:45 AM Mike Bishop <[email-masked]> wrote:

> I agree that the charter looks more conservative in scenario scope.  "An
> HTTP-based signaling protocol" still implies the creation of a new
> protocol, which may not be needed.  I think there are three general
> approaches you could pursue within that language:
>
>    - Defining HTTP endpoints and payloads for particular services, i.e. a
>    protocol on top of HTTP (like RPC over HTTP)
>    - Defining HTTP and/or HTTP/3 extensions to enable this functionality
>    within an HTTP/3 connection
>    - Defining a new protocol over QUIC, where that new protocol is based
>    on HTTP/3
>
>
>
> The middle one seems like the one we’d want and intend.  Perhaps reword it
> to “The group will specify a set of extensions to HTTP/3 and HTTP which
> permit creating and configuring….”
>
>
>
> Putting David's draft aside for a moment, do you think the proposed
> charter also sets this up as a "full independent protocol"? The relevant
> text reads:
>
>
>
> "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."
>
>
>
> To me, this says that MASQUE aims to support TCP and UDP relays or proxies
> over HTTP/3. Per your claim above, this seems quite achievable! If you read
> it differently, how might you change the text?
>
>
>
> Thanks,
>
> Chris
>
>
>
> --
>
> Masque mailing list
>
> [email-masked]
>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 8 Apr 2020 23:26:24 +0100

See response below

On Wed, 8 Apr 2020, 23:09 David Schinazi, <[email-masked]> wrote:

>>    - Defining HTTP endpoints and payloads for particular services, i.e.
>>    a protocol on top of HTTP (like RPC over HTTP)
>> The middle one seems like the one we’d want and intend.  Perhaps reword
>> it to “The group will specify a set of extensions to HTTP/3 and HTTP which
+1 to Mike and David. Let's get the text tweaked to reflect that intent.

The full charter states that this WG will work closely with others on
extensions. I'm sure we can wordsmith the change to make the charter
self-consistent.

Cheers,
Lucas

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 09 Apr 2020 05:32:46 -0700

Agreed. And thanks, Mike, for the improvement.

Best,
Chris

On Wed, Apr 8, 2020, at 3:26 PM, Lucas Pardue wrote:
> > In my understanding, the intent was to mean "Defining HTTP and/or HTTP/3 extensions to enable this functionality within an HTTP/3 connection". We're not trying to build a different application protocol here. I'd suggest we tweak the charter to clarify that.
> > 
> > David
> > 
> >> I agree that the charter looks more conservative in scenario scope. "An HTTP-based signaling protocol" still implies the creation of a new protocol, which may not be needed. I think there are three general approaches you could pursue within that language:____
> 
> >>  * Defining HTTP endpoints and payloads for particular services, i.e. a protocol on top of HTTP (like RPC over HTTP)____
> >>  * Defining HTTP and/or HTTP/3 extensions to enable this functionality within an HTTP/3 connection____
> >>  * Defining a new protocol over QUIC, where that new protocol is based on HTTP/3____
> >> __ __
> 
> >> The middle one seems like the one we’d want and intend. Perhaps reword it to “The group will specify a set of extensions to HTTP/3 and HTTP which permit creating and configuring….”____
> 
> >> __ 
> 
>