On Wed, Nov 6, 2013 at 2:39 PM, Yoav Nir <ynir(_at_)checkpoint(_dot_)com> wrote:
On Nov 6, 2013, at 2:12 PM, Roberto Peon <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.
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
[1] http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01
[2] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08