Subject: Three More Proxy User Stories

From: Peter Lepeska <[email-masked]>
Date: Sun, 8 Dec 2013 18:06:54 -0500

Interested in feedback on the following proxy user stories to be added to
the current list here:
https://github.com/http2/http2-spec/wiki/Proxy-User-Stories.

Adam's Strictly Confidential Traffic
Adam is the enterprise webmail administrator for company A, which
prioritizes corporate confidentiality and information assurance above all
else. Adam therefore would like to prevent all proxies from decrypting
corporate webmail traffic regardless of any side effects this might cause.

Eve's Access Blocking Enterprise Proxy
Eve, the administrator of a proxy deployed at the edge of company B's
network, refuses to allow any traffic in or out of the network that cannot
be inspected. At the same time, Eve would like to avoid the potential
liability involved in viewing another firm's confidential traffic. If a
user on company B's network also has a webmail account from a company that
has a strict confidentiality policy similar to company A's, Eve would
prefer to prevent access to that webmail server from within company B than
to decrypt that traffic.

Darlene's Content Server Respecting Proxy
Darlene, the executive at the mobile provider mentioned in the above link,
would like to optimize mobile user traffic which requires decryption but
would also like to avoid the potential liability of decrypting traffic
to/from content owners with strict confidentiality policy similar to
company A's. Darlene would like to decrypt only that traffic for which the
content owners have not explicitly denied consent to decrypt.

Thanks,

Peter

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Dec 2013 08:26:19 +0200

On 9/12/13 1:06 AM, Peter Lepeska wrote:
> Interested in feedback on the following proxy user stories to be added 
> to the current list here: 
> prioritizes corporate confidentiality and information assurance above 
> all else. Adam therefore would like to prevent all proxies from 
> decrypting corporate webmail traffic regardless of any side effects 
> this might cause.

With today's MitM proxies, the server side cannot opt out. We can design 
a protocol that allows the server to opt out, but to get a guarantee of 
the lack of proxies, we'd need to detect and block MitM proxies. There 
are ways of doing this, but as long as you can get people to install CA 
certificates and as long as browsers disable key pinning when faced with 
a locally-signed certificates, MitM will continue to work.
> network, refuses to allow any traffic in or out of the network that 
> cannot be inspected. At the same time, Eve would like to avoid the 
> potential liability involved in viewing another firm's confidential 
> traffic. If a user on company B's network also has a webmail account 
> from a company that has a strict confidentiality policy similar to 
> company A's, Eve would prefer to prevent access to that webmail server 
> from within company B than to decrypt that traffic.

Wouldn't liability be addressed by installing a product that doesn't 
show the cleartext to humans or store plaintext? or by having in place 
procedures to avoid humans seeing stuff they don't need?

The way you phrase the last sentence implies that company A just emits a 
policy, and company B enforces it. I would rather make it possible for 
company A to enforce this. Ethical proxies might honor such a request , 
but rogue ones would not. OTOH, ethical proxies would also implement the 
new protocol that allows company A to really opt out.
> Darlene, the executive at the mobile provider mentioned in the above 
> link, would like to optimize mobile user traffic which requires 
> decryption but would also like to avoid the potential liability of 
> decrypting traffic to/from content owners with strict confidentiality 
> policy similar to company A's. Darlene would like to decrypt only that 
> traffic for which the content owners have not explicitly denied 
> consent to decrypt.
>
Ah, so we need a way for the server to signal the client to refuse to 
cooperate with proxies, and proxies that only do caching can allow both 
CONNECT and GET.

Thanks

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Dec 2013 08:30:21 +0200

Thanks

Yoav

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 9 Dec 2013 10:27:57 -0500

Comments inline...

On Mon, Dec 9, 2013 at 1:26 AM, Yoav Nir <[email-masked]> wrote:

>> the current list here: https://github.com/http2/
>> http2-spec/wiki/Proxy-User-Stories.
>>
> With today's MitM proxies, the server side cannot opt out. We can design a
> protocol that allows the server to opt out, but to get a guarantee of the
> lack of proxies, we'd need to detect and block MitM proxies. There are ways
> of doing this, but as long as you can get people to install CA certificates
> and as long as browsers disable key pinning when faced with a
> locally-signed certificates, MitM will continue to work.

I agree with you but to the extent that enterprises like Eve's company B
below actually want to respect company A's policy, many enterprises will
adopt an explicit, trusted proxy over MITM. Our goal should be the protocol
supports all legitimate uses of proxies so that MITM becomes something only
bad actors have to do. Lastly, with cert pinning and DANE, it's not hard to
imagine a future where MITM will not continue to work. We should design the
protocol with that future in mind.

> Wouldn't liability be addressed by installing a product that doesn't show
> the cleartext to humans or store plaintext? or by having in place

Yes but then it comes back to a position of trust. Better would be if the
protocol itself guaranteed that the proxy could not decrypt without the
content server's consent. Don't you think?

> company A to enforce this. Ethical proxies might honor such a request , but
> rogue ones would not. OTOH, ethical proxies would also implement the new
> protocol that allows company A to really opt out.

Then my wording is confusing because I completely agree. The protocol
should allow for any node to refuse and should prevent the proxy from
decrypting when either the user or the content server says no.

>> link, would like to optimize mobile user traffic which requires decryption
>> but would also like to avoid the potential liability of decrypting traffic

Yes I think we do. Note that the "any node refusal" proposal I posted to
the list provides this functionality, as well as the functionality needed
to prevent proxies from decrypting without getting consent from the content
server.