Subject: [Masque] Proposed draft charter

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 24 Jan 2020 23:29:21 +0000

Hi everybody,

as already indicated by David in his last mail, some of us worked on a proposed draft charter for a new group. Please find the text below and provide comments!

Thanks!
Mirja

---------------------------------
MASQUE draft charter text

Many network topologies lead to situations where transport protocol proxying is beneficial. For example: helping endpoints to communicate when end-to-end connectivity is not possible, applying additional encryption where desirable (such as a VPN), or accommodating differences in network segment characteristics (e.g. long paths such as satellite, or high-loss links). Many existing proxy solutions deployed today rely on transparent intermediation. However, an increasing amount of traffic is using QUIC, and QUIC's improved security model prevents transparent proxies. In order to allow transport protocol proxying when QUIC is in use, we will need a mechanism where at least one of the QUIC endpoints actively collaborates with the proxy. QUIC is a good candidate protocols for tunneling or forwarding this kind of traffic, as QUIC provides secure connection establishment, multiplexed streams, and connection migration. Further, use of HTTP/3 on top of QUIC enables HTTP-level proxying and caching.

This working group will work on MASQUE (Multiplexed Application Substrate over QUIC Encryption) - a framework that allows concurrently running multiple networking applications inside a QUIC connection. The MASQUE framework will specify the actions and processes for establishing tunneled proxy connectivity as well as a signaling protocol that is used between the endpoint(s) and the MASQUE server to negotiate and request proxy service capabilities and parameters, and realize services that require communication between endpoints and proxies. A proxy may provide simple forwarding with optional address translation only, or more advanced services like name resolution, multipath support, or assistance for congestion control on link segments with challenging characteristics, such as high loss or strongly varying delays.

As use-cases for deploying MASQUE have different security or performance requirements, the working group may define multiple MASQUE services for proxying to suit these disparate use-cases. In particular, some deployments may want to avoid double-encryption to reduce computational costs if the inner connection as well as the outer QUIC tunnel connection use encryption, while others might prefer to keep the double-encryption of user data to sure strong privacy guarantees. Such options will need to produce documentation of the resulting security and privacy properties.

Alongside the definition of the MASQUE framework, the group will further work on discovery mechanisms for MASQUE servers and which MASQUE services they support, taking into account deployment across network segments with different operability and end-user relationship characteristics.
 
Proxy services that extend the signaling of the base MASQUE protocol can be adopted by the group by creating a new milestone with AD review.
 
If MASQUE requires any extensions to existing protocols, the group will coordinate closely with the respective group responsible for maintaining that protocol, such as the HTTPBIS, QUIC, or TLS working groups.

Milestones

July 2021 MASQUE framework and base protocol to be submitted to the IESG for publication as PS
Nov 2021 Discovery mechanism for MASQUE servers to be submitted to the IESG for publication as PS
Nov 2021 [Example WG Item] Use Case specific extension to the MASQUE protocol be submitted to the IESG for publication as EXP or PS

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jan 2020 09:22:14 +0200

Hi,

what motivates a separate WG vs. doing this in the QUIC WG?

There are aspects of the charter - e.g., one-sided (transparent to the peer?) cooperation with middleboxes, double-encryption avoidance (does this translated to an "unencrypted" mode for QUIC?) - that could have a large impact on the base protocol. That suggests to me tight coordination with the base protocol is essential.

Thanks,
Lars

On 2020-1-25, at 1:29, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jan 2020 08:26:05 +0000

i mostly think the same, but i'm concerned about one aspect of H3 that may be 
sufficiently far from the core protocol to warrant special focus on the proxy, 
and that is the enterprise situation where the endpoint trusts the proxy to 
either carry the transaction for it, or to refer the endpoint to a native 
flow. use case, employee doing their banking from their corporate desktop 
during their lunch break. this isn't a well-loved scenario because it's so 
close to the nation-state authoritarian situation. but i'd like to explore it 
with a group of open minded others, and i think doing it inside the QUIC or 
HTTP WG would make for big distraction.

there is, separately and precedingly, the the process by which an endpoint 
would discover, and know whether or not to trust, an enterprise outbound 
proxy.

am i in the wrong basket?

vixie

re:

On Monday, 27 January 2020 07:22:14 UTC Lars Eggert wrote:
> There are aspects of the charter - e.g., one-sided (transparent to the
> peer?) cooperation with middleboxes, double-encryption avoidance (does this
> translated to an "unencrypted" mode for QUIC?) - that could have a large
> impact on the base protocol. That suggests to me tight coordination with
> the base protocol is essential.
> 
> Thanks,
> Lars

-- 
Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jan 2020 12:04:59 +0000

Hi Paul and Lars,
(As individual, my AD role clearly have an conflict of interest situation here)

Paul's question is something that needs to be discussed. This goes beyond the
security model I have envisioned for this work. 

So the most basic security model for this work would be to have a secured
connection (outer) between an endpoint (mostly the client) and the proxy. Then
run a end-to-end secure QUIC connection between client and server (inner). That
end-to-end connection can run either inside the client-proxy connection for
certain properties or in parallel for other set of properties. Then use the
client proxy connection for meta data exchange to accomplis things. This model
can be extended to use outer connections between proxies and proxy to server,
and in cases where desired to even have an onion model where client uses a set
of proxies but each proxy only see the next and previous hop. 

An evolved model would be to move the inner connection from a full blown QUIC
connection to something which is an object security model end-to-end between
client and server. This will require an chain of outer transport connections all
the way between client and server. However, it would enable certain use cases
that isn't possible in the first, like object caching. It also enables the
proxies to do a much better job transport wise and avoid head of line blocking
completely for inner object fragments and enable proxy level prioritizations,
which is not really possible in the first model. I do note this model will
require basically a new QUIC version as it will redefine the internals
significantly. 

Paul I am uncertain of exactly what you attempting to accomplish. I think in the
basic security model the client proxy connection can be used by the client to
disclose information like SNI (assuming ESNI otherwise) to the proxy as that
would allow policy recommendations that it appear you ask for. But, my
assumption for this work is that the proxy will by default have no access to
clear text content being transfered between endpoints. Any such access would
require an explicit disclosure of the security context by the client to the
proxy. 

But, lets also try to answer Lars's question. Why not in QUIC WG. I will not
dismiss that this could be part of the QUIC WG charter. However, I think writing
the charter like it is its own WG clarifieis what the intentions here are. I
also note that basic framwork is much more like SOCKS work, or the TURN work in
TRAM WG, but different than both to require its own work. Its primary part is
not actually changing QUIC, at least for the basic security model above. Then,
certain of the transport performance enhancement work will be how to interface
information between the proxy and the end-to-end QUIC connection. That work will
need interaction with the QUIC WG. Some things may even need QUIC extensions,
and such would then likely need to be developed in the QUIC WG. I think we
should discuss this more, and at a minimum clarify the interaction part. 

Cheers

Magnus Westerlund
(as individual)

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 27 Jan 2020 12:23:26 +0000

Hi Mirja, all,

Speaking as an individual:

>From reading the charter, it isn't clear to me whether avoidance of double
encryption is intended to be part of the MASQUE framework deliverable, or
seen as some other document(s) that would be proposed into a MASQUE WG or
some other WG?

The discussion on the list highlights some of complexity in this area. I
personally see a lot of value in developing a framework that does not
attempt to avoid the multiple levels of encryption problem initially; there
are several use cases that could benefit from a baseline capability to
tunnel congestion-controlled transports inside QUIC without the pitfalls of
nested congestion control.

Targeting a baseline, while letting double encryption avoidance continue in
parallel at its own rate (and own group of people) seems like one way to
structure such work. The charter isn't clear if that is the intent or if
there is a strong desire to solve both in unison.

Cheers
Lucas

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 27 Jan 2020 12:50:26 +0000

> seen as some other document(s) that would be proposed into a MASQUE WG or

My interest was primarily the obfuscation scheme whereby double encryption
is avoided, and traffic is simply made to look like QUIC.  e.g. a VPN.

DF

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 27 Jan 2020 12:54:57 +0000

Hi Lars,

I think Magnus already provide some good background on the security model for different scenarios for this part of the work. I would just like to quickly also reply to your two questions below:

On 27.01.20, 08:22, "Lars Eggert" <[email-masked]> wrote:

    Hi,

[MK] The focus of this new group will be a signaling protocol on top of QUIC in order to communicate with the proxy and instruct the proxy to tunnel and forward other (unaltered) traffic that may or may not use QUIC as the end-to-end transport protocol. I think any new protocols that "just" uses QUIC as a transport should be in a separate group. Of course there might a closer dependency on QUIC features for this proposed work than for other application protocols, however, having the specification of a completely new protocol for proxy signaling in the QUIC group would be a very high load. As Magnus says this work is probably more link SOCKS or TURN, depending how you look at it...
    
    There are aspects of the charter - e.g., one-sided (transparent to the peer?) cooperation with middleboxes, double-encryption avoidance (does this translated to an "unencrypted" mode for QUIC?)

[MK] So there will be no data send unencrypted. The questions is only if there are ways to remove one layer of encryption if there are two. I think we could/should actually further clarify this point in the charter.

[MK] As Magnus already described, there are different security models here. One could be closely connectd to the security model in QUIC and this work would need to be closely coordinated with the quic group or should potentially even be done in the quic group. Not sure if there could also be a solution that would be based on a smallish extension to quic only, however, if and which extensions could be specified outside the quic group (with tight review from the quic) is something the quic group should probably discuss and decide on at some point.

[MK] Then, I also see an option, as also indicated by Magnus, where  little or no changes to QUIC are needed. The idea here is that you basically send tunneled packets (that are potentially double-encrypted) as well as directly packets of the inner connection but without the outer encapsulation on the same 5-tuple in such a way that an outside observer however would assume that all packets below to the same connection and cannot distinguish which packets are encapsulated with the tunneling QUIC and which ones are not.

[MK] So far we don't have a fully fleshed proposal but people working on this charter believe that there are use cases where double-encryption could be a strong performance impact and we should discuss while doing this work if there is way also support a mode where double-encryption is avoided or at least performance impact are reduced. I see this rather as a requirement at the moment and a final decision if and where to do it depend on the proposed approach. Maybe that is also something to clarify in the charter.

 - that could have a large impact on the base protocol. That suggests to me tight coordination with the base protocol is essential.

[MK] I'd definitely say that in any case close coordination with the QUIC group is needed. Having a separate group would however make it possible to separate discussion on non-quic specific part a bit. Further, this is probably a question of what group of people would be involved in this work and I could imagine that there might additional people from other areas interested that currently are probably not directly active in the quic group.

Mirja

    Thanks,
    Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jan 2020 15:28:25 +0200

Hi,

On 2020-1-27, at 14:54, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> [MK] The focus of this new group will be a signaling protocol on top of QUIC in order to communicate with the proxy and instruct the proxy to tunnel and forward other (unaltered) traffic that may or may not use QUIC as the end-to-end transport protocol. I think any new protocols that "just" uses QUIC as a transport should be in a separate group.

I agree with that basic approach (that apps that just want to run on vanilla QUIC can be in their own WGs.)

I don't think that this is the case here, however. (Or I am misunderstanding the proposal, which is not unlikely...)

> Of course there might a closer dependency on QUIC features for this proposed work than for other application protocols, however, having the specification of a completely new protocol for proxy signaling in the QUIC group would be a very high load. As Magnus says this work is probably more link SOCKS or TURN, depending how you look at it...

It might be helpful to see an initial solution candidate, so that complexity could be assessed.

> [MK] So there will be no data send unencrypted. The questions is only if there are ways to remove one layer of encryption if there are two. I think we could/should actually further clarify this poi…

And this is why I don't think this is just an application using QUIC. Because the intend seems to be to change the security model of QUIC.

There is a client, a proxy, and a server in your scenario. "No data is send unencrypted" does not necessarily mean that the data is end-to-end encrypted between the client and server.

In the double-encryption case, you'd have one TLS session between the client and the proxy, and another one between the client and the server, right? Which one would be eliminated to avoid the double encryption? Would clients need to ship with unencrypted QUIC stacks and need to trust that their proxy throws on the crypto for them?

> [MK] So far we don't have a fully fleshed proposal but people working on this charter believe that there are use cases where double-encryption could be a strong performance impact and we should discuss while doing this work if there is way also support a mode where double-encryption is avoided or at least performance impact are reduced.

The performance impact at a (double-encrypting) proxy is exactly what it is for a QUIC endpoint, which at the moment depends on how good your AES routines are, and in the future may well become close to zero (when crypto offload becomes available). We're at the moment seeing measurements of ~5Gb/s/core from several different QUIC stacks, so 20 cores (= 1 CPU) give you 100G, which seems OK to me.

> I see this rather as a requirement at the moment and a final decision if and where to do it depend on the proposed approach. Maybe that is also something to clarify in the charter.

To me, this is one of the key questions. I'm opposed to doing any variant of QUIC in the IETF that doesn't have end-to-end encryption. Whether this is in scope or not IMO needs to be clarified now rather than later.

Thanks,
Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 27 Jan 2020 14:34:10 +0000

Hi Lars,

see inline.

On 27.01.20, 14:28, "Lars Eggert" <[email-masked]> wrote:

    Hi,

    

[MK] Two candidates for the base signaling protocol are:
https://datatracker.ietf.org/doc/draft-schinazi-masque/
https://datatracker.ietf.org/doc/draft-piraux-quic-tunnel/

    
    
    In the double-encryption case, you'd have one TLS session between the client and the proxy, and another one between the client and the server, right? Which one would be eliminated to avoid the double encryption?

[MK] Only the outer client to proxy connection would be "eliminated".

[MK] I could see future work on QUIC where there are three TLS connections - client to proxy, client to server, as well as proxy to server. In this case I could imagine a quic variant where the inner quic still supports end-to-end encryption for any user data and at the same time enables closer interaction with a trusted proxy for transport optimization. However, I agree that such an approach should probably be done within the QUIC group (and then just be only used by a MASQUE setup). We can make that more clear in the charter (but need to figure out how to phrase that correctly).

Would clients need to ship with unencrypted QUIC stacks and need to trust that their proxy throws on the crypto for them?

[MK] As I just said for the current charter I think that should be excluded and we can find a way to make that clear.

[MK] There are two impacts: processing power and per packet overhead. We did a very quick test with multiple layer of TLS (on top of one TCP connection) and saw a significant decrease. Of course as you said this will get better but the overhead could also be reduce by some form of compression, however, if there is a good way to reduce this even more or get rid of it completely, this could still be very import for various use cases, especially when the client is on a mobile device (to increasebattery life).

[MK] Yes and okay.

    Thanks,
    Lars

---

From: Marcus Ihlar <[email-masked]>
Date: Mon, 27 Jan 2020 14:37:01 +0000

Hi,

" There is a client, a proxy, and a server in your scenario. "No data is send unencrypted" does not necessarily mean that the data is end-to-end encrypted between the client and server.

In the double-encryption case, you'd have one TLS session between the client and the proxy, and another one between the client and the server, right? Which one would be eliminated to avoid the double encryption? Would clients need to ship with unencrypted QUIC stacks and need to trust that their proxy throws on the crypto for them?"

As I would like to understand it the most straight forward way to avoid double encryption would be to use the MASQUE server as a UDP proxy or TURN server of sorts. A client and a MASQUE server establish a connection where feature negotiation and other information is exchanged. If double encryption is to be avoided, the client establishes end-to-end encrypted QUIC connections over the same 5-tuple as the client-proxy connection. Instructions to the proxy on where to forward, how to differentiate connections or any other required information would be sent on the client-proxy connection. 
This should have no impact on the QUIC security model.

Marcus

-----Original Message-----
From: Masque <[email-masked]> On Behalf Of Lars Eggert
Sent: den 27 januari 2020 14:28
To: Mirja Kuehlewind <mirja.kuehlewind=[email-masked]>
Cc: [email-masked]
Subject: Re: [Masque] Proposed draft charter

Hi,

Thanks,
Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jan 2020 14:41:41 +0000

Hi Lucas,
(As individual)

I think you are right that the charter should be clarified that efficiency
improvements in any form to reduce the overhead of re-encryption is definitely a
seperate parallel work item. One that I think by its nature needs to be optional
to use. And it can be discussed in parallel. 

I can't see how any solution could be other than optional as it will have some
impact on the security properties. The privacy protection against certain agents
will be impacted. And I think it is very important that the resulting properties
are very well described by such a solution. In fact a WG may in the end even
arrive at the conclusion that such a solution is not worth publishing. 

Cheers

Magnus

On Mon, 2020-01-27 at 12:23 +0000, Lucas Pardue wrote:
> encryption is intended to be part of the MASQUE framework deliverable, or seen
> as some other document(s) that would be proposed into a MASQUE WG or some
> other WG?
> 
> personally see a lot of value in developing a framework that does not attempt
> to avoid the multiple levels of encryption problem initially; there are
> several use cases that could benefit from a baseline capability to tunnel
> congestion-controlled transports inside QUIC without the pitfalls of nested
> congestion control. 
> 
> structure such work. The charter isn't clear if that is the intent or if there
> is a strong desire to solve both in unison.
> 
> Cheers
> Lucas
> 
> On Mon, Jan 27, 2020 at 12:05 PM Magnus Westerlund <
> magnus.westerlund=[email-masked]> wrote:
> > Hi Paul and Lars,
-- 
Cheers

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jan 2020 16:54:28 +0200

Hi,

> [MK] Only the outer client to proxy connection would be "eliminated".

thanks for clarifying.

So if the concern is for the client-to-proxy part, why does this outer connection need to be QUIC at all? (I think this is also what Marcus described in his reply, i.e., that you could simply run a non-QUIC protocol between the client and proxy on the same five-tuple.)

> [MK] As I just said for the current charter I think that should be excluded and we can find a way to make that clear.

That would be very helpful.

> [MK] There are two impacts: processing power and per packet overhead.

The two are directly related?

> We did a very quick test with multiple layer of TLS (on top of one TCP connection) and saw a significant decrease.

The decrease should be pretty much 50% if you use the same AES cipher. If you use something else (= non-AES) that doesn't have CPU support, the overhead will be much higher of course.

> Of course as you said this will get better but the overhead could also be reduce by some form of compression, however, if there is a good way to reduce this even more or get rid of it completely, this could still be very import for various use cases, especially when the client is on a mobile device (to increase battery life).

You can use a non-QUIC tunnel protocol between the client and proxy, without encryption.

But the proposed charter talks about wanting to use QUIC as this tunneling protocol, which again makes me wonder how double-encryption here is supposed to be avoided without changing the QUIC security model.

Lars

---

From: Marcus Ihlar <[email-masked]>
Date: Mon, 27 Jan 2020 15:27:57 +0000

-----Original Message-----
From: Masque <[email-masked]> On Behalf Of Lars Eggert
Sent: den 27 januari 2020 15:54
To: Mirja Kuehlewind <[email-masked]>
Cc: [email-masked]
Subject: Re: [Masque] Proposed draft charter

Hi,

thanks for clarifying.

[MI]  One reason for the client-proxy communication to be QUIC-based is that it would allow for both the double encrypted tunneling and the UDP-forwarding modes. 
Also, it is probably a good idea from both privacy and deployment perspectives that the client-proxy communication isn't easy to distinguish from standard QUIC traffic. 

Marcus

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 27 Jan 2020 15:42:53 +0000

Hi Lars, hi all,

see below.

On 27.01.20, 16:27, "Marcus Ihlar" <[email-masked]> wrote:

    -----Original Message-----
    From: Masque <[email-masked]> On Behalf Of Lars Eggert
    Sent: den 27 januari 2020 15:54
    To: Mirja Kuehlewind <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Masque] Proposed draft charter
    
    Hi,

    thanks for clarifying.

[MK] Yes, these are the most important points. The initial use case for MASQUE was obfuscation - so in that case the goal is trying to make MASQUE look as much as possible like any other QUIC traffic on the wire - but there are actually more use cases were the same kind of proxy/tunnel setup would be beneficial so we extended the scope in the proposed charter still including obfuscation as one case. When using QUIC, it is especially nice that different QUIC streams within one connection can be used to forward traffic over the same proxy to different target servers (while e.g. SOCKS would use a separate port for each connection which is then of course visible on the wire), hiding information about the existing of these different connections completely from the respective network segment.

[MK] Further QUC provides build in encryption and authentication. While there are cases were double-encryption of the end-to-end traffic should be avoided, any communication with the proxy directly must be encrypted of course.

[MK] I would say QUIC is simply a nice fit for a transport protocol underneath the proxy protocol we want to work on, providing the features needed for the proxy service like multiplexing, encryption/authentication, and optional datagram support. So why not using it __ Further as the expectation is that in many cases this will especially be used to tunnel quic within quic, you may need to implement only one stack on the client and I think this also open potentials for further optimization in the future.

Mirja