Re: [Masque] Proposed draft charter

[Mirja Kuehlewind <[e-mail]>]

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" <[e-mail]> wrote:

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

[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
    
    On 2020-1-25, at 1:29, Mirja Kuehlewind <mirja.kuehlewind=[e-mail]> wrote:
    > 
    > 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
    > 
    > 
    > 
    > 
    > --
    > Masque mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/masque