Re: [Masque] Proposed draft charter

[Magnus Westerlund <[e-mail]>]

Hi Lucas,
(As individual)

I think you are right that the charter should be clarified that efficiency
improvements in any form to reduce the overhead of re-encryption is definitely a
seperate parallel work item. One that I think by its nature needs to be optional
to use. And it can be discussed in parallel. 

I can't see how any solution could be other than optional as it will have some
impact on the security properties. The privacy protection against certain agents
will be impacted. And I think it is very important that the resulting properties
are very well described by such a solution. In fact a WG may in the end even
arrive at the conclusion that such a solution is not worth publishing. 

Cheers

Magnus


On Mon, 2020-01-27 at 12:23 +0000, Lucas Pardue wrote:
> 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]
> > ----------------------------------------------------------------------
> > 
> > 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------