Re: [Masque] Proposed draft charter

[Lucas Pardue <[e-mail]>]

Hi Mirja, all,

Speaking as an individual:

>From reading the charter, it isn't clear to me whether avoidance of double
encryption is intended to be part of the MASQUE framework deliverable, or
seen as some other document(s) that would be proposed into a MASQUE WG or
some other WG?

The discussion on the list highlights some of complexity in this area. I
personally see a lot of value in developing a framework that does not
attempt to avoid the multiple levels of encryption problem initially; there
are several use cases that could benefit from a baseline capability to
tunnel congestion-controlled transports inside QUIC without the pitfalls of
nested congestion control.

Targeting a baseline, while letting double encryption avoidance continue in
parallel at its own rate (and own group of people) seems like one way to
structure such work. The charter isn't clear if that is the intent or if
there is a strong desire to solve both in unison.

Cheers
Lucas

On Mon, Jan 27, 2020 at 12:05 PM Magnus Westerlund <magnus.westerlund=
[e-mail]> wrote:

> Hi Paul and Lars,
> (As individual, my AD role clearly have an conflict of interest situation
> here)
>
>
> Paul's question is something that needs to be discussed. This goes beyond
> the
> security model I have envisioned for this work.
>
> So the most basic security model for this work would be to have a secured
> connection (outer) between an endpoint (mostly the client) and the proxy.
> Then
> run a end-to-end secure QUIC connection between client and server (inner).
> That
> end-to-end connection can run either inside the client-proxy connection for
> certain properties or in parallel for other set of properties. Then use the
> client proxy connection for meta data exchange to accomplis things. This
> model
> can be extended to use outer connections between proxies and proxy to
> server,
> and in cases where desired to even have an onion model where client uses a
> set
> of proxies but each proxy only see the next and previous hop.
>
> An evolved model would be to move the inner connection from a full blown
> QUIC
> connection to something which is an object security model end-to-end
> between
> client and server. This will require an chain of outer transport
> connections all
> the way between client and server. However, it would enable certain use
> cases
> that isn't possible in the first, like object caching. It also enables the
> proxies to do a much better job transport wise and avoid head of line
> blocking
> completely for inner object fragments and enable proxy level
> prioritizations,
> which is not really possible in the first model. I do note this model will
> require basically a new QUIC version as it will redefine the internals
> significantly.
>
> Paul I am uncertain of exactly what you attempting to accomplish. I think
> in the
> basic security model the client proxy connection can be used by the client
> to
> disclose information like SNI (assuming ESNI otherwise) to the proxy as
> that
> would allow policy recommendations that it appear you ask for. But, my
> assumption for this work is that the proxy will by default have no access
> to
> clear text content being transfered between endpoints. Any such access
> would
> require an explicit disclosure of the security context by the client to the
> proxy.
>
> But, lets also try to answer Lars's question. Why not in QUIC WG. I will
> not
> dismiss that this could be part of the QUIC WG charter. However, I think
> writing
> the charter like it is its own WG clarifieis what the intentions here are.
> I
> also note that basic framwork is much more like SOCKS work, or the TURN
> work in
> TRAM WG, but different than both to require its own work. Its primary part
> is
> not actually changing QUIC, at least for the basic security model above.
> Then,
> certain of the transport performance enhancement work will be how to
> interface
> information between the proxy and the end-to-end QUIC connection. That
> work will
> need interaction with the QUIC WG. Some things may even need QUIC
> extensions,
> and such would then likely need to be developed in the QUIC WG. I think we
> should discuss this more, and at a minimum clarify the interaction part.
>
> Cheers
>
> Magnus Westerlund
> (as individual)
>
>
> On Mon, 2020-01-27 at 08:26 +0000, Paul Vixie wrote:
> > i mostly think the same, but i'm concerned about one aspect of H3 that
> may be
> > sufficiently far from the core protocol to warrant special focus on the
> > proxy,
> > and that is the enterprise situation where the endpoint trusts the proxy
> to
> > either carry the transaction for it, or to refer the endpoint to a
> native
> > flow. use case, employee doing their banking from their corporate
> desktop
> > during their lunch break. this isn't a well-loved scenario because it's
> so
> > close to the nation-state authoritarian situation. but i'd like to
> explore it
> > with a group of open minded others, and i think doing it inside the QUIC
> or
> > HTTP WG would make for big distraction.
> >
> > there is, separately and precedingly, the the process by which an
> endpoint
> > would discover, and know whether or not to trust, an enterprise outbound
> > proxy.
> >
> > am i in the wrong basket?
> >
> > vixie
> >
> > re:
> >
> > On Monday, 27 January 2020 07:22:14 UTC Lars Eggert wrote:
> > > Hi,
> > >
> > > what motivates a separate WG vs. doing this in the QUIC WG?
> > >
> > > 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?) - that could have a
> large
> > > impact on the base protocol. That suggests to me tight coordination
> with
> > > the base protocol is essential.
> > >
> > > Thanks,
> > > Lars
> >
> > --
> > Paul
> >
> >
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>