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

Re: HTTP/2 and Pervasive Monitoring

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Fri, 15 Aug 2014 18:54:01 +0000
To: Martin Thomson <martin.thomson@gmail.com>
cc: Erik Nygren <erik@nygren.org>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <7374.1408128841@critter.freebsd.dk>
In message <CABkgnnXc9Di3-eLSrbhFDTwGkPmmnig67x-3-t0fCTM3c2YTFQ@mail.gmail.com>
, Martin Thomson writes:
>On 15 August 2014 07:50, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

>> I was talking only conceptually here, the actual protocol mechanics
>> will be at least as tricky as HTTP/1 -> HTTP/2 upgrade.
>I've talked with several people about HTTP/1.1 and the mechanisms
>we've defined.  They are portable - in theory.

...and in theory that means that they will work in practice :-)

>Incidentally, the difference between good crypto and bad crypto here
>is that good crypto is fast and secure and bad crypto is just bad.

What is good and what is bad crypto, depends a LOT on what your
ephemeral lifetime requirement is,.

And incidentally, cryptographers have a very strong tendency to
forget that all crypto is ephemeral in the first place, because the
usually unstated requirement is that the ephemeral lifetime be
longer than the probable duration of the universe.

For the isolated problem of defeating PM, the ephemeral lifetime
requirement is a few seconds, reducing the customary 128+ bits
to something on the order of 32.

Good crypto which only lasts a couple of seconds would be terribly
bad crypto in almost any other context.

But conversely, a lot of crypto deemed bad or even "horrible" in
normal contexts will be perfectly good crypto for the purpose of
defeating PM.

I'm not taking a position on what specific algorithms would or
wouldn't be suitable here, but I will point out that it is much
more important that it does 10Gbit/s on commodity hardware, so
loadbalancers and such can keep up, than it be able to survive
systematic attack for more than few seconds.

If it wasn't because of the almost-always-known-plaintest property
of HTTP headers, a simple XOR with a 32bit random number would
be enough.

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.
Received on Friday, 15 August 2014 18:54:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC