Dear Magnus/QUIC and Martin/MASQUE, On Wed, Sep 30, 2020 at 6:43 AM Lars Eggert <[email protected]> wrote:
> Hi, > > On 2020-9-30, at 14:27, Flinck, Hannu (Nokia - FI/Espoo) < > [email protected]> wrote: > ... > > > Also the question Qn-2 in LS is not well formulated either. What they > really ask is about avoidance of avoid multiple encryption layers that > occur in QUIC in QUIC tunneling. The motivation for their question is also > mentioned in the ATSSS-draft. And *maybe the question should be answered > by MASQUE WG instead*. > > * Well, they asked us, so we are answering. *And even when QUIC is > tunneled in QUIC, we are not chartered to standardize a method to disable > encryption for one of those QUICs. > Hannu and Lars are both right. Is there a better way for the IETF to react to a question that would have gone to QUIC before MASQUE was chartered, but would now be better addressed to MASQUE? We can send a liaison from QUIC to 3GPP, and 3GPP can send back the same question in a liaison to MASQUE in a month or two, but we're an engineering SDO and that seems like bad engineering :-) In the IETF 108 minutes for MASQUE at https://datatracker.ietf.org/doc/minutes-108-masque/, I see this (with no edits on my part) ## QUIC Proxying *Tommy Pauly* [Slides]( https://www.ietf.org/proceedings/108/slides/slides-108-masque-optimizing-proxies-for-quic-00 ) Tommy Pauly: No draft yet on this, but we're working on it Tommy Pauly: This is particularly interesting for multi-hop forward proxying like Tor. Tommy Pauly: "CONNECT-QUIC" is a placeholder here, separate from the question of whether to use one method or many. Tommy Pauly: The new mode here is "forwarding" instead of "tunneling". Martin Thomson: From what I've seen on the slides, I have serious reservations as to whether this is going to achieve the goals you've set. What are those goals? *Tommy Pauly: The goal is to allow multiple proxy hops for QUIC without* *encapsulation and encryption overhead for each hops. We don't have to keep* *adding DATAGRAM frames and reducing MTU and adding encryptions.* Martin Thomson: That's a reasonable goal, but I don't think this is going to work for a proxy that has to manage multiple connections. Did you say that the client sets the connection IDs that the proxy expects to use? Tommy Pauly: Whenever the client becomes aware of a connection ID, it informs the proxy and requires a confirmation before it will start using that connection ID. Eric Rescorla: I understand the performance objective, but I don't think I understand the security objective. You said "tor-like", but Tor has some extremely specific properties and I don't understand how this prevent private collusion. Tommy Pauly: It won't have the same security properties as a Tor-like thing, especially because you may see the same content going through on both sides of the proxy. You won't see more than if you were on path already. The goal is to get IP address obfuscation but we're not necessarily concerned about reconstructing the path if you can see all the links. Eric Rescorla: I think this needs a clearer threat model. Tommy Pauly: We're just trying to point out that this mode exists, and could be used when it's appropriate. Eric Rescorla: I'm trying to figure out whether this has interesting security properties. Tommy Pauly: Connection ID mapping is especially difficult when multiplexing connections onto a single client-proxy 5-tuple. Beyond collusion protection, we also need to make sure that you're not vulnerable to forwarding replayed packets. Ben Schwartz: This is not so similar to CONNECT-UDP or old-fashioned CONNECT, because it breaks out of the TLS stream. Recommend focusing on a non-HTTP proxy substrate like SOCKS-6. > Thanks, > Lars >
