Re: I-D Action: draft-ietf-httpbis-tunnel-protocol-00.txt

[Martin Thomson <[e-mail]>]

On 20 August 2014 21:50, Adam Rice <[e-mail]> wrote:
> As a client, why would I add a header to my request that is going to cause
> the proxy to block it? What is the benefit to the user?

I'm going to give a different answer to the one Amos gave.  You can
read the background, including the recorded discussion from the last
IETF meeting for more on the subject.

In WebRTC, browsers will do this because they want to be good network
citizens and sometimes that means asking nicely.  Applications don't
get that privilege.

And this isn't always about a block/don't block binary decision.
Sometimes the information can let the proxy make better choices about
how it treats the data.  Realtime media over these tunnels (the
original motivating use case) has somewhat different requirements to
other types of traffic.  Knowledge about applications can help the
proxy make better decisions.

As I've said privately to others when the same point was raised, the
use of cleartext markers in the context of intermediary blocking is a
topic that was discussed at some length when the TLS working group
chose ALPN over NPN.  We could re-run those arguments, and I'm sure
that we'd have a ball in the process, but that's wasteful.  This
document really doesn't change the dynamic at all.  If you choose not
to send this, then send ALPN, then that's just forcing the proxy to do
extra work to discover what you are doing (i.e., it looks at your TLS
ClientHello once the tunnel is active).

If you are suppressing ALPN, then you suppress this too.  I don't
think that's in question.