On Wed, Nov 6, 2013 at 2:39 PM, Yoav Nir <ynir@xxxxxxxxxxxxxx> wrote:
A lot of that was very generic statements that were bound to achieve consensus.On Nov 6, 2013, at 2:12 PM, Roberto Peon <grmocg@xxxxxxxxx> 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.
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.
Note that from what I've heard in various interactions this week, this is not well understood.
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.
In my little world I mean that the sender authorizes the recipient, which would be true of each side of a full-duplex session, but 'authorization' on its own without further clarification is ambiguous on its own, agreed.
-=R
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