Re: [Masque] Proposed draft charter

[Marcus Ihlar <[e-mail]>]

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 <[e-mail]> On Behalf Of Lars Eggert
Sent: den 27 januari 2020 14:28
To: Mirja Kuehlewind <mirja.kuehlewind=[e-mail]>
Cc: [e-mail]
Subject: Re: [Masque] Proposed draft charter

Hi,

On 2020-1-27, at 14:54, Mirja Kuehlewind <mirja.kuehlewind=[e-mail]> 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 point in the charter.

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