Re: new version trusted-proxy20 draft

On 18/02/2014 14:29, "Patrick McManus" <pmcmanus@mozilla.com<mailto:pmcmanus@mozilla.com>> wrote:
On Tue, Feb 18, 2014 at 5:16 AM, Salvatore Loreto <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:
On Feb 17, 2014, at 4:00 PM, Patrick McManus <pmcmanus@mozilla.com<mailto:pmcmanus@mozilla.com>> wrote:
This has the effect of signaling to an on path observer which transactions, in a large stream of them, will not be able to detect a MITM interaction. I'm not in favour.
The draft proposal to define "h2clr" for http traffic does not make the environment more prone to stealthy MITMs then just having "h2"

Assume the traffic has a mix of resources on port 443 using TLS. some will insist on strong TLS semantics (i.e. https) and some that will not (http). When blocked by an attacker the strong ones throw a visible error and the weak ones do something like fall back to cleartext http/1. The attacker does not want to be detected via visible error.

If all of those transactions are labeled "h2" then an active attacker has to guess which flows can be attacked without being detected. The risk  of getting it wrong is a barrier to the attack. All the better if the transactions are muxxed together into the same TLS connection.

Splitting them into 2 connections with 2 different ALPN tokens is pretty much labeling one of them "mess with me". Which is also pretty much the point of your proposal afaict - you're just doing it on behalf of a firewall instead of someone installing an illicit fiber tap.

The threat that you see is an undetectable downgrade (2.0 overTLS => cleartext 1.x), correct?

In fact, that can actually happen when using the “captive proxy” as described in Section 3.2, whereas the mechanism that uses the proxy certificate (3.1) is robust.

I think that the “captive proxy” could be hammered a bit to counter the downgrade attack — e.g. by forcing the TLS handshake to proceed up to the point where the trusted proxy has sent its certificate to the browser, before aborting TLS and restarting with cleartext HTTP/1.x — or maybe it could just be removed, or harmonised with 3.1.

Anyway, stepping back for a moment from the actual mechanics described by Sal, to me the basic principles on which this proposal is based are sound:

  *   the service is optional;
  *   the choice of using the service is user-driven with clear opt-in/out flow;
  *   the trusted proxy must provide cogent evidence about its identity, so it’s not easy to impersonate it;
  *   there is a clear path for establishing the trust relationship;
  *   it should be easy to implement and deploy.

So, this is possibly the most promising solution I’ve heard in terms of balance between the user needs & rights, and the network operators interests.
That’s why I’d hope we do not shelve it in a hurry.

Cheers