Subject: [Masque] Consensus on charter?

From: Martin Duke <[email-masked]>
Date: Mon, 13 Apr 2020 15:44:55 -0700

I would like the gauge the level of consensus we have on several items. To
avoid total chaos in response, I ask one or both of the chairs to respond
with their assessment of the state of things and allow people to dissent
from that as a basis of discussion:

1) Will this use the HTTP/3 ALPN or its own? Or both? Is the minority on
this question willing to lie down in the road over it?

2) What proxy use cases are we trying to support? The "such as" language in
the proposed charter
<https://raw.githubusercontent.com/chris-wood/ietf-masque/master/proposed_charter.txt>
is IMO too loose but we could certainly add more use cases if it's a
manageable unit of work.

There seems to be clear support for TCP (which may turn out to be trivial)
and UDP (which is not a whole lot harder). The proposed charter also says
"IP" which sounds harder. If the words "such as" are to enable other use
cases (like DNS) we should call those out in the charter to give the ADs
responsible for those protocols a chance to object.

Of course, omitting some use cases from the charter does not preclude
bringing them back after reaching some milestones.

3) After we've answered #2, is this a WG size unit of work? If we were to
adopt David's drafts, for instance, it's basically two shortish documents
to solve five use cases. If that is the limit of it, it's best handled in
an existing WG.

However, if the desired use cases involve several long and/or tricky
drafts, or we envision some more use cases after a rechartering, then this
seems to be within scope of a WG.

Regards,
Martin

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 13 Apr 2020 16:00:07 -0700

On Mon, Apr 13, 2020, at 3:44 PM, Martin Duke wrote:
> I would like the gauge the level of consensus we have on several items. 
> To avoid total chaos in response, I ask one or both of the chairs to 
> respond with their assessment of the state of things and allow people 
> to dissent from that as a basis of discussion:
> 
> 1) Will this use the HTTP/3 ALPN or its own? Or both? Is the minority 
> on this question willing to lie down in the road over it?

Based on the BoF meeting and both on- and off-list discussion, it seems there's rough consensus for the HTTP/3 ALPN. Taking a dependency on ECHO (or some other ALPN encryption mechanism) did not seem desired.

> 2) What proxy use cases are we trying to support? The "such as" 
> language in the proposed charter 
> <https://raw.githubusercontent.com/chris-wood/ietf-masque/master/proposed_charter.txt> is IMO too loose but we could certainly add more use cases if it's a manageable unit of work.
> 
> There seems to be clear support for TCP (which may turn out to be 
> trivial) and UDP (which is not a whole lot harder). The proposed 
> charter also says "IP" which sounds harder. If the words "such as" are 
> to enable other use cases (like DNS) we should call those out in the 
> charter to give the ADs responsible for those protocols a chance to 
> object.
> 

Precisely! Our (chair) impression based on the BoF and list feedback was that UDP and IP are a good chunk of work with which we can start (and possibly conclude when done!). While there have been other protocols floated on the list and in drafts, such as DNS, there was no truly compelling use case that justified their inclusion. Therefore, we propose dropping the words "such as" from the charter, focusing on UDP and IP, which leaves the following: 

   "The group will focus on a limited set of client-initiated services: (1) UDP and then (2) IP proxying." 

(Kudos to Mark, as this was his suggestion all along.)

> 3) After we've answered #2, is this a WG size unit of work? If we were 
> to adopt David's drafts, for instance, it's basically two shortish 
> documents to solve five use cases. If that is the limit of it, it's 
> best handled in an existing WG.
> 
> drafts, or we envision some more use cases after a rechartering, then 
> this seems to be within scope of a WG.

We (chairs) see at least two major deliverables coming from this effort: (1) a specification for UDP proxying, and (2) a specification for IP proxying. The latter will not be as straightforward as the former. The WG might also work on a use case and requirements document to help refine the these deliverables, though it's unclear if that warrants publication as an RFC. Thus, we envision this as a short-lived WG aimed at addressing these use cases. If, upon completion, the WG decides more use cases can be take on, WG chairs can consider re-chartering and widening the WG scope at that time. 

Best,
Chris, on behalf of the chairs

---

From: David Schinazi <[email-masked]>
Date: Mon, 13 Apr 2020 16:24:06 -0700

I support this change. I think constraining to charter to working on UDP
proxying first, then working on IP proxying sounds like a good plan.

On the topic of whether to form a working group, I think there will need to
be discussion about these deliverables, and I'm not sure the HTTPBIS WG
would like to devote that much agenda time to this. To me this is
conceptually similar to the DoH WG, which was chartered with a specific
deliverable which became RFC 8484. I'm not aware of a requirement
on number of drafts in order to form a WG. Once the two deliverables are
published the MASQUE WG can be concluded or rechartered depending on
whether participants have other use-cases they want to work on.

Thanks,
David

On Mon, Apr 13, 2020 at 4:00 PM Christopher Wood <[email-masked]>
wrote:

> Based on the BoF meeting and both on- and off-list discussion, it seems
> there's rough consensus for the HTTP/3 ALPN. Taking a dependency on ECHO
> (or some other ALPN encryption mechanism) did not seem desired.
>
> > <
> https://raw.githubusercontent.com/chris-wood/ietf-masque/master/proposed_charter.txt>
> Precisely! Our (chair) impression based on the BoF and list feedback was
> that UDP and IP are a good chunk of work with which we can start (and
> possibly conclude when done!). While there have been other protocols
> floated on the list and in drafts, such as DNS, there was no truly
> compelling use case that justified their inclusion. Therefore, we propose
> dropping the words "such as" from the charter, focusing on UDP and IP,
> which leaves the following:
>
> We (chairs) see at least two major deliverables coming from this effort:
> (1) a specification for UDP proxying, and (2) a specification for IP
> proxying. The latter will not be as straightforward as the former. The WG
> might also work on a use case and requirements document to help refine the
> these deliverables, though it's unclear if that warrants publication as an
> RFC. Thus, we envision this as a short-lived WG aimed at addressing these
> use cases. If, upon completion, the WG decides more use cases can be take
> on, WG chairs can consider re-chartering and widening the WG scope at that
> time.
>
> Best,
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 Apr 2020 16:48:33 -0700

On 4/13/2020 4:24 PM, David Schinazi wrote:

> I support this change. I think constraining to charter to working on
> UDP proxying first, then working on IP proxying sounds like a good plan.
>
> On the topic of whether to form a working group, I think there will
> need to be discussion about these deliverables, and I'm not sure the
> HTTPBIS WG would like to devote that much agenda time to this. To me
> this is conceptually similar to the DoH WG, which was chartered with a
> specific deliverable which became RFC 8484. I'm not aware of a
> requirement on number of drafts in order to form a WG. Once the two
> deliverables are published the MASQUE WG can be concluded or
> rechartered depending on whether participants have other use-cases
> they want to work on.

I agree, with one caveat. The words "user initiated UDP" are a bit
vague. I don't know whether this means:

1) Something like TURN, requiring binding of channels to specific 5
tuples, and treating arrival of packets outside of pre-defined channels
as "signalled events".

2) Something like NAT-PMP, reserving an"external port" and forwarding
all packets arriving on that port to the client.

Something like TURN would off course allow us to use the existing threat
modelling and security considerations of TURN rather than invent our
own, and that seems like a good idea.

By the way, are we dropping TCP proxying from the charter?

-- Christian Huitema

---

From: David Schinazi <[email-masked]>
Date: Mon, 13 Apr 2020 17:02:19 -0700

I think the intention of "UDP proxying" is to have a UDP equivalent of HTTP
CONNECT.
We would build a mechanism by which the client tells the proxy
"Please UDP-CONNECT to SERVER_IP:SERVER_PORT"
The server would then create a connected UDP socket, and this would behave
very
similarly to the traditional TCP-only HTTP CONNECT, and would use a local
ephemeral port.
If the server receives any UDP packet on that ephemeral port that does not
match the 5-tuple,
it just discards it.

I don't think we should try to reinvent TURN or NAT-PMP here.

I think TCP proxying got removed from the charter because HTTP CONNECT
already exists.

David

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 Apr 2020 17:17:00 -0700

David, that's a fine answer. But if I found the charter somewhat
ambiguous, it is entirely possible that a few more people will. If the
consensus is to develop an UDP CONNECT mechanism similar to TCP CONNECT,
than maybe we should say exactly that in the charter.

-- Christian Huitema

On 4/13/2020 5:02 PM, David Schinazi wrote:
> I think the intention of "UDP proxying" is to have a UDP equivalent of
> HTTP CONNECT.
> The server would then create a connected UDP socket, and this would
> behave very
> similarly to the traditional TCP-only HTTP CONNECT, and would use a
> local ephemeral port.
> If the server receives any UDP packet on that ephemeral port that does
> not match the 5-tuple,
> it just discards it.
>
> On Mon, Apr 13, 2020 at 4:48 PM Christian Huitema <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 13 Apr 2020 20:33:29 -0400

Question: shall we design a protocol that supports only clients of
client-server protocols, or one that also enables proxying of P2P and
server traffic?
Meta-question: do we have to decide this in the charter, or can we defer it
to the working group?

I think that, precisely to avoid reinventing TURN, we should consider
adopting TURN nearly as-is, to avoid defining yet another encapsulation
format.  We're going to want all that functionality eventually anyway, and
browsers that do WebRTC already have a full implementation so this should
reduce total code size.

I don't think that we need to figure this out during chartering.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Apr 2020 01:46:55 +0100

Hiya,

> Meta-question: do we have to decide this in the charter, or can we defer it

Meta-answer(*): I can't see how the WG avoids repetitive
and near-endless churn if that's not already decided in
the charter.

S.

(*) is there even such a thing as a meta-answer? :-)

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 14 Apr 2020 08:32:12 -0700

On Mon, Apr 13, 2020, at 5:17 PM, Christian Huitema wrote:
> consensus is to develop an UDP CONNECT mechanism similar to TCP 
> CONNECT, than maybe we should say exactly that in the charter.

That seems quite reasonable to me! Thanks for pointing out this ambiguity and helping clarify it. 

Best,
Chris

> > I think the intention of "UDP proxying" is to have a UDP equivalent of HTTP CONNECT. 
> > The server would then create a connected UDP socket, and this would behave very
> > similarly to the traditional TCP-only HTTP CONNECT, and would use a local ephemeral port.
> > If the server receives any UDP packet on that ephemeral port that does not match the 5-tuple,
> > it just discards it.
> > 
> > I think TCP proxying got removed from the charter because HTTP CONNECT already exists.
> > 
> > David
> > 
> > On Mon, Apr 13, 2020 at 4:48 PM Christian Huitema <[email-masked]> wrote:

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 14 Apr 2020 16:17:59 +0000

I would like to double-check if that is really what we want. I do believe that having a proxying approach that is based on HTTP CONNECT would work in most use cases and I do see the case of hiding the fact that some connection is MASQUE traffic (by masking it as web traffic instead). However, I think that most use cases (except the one where you actually "only" want to extend HTTP CONNECT to UDP/QUIC for web traffic) are actually not foremost, if at all, focused on web traffic - this is especially the case for any use case that includes IP proxying like the VPN/QBONE use case. While implementing a limited HTTP CONNECT support does not meant that a masque server has to implement a full HTTP stack, for any server that is usually not serving HTTP traffic that would probably not be the first choice for a proxying protocol. 

I think there are pros and cons of a HTTP CONNECT extension approach vs. an approach that uses an HTTP-based protocol for negotiation, but I'm not sure I can make a decision at charter time given that a lot probably depends on the details of such a protocol and we so far only have a initial proposal for the latter approach.

Mirja

On 14.04.20, 17:32, "Masque on behalf of Christopher Wood" <[email-masked] on behalf of [email-masked]> wrote:

    
    Best,
    Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 14 Apr 2020 09:59:15 -0700

On Mon, Apr 13, 2020, at 5:33 PM, Ben Schwartz wrote:
> Meta-question: do we have to decide this in the charter, or can we 
> defer it to the working group?

The charter aims to focus on the former. We can always re-charter later to bring in P2P mechanisms.

Best,
Chris

> format. We're going to want all that functionality eventually anyway, 
> and browsers that do WebRTC already have a full implementation so this 
> should reduce total code size.
> 
> On Mon, Apr 13, 2020 at 8:17 PM Christian Huitema <[email-masked]> wrote:
> > David, that's a fine answer. But if I found the charter somewhat ambiguous, it is entirely possible that a few more people will. If the consensus is to develop an UDP CONNECT mechanism similar to TCP CONNECT, than maybe we should say exactly that in the charter.
> 
> > -- Christian Huitema
> 
> Attachments:
> * smime.p7s

---

From: David Schinazi <[email-masked]>
Date: Tue, 14 Apr 2020 11:51:17 -0700

On Tue, Apr 14, 2020 at 9:18 AM Mirja Kuehlewind <
[email-masked]> wrote:

> I would like to double-check if that is really what we want. I do believe
> that having a proxying approach that is based on HTTP CONNECT would work in
> most use cases and I do see the case of hiding the fact that some
> connection is MASQUE traffic (by masking it as web traffic instead).
> However, I think that most use cases (except the one where you actually
> "only" want to extend HTTP CONNECT to UDP/QUIC for web traffic) are
> actually not foremost, if at all, focused on web traffic - this is
> especially the case for any use case that includes IP proxying like the
> VPN/QBONE use case. While implementing a limited HTTP CONNECT support does
> not meant that a masque server has to implement a full HTTP stack, for any
> server that is usually not serving HTTP traffic that would probably not be
> the first choice for a proxying protocol.
>

I do think that is really what we want. HTTP already provides CONNECT,
therefore adding what we need at that layer sounds like the right choice.

I think there are pros and cons of a HTTP CONNECT extension approach vs. an
> approach that uses an HTTP-based protocol for negotiation, but I'm not sure
> I can make a decision at charter time given that a lot probably depends on
> the details of such a protocol and we so far only have a initial proposal
> for the latter approach.
>

We've heard the pros of HTTP, but so far I haven't heard arguments against
it apart from a slight reduction in code size. Nailing this down at
chartering time allows us to move forward instead of setting us up for a
lengthy conversation in the new WG.

David

Mirja
>
>
> On 14.04.20, 17:32, "Masque on behalf of Christopher Wood" <
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Apr 2020 16:44:11 -0700

On Tue, Apr 14, 2020 at 11:51 AM David Schinazi <[email-masked]>
wrote:

> I think there are pros and cons of a HTTP CONNECT extension approach vs.
>> an approach that uses an HTTP-based protocol for negotiation, but I'm not
>> sure I can make a decision at charter time given that a lot probably
>> depends on the details of such a protocol and we so far only have a initial
>> proposal for the latter approach.
>>
>

+1. I think we should commit to HTTP both for consistency with TCP and for
conceptual simplicity reasons (we are already going to use HTTP to
negotiate things).

In terms of this IP question, here are some half-baked thoughts:

- HTTP already provides CONNECT for TCP, so there's very little to do if
anything
- CONNECTU seems very easy to design as it's directly analogous to CONNECT
- Any kind of generic IP tunnelling (as opposed to "just send IP datagrams
to this location all the time as with CONNECTU") is going to require rather
more engineering and might not even conceptually be like connect.

What if we sent CONNECTU (and CONNECT with QUIC if anything is needed) to
HTTP to do and make the MASQUE WG *just* IP?

-Ekr

David
>>     > > On Mon, Apr 13, 2020 at 4:48 PM Christian Huitema <
>> huitema@huitema..net <[email-masked]>> wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Apr 2020 07:28:28 -0500

Hi, Eric,

On Wed, Apr 15, 2020 at 6:44 PM Eric Rescorla <[email-masked]> wrote:

>>> I would like to double-check if that is really what we want. I do
>>> believe that having a proxying approach that is based on HTTP CONNECT would
>>> work in most use cases and I do see the case of hiding the fact that some
>> We've heard the pros of HTTP, but so far I haven't heard arguments
>> against it apart from a slight reduction in code size. Nailing this down at

That's an interesting proposal.

I don't have an opinion about the Right Thing To Do, but I note that the
"IP last" strategy wouldn't prioritize either QBONE or Release 17 3GPP
ATSSS requirements.

I agree with you about IP tunneling requiring rather more engineering, and
if your proposed organization would make that easier, that would be lovely.

Honestly, CONNECTU and "CONNECTIP" might not even fit in the same area ...

IMO, of course.

Best,

Spencer

>>> huitema@huitema...net <[email-masked]>> wrote:

---

From: Ted Hardie <[email-masked]>
Date: Thu, 16 Apr 2020 09:08:16 -0700

> That's an interesting proposal.
I agree that it is interesting, but I had thought the current rubric was
that HTTP WG handled anything that wasn't transport specific, and that QUIC
handled the transport specific aspects.  We can change that, of course, but
I do hope we're not trying to have CONNECTU work with HTTP/2 or other
TCP-based transports.  While you could obviously get that to work at some
level, I don't think anyone using CONNECTU would be very happy with the
performance.

> When is Release 17 due to ship?

regards,

Ted

>>>> huitema@huitema....net <[email-masked]>> wrote:

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Apr 2020 10:20:45 -0700

On Thu, Apr 16, 2020 at 9:08 AM Ted Hardie <[email-masked]> wrote:

>>> What if we sent CONNECTU (and CONNECT with QUIC if anything is needed)
>>> to HTTP to do and make the MASQUE WG *just* IP?
>>>
>>
> handled the transport specific aspects.
>

I don't have a strong opinion about HTTP vs. QUIC.

We can change that, of course, but I do hope we're not trying to have
> CONNECTU work with HTTP/2 or other TCP-based transports.  While you could
> obviously get that to work at some level, I don't think anyone using
> CONNECTU would be very happy with the performance.
>

I hadn't thought about this a lot. I can tell you that this actually would
be useful for some applications for the same reason that TURN-TCP is useful.

-Ekr

>> I agree with you about IP tunneling requiring rather more engineering,
>> and if your proposed organization would make that easier, that would be
>> lovely.
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Apr 2020 12:23:30 -0500

Hi, Ted,

>> When is Release 17 due to ship?

I am not the 3GPP Whisperer (and I note that Gonzalo Camarillo is still
listed as the IETF-to-3GPP liaison manager at
https://www.ietf.org/about/liaisons/, so I assume he'd be smarter than I
am), but from https://www.3gpp.org/specifications/releases, they changed
the timeline at the March plenary by three months, to

   - Rel-17 Stage 3 freeze September 2021
   - Rel-17 ASN.1 and OpenAPI specification freeze: December 2021

My point on mentioning ATSSS wasn't that shipping was imminent, but that
the people doing Stage 2 architecture are starting (if all proceeds
according to plan) in May 2020. Waterfalls, and all that.

Best,

Spencer

regards,

---

From: Mike Bishop <[email-masked]>
Date: Fri, 17 Apr 2020 17:56:48 +0000

CONNECT is a special beast in HTTP-land – the method definition is generic across all HTTP versions, but the actual mechanics of implementing it vary from H1 to H2 to H3.  (Most notably, the stream typically closes after the request headers if there’s no body, but CONNECT is special in that the “body” only commences after the server has sent a 200.)  It’s the subject of some discussion how that should land between the HTTP Semantics and the HTTP/1.1 Messaging drafts.  CONNECT is already defined in the HTTP/3 draft, so I don’t think there’s anything new needed on that front; if there is, PRs welcome.  Upgrade is similar – it’s a cross-version extension point that nonetheless requires per-version specification, and it’s usage is not specified for HTTP/2 or HTTP/3.

I would expect CONNECTU to be at least as special, particularly since in HTTP/3 it would use DATAGRAM frames, a concept which doesn’t exist in TCP-based HTTP mappings.  We might reasonably choose to leave its use on those mappings undefined, or create a simply framing that allows sending datagrams (albeit obviously in an order) over the TCP connection.

I don’t believe the current state of the charters/draft charters gives the QUIC WG any purview over HTTP/3 – even QUIC-specific pieces – once HTTP/3 ships.  It’s handed off to HTTP for maintenance and extensions, while QUIC will be rechartering to continue transport-layer work.

From: Masque <[email-masked]> On Behalf Of Ted Hardie
Sent: Thursday, April 16, 2020 12:08 PM
To: Spencer Dawkins at IETF <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; MASQUE <[email-masked]>; Christian Huitema <[email-masked]>; Mirja Kuehlewind <[email-masked]>; David Schinazi <[email-masked]>; Christopher Wood <[email-masked]>
Subject: Re: [Masque] Consensus on charter?

On Thu, Apr 16, 2020 at 5:29 AM Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:

What if we sent CONNECTU (and CONNECT with QUIC if anything is needed) to HTTP to do and make the MASQUE WG *just* IP?

I agree that it is interesting, but I had thought the current rubric was that HTTP WG handled anything that wasn't transport specific, and that QUIC handled the transport specific aspects.  We can change that, of course, but I do hope we're not trying to have CONNECTU work with HTTP/2 or other TCP-based transports.  While you could obviously get that to work at some level, I don't think anyone using CONNECTU would be very happy with the performance.

I don't have an opinion about the Right Thing To Do, but I note that the "IP last" strategy wouldn't prioritize either QBONE or Release 17 3GPP ATSSS requirements.

regards,

Ted

I agree with you about IP tunneling requiring rather more engineering, and if your proposed organization would make that easier, that would be lovely.

IMO, of course.

Best,

Spencer

-Ekr

David

Mirja

On 14.04.20, 17:32, "Masque on behalf of Christopher Wood" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Best,
    Chris

    > > On Mon, Apr 13, 2020 at 4:48 PM Christian Huitema <huitema@huitema.....net<mailto:[email-masked]>> wrote:
    > >> [email-masked]<mailto:[email-masked]>

    --
    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
--
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: <[email-masked]>
Date: Fri, 17 Apr 2020 18:00:38 +0000

Dear all,

since I'm involved in the 3GPP ATSSS specification from DT side and I believe that MASQUE might become one piece in the solution puzzle, I want to ask you if MASQUE and the current proposed charter inherently cover/consider:

- Support for MP-QUIC and Datagram mode
- Congestion Control over Congestion Control in case of UDP or IP proxying
- Dynamic/Relaxed Encryption for already secured data to avoid useless and power consuming 

and the combination of this bullet points.

Maybe that was already discussed on the mailinglist, unfortunately I joint the mailinglist late.

BR

Markus 

From: Masque <[email-masked]> On Behalf Of Spencer Dawkins at IETF
Sent: Donnerstag, 16. April 2020 19:24
To: Ted Hardie <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; MASQUE <[email-masked]>; Christian Huitema <[email-masked]>; Mirja Kuehlewind <[email-masked]>; David Schinazi <[email-masked]>; Christopher Wood <[email-masked]>
Subject: Re: [Masque] Consensus on charter?

Hi, Ted,

On Thu, Apr 16, 2020 at 11:08 AM Ted Hardie <mailto:[email-masked]> wrote:
On Thu, Apr 16, 2020 at 5:29 AM Spencer Dawkins at IETF <mailto:[email-masked]> wrote:

I am not the 3GPP Whisperer (and I note that Gonzalo Camarillo is still listed as the IETF-to-3GPP liaison manager at https://www.ietf.org/about/liaisons/, so I assume he'd be smarter than I am), but from https://www.3gpp.org/specifications/releases, they changed the timeline at the March plenary by three months, to 
• Rel-17 Stage 3 freeze September 2021
• Rel-17 ASN.1 and OpenAPI specification freeze: December 2021
My point on mentioning ATSSS wasn't that shipping was imminent, but that the people doing Stage 2 architecture are starting (if all proceeds according to plan) in May 2020. Waterfalls, and all that. 

Best,

Spencer 

regards,

Ted

---

From: Martin Duke <[email-masked]>
Date: Sat, 18 Apr 2020 16:48:24 -0700

I am happy to be proven wrong, but ISTM CONNECTU has nested congestion
control issues not present with CONNECT that may not fit well with httpbis.

On Fri, Apr 17, 2020, 11:00 <[email-masked]> wrote:

> Dear all,
>
> since I'm involved in the 3GPP ATSSS specification from DT side and I
> believe that MASQUE might become one piece in the solution puzzle, I want
> to ask you if MASQUE and the current proposed charter inherently
> cover/consider:
>
> Cc: Eric Rescorla <[email-masked]>; MASQUE <[email-masked]>; Christian
> Huitema <[email-masked]>; Mirja Kuehlewind <
> [email-masked]>; David Schinazi <[email-masked]>;
> Christopher Wood <[email-masked]>

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 21 Apr 2020 18:26:15 -0700

Good point, Martin! Given this, and given what's in store for QUIC and HTTPBIS in the near(ish) future, does moving CONNECTU still make sense?

Best,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 21 Apr 2020 18:30:03 -0700

Hi Markus,

On Fri, Apr 17, 2020, at 11:00 AM, [email-masked] wrote:
> believe that MASQUE might become one piece in the solution puzzle, I 
> want to ask you if MASQUE and the current proposed charter inherently 
> cover/consider:
> 

By Datagram mode do you mean QUIC datagrams, or something else? 

I think MP-QUIC is out of scope given that it's not part of QUICv1. 

> - Congestion Control over Congestion Control in case of UDP or IP 

The proposed charter items will probably need to touch on this, yes, and I think that's in scope. 

> - Dynamic/Relaxed Encryption for already secured data to avoid useless 

Based on the current proposed charter and past discussions on this list, I believe this to be out of scope.

I hope this helps!

Best,
Chris

---

From: <[email-masked]>
Date: Wed, 22 Apr 2020 10:15:17 +0000

Hi Chris, thanks for answering, please see my comments below.

> -----Original Message-----
> From: Christopher Wood <[email-masked]>
> Sent: Mittwoch, 22. April 2020 03:30
> To: Amend, Markus <[email-masked]>; Spencer Dawkins at IETF
> <[email-masked]>; Ted Hardie <[email-masked]>
> Cc: Eric Rescorla <[email-masked]>; [email-masked]; Christian Huitema
> <[email-masked]>; Mirja Kuehlewind
> <[email-masked]>; David Schinazi
> <[email-masked]>

Yes, indeed I meant QUIC datagram

> I think MP-QUIC is out of scope given that it's not part of QUICv1.

OK. However, from my rough understanding there is nothing which really prevents Masque to be used in combination with MP when it becomes standardized. Do you share this assumption?

> believe this to be out of scope.

I fully understand the QUIC community position on this, since security is an integral feature of QUIC. But please have in mind, assuming MASQUE becomes an option in 3GPP ATSSS for UDP or even IP proxying, this leads to several nested encryption layer. In particular if it is assumed, that most of the piggybacked data for UDP proxying is again QUIC -> 3GPP IPsec tunnel, Masque tunnel, piggybacked QUIC.
Three encryption layer where two are useless since the security level is not increased. Rather it has presumably drawbacks on the handset energy consumption and achievable transmission speed.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Apr 2020 10:16:27 -0500

Just to poke at multipath ...

On Wed, Apr 22, 2020 at 5:15 AM <[email-masked]> wrote:

> OK. However, from my rough understanding there is nothing which really
> prevents Masque to be used in combination with MP when it becomes
> standardized. Do you share this assumption?
>

The language in the most current QUIC charter is still about "- Enabling
multipath and forward error correction extensions", isn't it?

So, my suggestion for MASQUE, would be to

   - include language like "enabling multipath" in the charter, to prevent
   MASQUE from having to recharter just because QUIC delivered MP-QUIC,
   - include multipath as a consideration for MASQUE, at least as a high
   level design consideration, and
   - trust the MASQUE chairs to manage what MASQUE works on, as we have
   done and continue to do in QUIC.

Adding language like that would also reduce the number of conversations
about "whether multipath is a requirement" as MASQUE does its work.

Best,

Spencer

> > The proposed charter items will probably need to touch on this, yes, and
> I
> > think that's in scope.
> >
> > Based on the current proposed charter and past discussions on this list,
> I
> > believe this to be out of scope.
> >
>
> I fully understand the QUIC community position on this, since security is
> an integral feature of QUIC. But please have in mind, assuming MASQUE
> becomes an option in 3GPP ATSSS for UDP or even IP proxying, this leads to
> several nested encryption layer. In particular if it is assumed, that most
> of the piggybacked data for UDP proxying is again QUIC -> 3GPP IPsec
> tunnel, Masque tunnel, piggybacked QUIC.
> Three encryption layer where two are useless since the security level is
> not increased. Rather it has presumably drawbacks on the handset energy
> consumption and achievable transmission speed.
>
> > I hope this helps!
> >
> > Best,
> > Chris
>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 22 Apr 2020 10:26:55 -0700

On Wed, Apr 22, 2020, at 3:15 AM, [email-masked] wrote:
> I fully understand the QUIC community position on this, since security 
> is an integral feature of QUIC. But please have in mind, assuming 
> MASQUE becomes an option in 3GPP ATSSS for UDP or even IP proxying, 
> this leads to several nested encryption layer. In particular if it is 
> assumed, that most of the piggybacked data for UDP proxying is again 
> QUIC -> 3GPP IPsec tunnel, Masque tunnel, piggybacked QUIC.
> Three encryption layer where two are useless since the security level 
> is not increased. Rather it has presumably drawbacks on the handset 
> energy consumption and achievable transmission speed.

(with no hats on)

This is symmetric encryption we're talking about, so I'm not sure I buy this cost argument. Moreover, removing encryption may have unknown consequences and warrants further analysis. As such, I don't think this use case is worth considering (at this time).

Best,
Chris

---

From: Martin Duke <[email-masked]>
Date: Wed, 22 Apr 2020 19:22:35 -0700

Regarding removing encryption:

There is only one layer of encryption in masque, and that is the connection
from client to MASQUE server. ISTM that layer is critical to the privacy
properties.

The things on top of the IP or UDP transport may or may not have their own
encryption, but that is orthogonal to MASQUE. In principle, MASQUE could
offer an IPSec or DTLS service (ie, the proxy encrypts the
packets/datagrams for you), but IMO that is not currently in scope.

On Wed, Apr 22, 2020, 10:27 Christopher Wood <[email-masked]> wrote:

> > > The proposed charter items will probably need to touch on this, yes,
> and I
> > > think that's in scope.
> > >
> > > > - Dynamic/Relaxed Encryption for already secured data to avoid
> useless
> > > > and power consuming
> > >
> > > Based on the current proposed charter and past discussions on this
> list, I
> This is symmetric encryption we're talking about, so I'm not sure I buy
> this cost argument. Moreover, removing encryption may have unknown
> consequences and warrants further analysis. As such, I don't think this use
> case is worth considering (at this time).
>
> Best,
> Chris
>
> --
> Masque mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Apr 2020 03:31:48 +0100

Hiya,

On 23/04/2020 03:22, Martin Duke wrote:
> encryption, but that is orthogonal to MASQUE. 

Disagree. Unless masque is useful with two layers of
encryption, masque is useless.

So IMO these things are not orthogonal, in the sense
of a wg not having to worry about the feasibility of
a 2nd layer of encryption.

Put another way: I think the putative wg here does
have to worry about the feasibility of a 2nd layer of
encryption. A wg doesn't have to specify how to do
that 2nd layer of crypto, but it does have to not
bugger it up.

Cheers,
S.

> In principle, MASQUE could

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 18:30:42 +1000

> encryption, masque is useless.

That's a strong statement.  I think that I have a design without two layers of symmetric encryption, but I don't know if it is worth the complexity and maybe the added exposure to traffic analysis that comes with it.  But it does still have two encryption contexts, which I agree is necessary.  Some stuff is necessarily secret between client and proxy; other stuff is necessarily secret between client and server.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 23 Apr 2020 08:45:41 +0000

(comment marked with [MK] below)

On 23.04.20, 10:31, "Martin Thomson" <[email-masked]> wrote:

[MK] Yes, the concern that the actual end-to-end payload data would be encrypted twice comes up often. The approach we've been looking at is not to interfere with the end-to-end encryption but find a way to avoid double-encryption on the MASQUE tunnel segment if the end-to-end traffic is known to be already encrypted, e.g in case of QUIC proxying. As Martin said, you still need an encryption context between the client and the MSAQUE server (as well as the end-to-end context) but the simplified idea would be to send some of the already encrypted data rather "besides" the MASQUE tunnel connection than inside the encrypted tunnel. 

However, I don't think this necessarily should be in focus for the initial work of the group. Right now we should focus on the configuration/negotiation part to enable the forwarding of different services. 

Mirja