Re: [Masque] Proposed draft charter

[Mirja Kuehlewind <[e-mail]>]

Hi Lars,

see inline.

On 27.01.20, 14:28, "Lars Eggert" <[e-mail]> wrote:

    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] 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/
    
    > [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?

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

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

[MK] Yes and okay.

    
    Thanks,
    Lars