W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Three More Proxy User Stories

From: Peter Lepeska <bizzbyster@gmail.com>
Date: Mon, 9 Dec 2013 10:27:57 -0500
Message-ID: <CANmPAYFNt=9iM5cwO9di2Gifo9Suybzy7g7afbYEpmVoNzRNXQ@mail.gmail.com>
To: Yoav Nir <synp71@live.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Comments inline...


On Mon, Dec 9, 2013 at 1:26 AM, Yoav Nir <synp71@live.com> wrote:

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

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

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?


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


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.


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

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.


> Thanks
>
> Yoav
>
>
Received on Monday, 9 December 2013 15:28:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC