On Nov 6, 2013, at 2:12 PM, Roberto Peon
<grmocg(_at_)gmail(_dot_)com<mailto:grmocg(_at_)gmail(_dot_)com>> wrote:
At least one of the questions (and probably two of 'em) for which we hummed was
unclear enough that I couldn't interpret it as a policy statement.
A lot of that was very generic statements that were bound to achieve consensus.
In particular: "The IETF should strive for e2e encryption even when there are
middleboxes in the path":
- encryption with/without privacy?
- encryption with/without authentication?
- do authorized/explicit middleboxes count?
This is too ambiguous for me to interpret in any meaningful way :/
In the context of the IETF, that has to mean encryption with authentication and
no authorized or explicit middleboxes.
As soon as you have authorized middleboxes (full disclosure, I was a co-author
of a TLS proxy draft [1] that got shot down in the TLS WG), you run into the
messy question of "authorized by whom?"
If I install Fiddler to analyze https traffic, that's a trusted proxy. If a
government agent installs such a proxy on my computer or on my home router,
it's still authorized, but not by me. It's hard to create a slot in the
protocol to insert an authorized intermediary that only the user would be able
to authorize. The browser vendor, the OS vendor, the employer, the ISP, the
malware developer and the national government are all likely to authorize such
a middlebox.
There is a flip side. By refusing to specify an authorized middlebox for the
protocol, we end up with all middleboxes being treated as equal. As an example,
TLS proxies have no standing in the protocol - they work by signing a
certificate on behalf of the server's domain name. Key pinning ([2]) detects
this middlebox and breaks the connection. But there are legitimate proxies, so
using a simple heuristic, browsers detect that a proxy exists, and disable the
key pinning protection. If there was a way in the protocol for the proxy to
identify itself, clients could then apply a policy that determined whether this
was the authorized middlebox (corporate firewall) or some other middlebox. As
it is, there are only two things that HPKP can prescribe: disconnect when faced
with any proxy, or allow when faced with any proxy.
Yoav
[1] http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01
[2] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08