Re: [Masque] Proposed draft charter

[Magnus Westerlund <[e-mail]>]

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