Re: multiplexing -- don't do it

On Mon, Apr 2, 2012 at 2:08 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
> ------ Original Message ------
> From: "Mike Belshe" <mike@belshe.com>
> To: "Adrien W. de Croy" <adrien@qbik.com>
> Cc: "Amos Jeffries" <squid3@treenet.co.nz>;"ietf-http-wg@w3.org" <
> ietf-http-wg@w3.org>
> Sent: 3/04/2012 8:52:22 a.m.
> Subject: Re: multiplexing -- don't do it
>
>
>
> On Mon, Apr 2, 2012 at 1:43 PM, Adrien W. de Croy < <adrien@qbik.com>
> adrien@qbik.com> wrote:
>
>>
>> ------ Original Message ------
>> From: "Mike Belshe" <mike@belshe.com>mike@belshe.com
>>
>>
>>
>> On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries < <squid3@treenet.co.nz><squid3@treenet.co.nz>
>> squid3@treenet.co.nz> wrote:
>>
>>> On 1/04/2012 5:17 a.m., Adam Barth wrote:
>>>
>>> On Sat, Mar 31, 2012 at 4:54 AM, Mark Nottingham wrote:
>>>>
>>>>> On 31/03/2012, at 1:11 PM, Mike Belshe wrote:
>>>>>
>>>>> For the record - nobody wants to avoid using port 80 for new
>>>>>> protocols.  I'd love to!  There is no religious reason that we don't - its
>>>>>> just that we know, for a fact, that we can't do it without subjecting a
>>>>>> non-trivial number of users to hangs, data corruption, and other errors.
>>>>>>  You might think its ok for someone else's browser to throw reliability out
>>>>>> the window, but nobody at Microsoft, Google, or Mozilla has been willing to
>>>>>> do that…
>>>>>>
>>>>> Mike -
>>>>>
>>>>> I don't disagree on any specific point (as I think you know), but I
>>>>> would observe that the errors you're talking about can themselves be viewed
>>>>> as transient. I.e., just because they occur in experiments now, doesn't
>>>>> necessarily mean that they won't be fixed in the infrastructure in the
>>>>> future -- especially if they generate a lot of support calls, because they
>>>>> break a lot MORE things than they do now.
>>>>>
>>>>> Yes, there will be a period of pain, but I just wanted to highlight
>>>>> one of the potential differences between deploying a standard and a
>>>>> single-vendor effort.  It's true that we can't go too far here; if we
>>>>> specify a protocol that breaks horribly 50% of the time, it won't get
>>>>> traction. However, if we have a good base population and perhaps a good
>>>>> fallback story, we *can* change things.
>>>>>
>>>> That's not our experience as browser vendors.  If browsers offer an
>>>> HTTP/2.0 that has a bad user experience for 10% of users, then major
>>>> sites (e.g., Twitter) won't adopt it.  They don't want to punish their
>>>> users any more than we do.
>>>>
>>>> Worse, if they do adopt the new protocol, users who have trouble will
>>>> try another browser (e.g., one that doesn't support HTTP/2.0 such as
>>>> IE 9), observe that it works, and blame the first browser for being
>>>> buggy.  The net result is that we lose a user and no pressure is
>>>> exerted on the intermediaries who are causing the problem in the first
>>>> place.
>>>>
>>>> These are powerful market force that can't really be ignored.
>>>>
>>>
>>> So the takeway there is pay attention to the intermediary people when
>>> they say something cant be implemented (or won't scale reasonably).
>>>
>>
>> I agree we should pay attention to scalability - and we have.
>>
>> Please don't disregard that Google servers switched to SPDY with zero
>> additional hardware (the google servers are fully conformant http/1.1
>> proxies with a lot more DoS logic than the average site).  I know, some
>> people think Google is some magical place where scalability defies physics
>> and is not relevant, but this isn't true.  Google is just like every other
>> site, except much much bigger.   If we had a 10% increase in server load
>> with SPDY, Google never could have shipped it.  Seriously, who would roll
>> out thousands of new machines for an experimental protocol?  Nobody.  How
>> would we have convinced the executive team "this will be faster", if they
>> were faced with some huge cap-ex bill?  Doesn't sound very convincing, does
>> it?  In my mind, we have already proven clearly that SPDY scales just fine.
>>
>> But I'm open to other data.  So if you have a SPDY implementation and
>> want to comment on the effects on your server, lets hear it!   And I'm not
>> saying SPDY is free.  But, when you weigh costs (like compression and
>> framing) against benefits (like 6x fewer connections),  there is no
>> problem.  And could we make improvements still?  Of course.  But don't
>> pretend that these are the critical parts of SPDY.  These are the mice nuts.
>>
>>
>> For a forward proxy, there are several main reasons to even exist:
>>
>> a) implement and enforce access control policy
>> b) audit usage
>> c) cache
>>
>> you block any of these by bypassing everything with TLS, you have a
>> non-starter for corporate environments.  Even if currently admins kinda
>> turn a blind eye (because they have to) and allow port 443 through, as more
>> and more traffic moves over to 443, more pressure will come down from
>> management to control it.
>>
>> Best we don't get left with the only option being MITM.
>>
>
> In my talk at the IETF, I proposed a solution to this.
>
> Browsers need to implement SSL to trusted proxies, which can do all of the
> a/b/c that you suggested above.  This solution is better because the proxy
> becomes explicit rather than implicit.  This means that the user knows of
> it, and it IT guys knows of it.  If there are problems, it can be
> configured out of the system.  Implicit proxies are only known the the IT
> guy (maybe), and can't be configured out from a client.  The browser can be
> made to honor HSTS so that end-to-end encryption is always enforced
> appropriately.
>
> Further, proxies today already need this solution, even without SPDY.
>  Traffic is moving to SSL already, albeit slowly, and corporate firewalls
> can't see it today.  Corporate firewall admins are forced to do things like
> block facebook entirely to prevent data leakage.  But, with this solution,
> they could allow facebook access and still protect their IP.  (Or they
> could block it if they wanted to, of course).
>
> Anyway, I do agree with you that we need better solutions so that we don't
> incur more SSL MITM.  Many corporations are already looking for expensive
> SSL MITM solutions (very complex to rollout due to key management) because
> of the reasons I mention above, and its a technically inferior solution.
>
> So lets do it!
>
>
> I basically agree with all the above, however there is the ISP
> intercepting proxy to think about.
>
> Many ISPs here in NZ have them, it's just a fact of life when you're 150ms
> from the US and restricted bandwidth.  Pretty much all the big ISPs have
> intercepting caching proxies.
>
> There's just no way to make these work... period...
>
> unless the ISP is to
>
> a) try and support all their customers to use an explicit proxy, or
> b) get all their customers to install a root cert so they can do MITM.
>


> Maybe we need a better way to force a client to use a proxy, and take the
> pain out of it for administration.  And do it securely (just remembering
> why 305 was deprecated).
>

Do proxy pacs or dhcp work for this?

Note that we also need the browsers to honor HSTS end-to-end, even if we
turn on "GET https://".
Mike




> Adrien
>
>
>
>
>
>
>
> Mike
>
>
>
>
>>
>> Adrien
>>
>>
>>
>>
>> Mike
>>
>>
>>
>>> With plenty of bias, I agree.
>>>
>>> AYJ
>>>
>>>
>>
>