Re: Encouraging a healthy HTTP/2 ecosystem

On Tue, Jul 1, 2014 at 4:07 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <CAA4WUYjHU__T9TT868mory=szszgXH3SCbod+F7=
> qEN--D8zbg@mail.gmail.com>, =?UTF-8?B?V2lsbGlhbSBDaGF
> uICjpmYjmmbrmmIwp?= writes:
>
> >Hm, I don't follow. I'm not sure if we disagree in our logical
> conclusions,
> >or that we're starting from different premises and have different
> >fundamental assumptions. Let me try the latter. I assume that the
> inability
> >to reliably deploy new TCP options (due to middlebox interference) is a
> bad
> >thing. Do you disagree with this?
>
> A bad analogy is like a wet screwdriver:  TCP options are not
> information carrying (unless you're truly evil that is...)
>

I'm confused. I don't understand why you think this is a bad analogy. What
information can a HTTP/2 extension carry that a TCP option can't?


>
> The reason many of the MITM proxies are there, is to filter out
> or prevent information not in compliance with a particular policy.
>
> Do you think that policy normally is going to have "allow through
> anything I don't understand" clause ?
>
> Have you not noticed how many "guest" WLANs only allow traffic on
> port 80 and 443, but not, for instance on port 22 ?


> What makes you think HTTP/2 is going to escape that mindset ?


> If your attempt to force negotiation of random extensions through
> blackmail methods succeeds, it would amount to a "Get out of jail
> cards" for any HTTP content filter that bows to your mob rule.
>
> Do you seriously think the library, school, jail or country (UK:
> I'm looking at you!) would instantly see the errors of their ways
> and remove their illadvised filters ?
>
> I think they'll just ban HTTP/2 from their network until they can
> filter it, and that filter is going to nix anything not on its
> white-list, no matter what you would like.


> There are never any easy techical fixes for hard political problems.
>

Great. I think we're making progress here on the core discussion. Yes, I
think we agree that the current state of things is that many ports are
unusable due to filtering proxies and the like. Therefore, more and more
protocols are getting tunneled over port 80 and port 443, and they're
moving up the stack. We're doing multiplexing in the application layer
since we've been unable to deploy multiplexing at a lower layer. It sounds
to me like you think that the inability to deploy new TCP options is
somewhat unfortunate, but it's the best reality we can hope for because
"There are never any easy technical fixes for hard political problems."

My assertion is that this situation is unacceptable. You're right, for
political / compliance reasons, proxies are going to be there and do these
things that ossify our protocols and force us to tunnel higher up the stack
and develop way more cruft in our protocol stack. I do think that we should
fight this. If MITM proxies outright drop ALPN from the negotiation,
thereby disabling HTTP/2, then so be it. I think it's better to let those
networks fall behind the rest of the internet than force the vast majority
of the internet into the lowest common denominator. I'd rather pick this
battleground here and now, rather than continuing to tunnel more complexity
higher up the stack every time we want to deploy new changes without having
to update all intermediaries on the internet.


>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>