Re: [Masque] Proposed draft charter

[Paul Vixie <[e-mail]>]

On Monday, 27 January 2020 12:04:59 UTC Magnus Westerlund wrote:
> Hi Paul and Lars,
> (As individual, my AD role clearly have an conflict of interest situation
> here)

ty for your answer. mine is inline below.

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

you're right that my vision exceeds your described model. there are situations 
where e2e won't be allowed due to corporate policy, local law, or local 
regulation. it may be nec'y for the outbound proxy to see the request URI in 
order to determine whether to allow-direct, allow-via, or disallow.

historically (H1), the proxy had only two choices, allow-via or disallow. this 
led to the development of the HTTPS MiTM model, which is explicitly and 
intentionally voided by TLS 1.3 + ESNI. i wish to reestablish a corporate 
policy perimeter which does not depend on MiTM, and is a negotiation between 
the initiator and the proxy.

this negotiation would rely on secure proxy discovery and establishment of 
trust. this has to be fairly well automatable, because of IoT and ICS devices.

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

i am simultaneously heartened that your understanding of "an evolved model" is 
similar to mine for "trusted proxy discovery and connection negotiation" 
(above), and disheartened that it would apparently require a QUIC development 
restart, which i feel is not in the cards.

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

there are three levels of such access. SNI, URI, and content. in the use cases 
i predict (e.g., employee doing personal banking using company network) only 
the SNI and URI need to be known in order to yield a trusted "allow-direct" 
answer. for more sensitive managed private networks such as military or 
government, and for corporations under a regulatory regime that includes 
transparency for archival, the content would also have to be visible. in no 
case should this be possible without the initiators knowledge and consent, but 
in some cases the result will be "disallow" because the negotiation "failed".

> But, lets also try to answer Lars's question. Why not in QUIC WG. ...

that's not my area of expertise, so i'll remain silent as to that point.

-- 
Vixie