Re: multiplexing -- don't do it

Hi Mike,

On Fri, Apr 06, 2012 at 03:34:46PM +0000, Mike Belshe wrote:
> Once again - the people arguing against encryption are the people that want
> to exploit the user's data transmission stream for their own personal gain.

I disagree with your view here. I'm against mandatory encryption because there
are many places where it's not *needed* (eg: in the backoffice). And having two
different protocols for the same thing seems like the wrong solution to me,
while the model we currently have where HTTP is the framing protocol which
uses a transport whether it's encrypted or not ensures that encryption is used
only where appropriate.

Also, I know you disagree with me on the point of the performance cost, but I
have some haproxy users forwarding 10 Gbps of data 24*7 on a single machine by
relying on TCP splicing which consists in avoiding memory copies. These data
are files exchanged between some hosts and that are encrypted/decrypted on the
user's PC, which means that encrypting the transport just adds a useless second
encryption. You can forward at 10 Gbps right now on a single machine between 25
and 50% CPU. By simply switching from splice() to recv()+send(), you double the
CPU consumption. By adding decryption and encryption on top of that, you always
add more work than just recv()+send(), even if you're using crypto accelerators
etc... Forcing these services to apply encryption to data that are already
stored encrypted and resulting in a significant increase in infrastructure
costs is not going to help HTTP2 adoption at all, instead it will fragment the
web.

As we discussed last week, I'm sure that once we get HTTP to work over UDP,
it will be much cheaper to perform point-to-point encryption because it's
much cheaper to offload datagram encryption than stream encryption (basically
the NICs will do it for free). But doing encryption over TCP is expensive, at
least as much as several memcpy() of the same buffers, which precisely is what
we try to avoid as much as possible at high bit rates.

> If we want the Internet to be protect users - encrypt it.

Remember again, right now people who lose money on their bank account on
the Internet are already using end-to-end encryption. The issue has much
more to do with malware running on their host, and fortunately the issue
is less important in corporate networks because these malware are not
commonly allowed to communicate to the C&C server over HTTPS there !

If you want to protect internet users, do your best to stop malware !

> It's a simple choice:  users vs interceptors.

Interceptors are bad but they exist right now in part because of the lack
of ability to securely connect to a mandatory proxy. This certainly needs
to be addressed. They also exist because at some places it's not easy to
deploy a proxy configuration (eg: your smartphone might not support having
one in 3G, so your operator installs an accelerator to "improve" your
browsing experience).

We need to think why something which currently is an opt-in isn't proposed
to end users before trying to block the features that people had to invent
to solve this issue in the dirtiest way. Otherwise we'll fail again and
we'll see them invent even dirtier tricks to get the work done.

Regards,
Willy

Received on Friday, 6 April 2012 19:38:15 UTC