W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Mandatory encryption

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 19 Jul 2012 13:27:08 +1200
To: <ietf-http-wg@w3.org>
Message-ID: <ceec9f40bdb097db1c4ec9be151c71c4@treenet.co.nz>
On 19.07.2012 01:07, Patrick McManus wrote:
> On Wed, 2012-07-18 at 08:09 +0200, Willy Tarreau wrote:
>> On Tue, Jul 17, 2012 at 09:22:24PM -0400, Phillip Hallam-Baker 
>> wrote:
>> The issue with HTTP/2 will indeed be the same as with IPv6 : HTTP/2 
>> will
>> be deployed between the browser and the load balancer, and 
>> everything
>> behind will remain HTTP/1 due to the added nuisances of deploying 
>> 2.0
>> everywhere.
> Except we know that in the very near future SPDY adoption will have
> reached far more people than IPv6 ever has. So, unlike IPv6, there is 
> a
> big demand to solve the problems it addresses.

Huh. IPv6 has *reached* just about every end-user in eastern 
civilisation and a good portion of the western as well.

The annoying fact that there are IPv4-only barriers devices all over 
the Internet is not the users or content providers faults.

If HTTP/2 mandates encryption, compression or anything similar that 
raises the developer implementation workload significantly over HTTP/1 
then our efforts will face the same type of barriers with HTTP/1-only 
IDS, firewall and monitoring systems.

Remember we are *already* pretty much confirmed to be adding:
  * binary encoding - difficult to read on the wire, special new tools 
required to interpret it (and learn how to use), new library APIs to 
learn for parsing and generating messages.
  * multiplexing - flow control on that one will be an educational curve 
for most still stuck on the HTTP/1.0 paradigm (1.1 folks only get it 
slightly easier if they understand 1xx status flow control).
  * pipelining - already a difficult subject under HTTP1, making it 
mandatory to support is a good thing but does raise the learning curve.

Adding all these up and we have a noticable barrier to implementation. 
Placing *mandatory* encryption on top to raise the barrier even higher, 
particularly in places where it is clearly not necessary for security OR 
privacy is too much. As the Hulu folks have said, too much of a good 
thing is still too much.

>>  Almost nobody does IPv6 between LB and server nowadays, it's
>> added cost for no benefit.

You want to tell that to my customers. You (and most other users) not 
noticing just goes to show how well the middleware gateways and LB have 
been doing translating IPv4 to IPv6 and back again.

The networks over this *quarter* of the world (APNIC and increasingly 
RIPE NCC) are increasingly 'forced' to run IPv6 internally due to 
unavailability of IPv4 allocations and routinely do exactly as you 
suggest 'nobody' does: Run IPv6 between LB and server pool. The 
available IPv4 being reserved largely for use on the America-facing 
  Then there is the carrier-grade NAT situation for content providers. 
Bit of a no-chance there, but every attempt simply hides more IPv6 away 
from those of you in IPv4-only nets.

> of course spdy has lots of benefits. key difference :)

Received on Thursday, 19 July 2012 01:27:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC