Re: [Masque] Proposed draft charter

[Lars Eggert <[e-mail]>]

Hi,

On 2020-1-27, at 16:34, Mirja Kuehlewind <[e-mail]> wrote:
> [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.)

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

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