Re: HTTP/2 and Pervasive Monitoring

"Poul-Henning Kamp" <phk@phk.freebsd.dk> Sun, 17 August 2014 07:36 UTC

Resent-Date: Sun, 17 Aug 2014 07:32:47 +0000
Resent-Message-Id: <E1XIuxL-0002RW-Ri@frink.w3.org>
To: Eliot Lear <lear@cisco.com>
cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
In-reply-to: <53F0496A.9040307@cisco.com>
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
References: <38BD57DB-98A9-4282-82DD-BB89F11F7C84@mnot.net> <4851.1408094168@critter.freebsd.dk> <EB5B7C64-165B-48F1-94FF-1354E917A10F@mnot.net> <5871.1408106089@critter.freebsd.dk> <53F0496A.9040307@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14190.1408260714.1@critter.freebsd.dk>
Date: Sun, 17 Aug 2014 07:31:54 +0000
Message-ID: <14191.1408260714@critter.freebsd.dk>
Received-SPF: none client-ip=130.225.244.222; envelope-from=phk@phk.freebsd.dk; helo=phk.freebsd.dk
Subject: Re: HTTP/2 and Pervasive Monitoring
Archived-At: <http://www.w3.org/mid/14191.1408260714@critter.freebsd.dk>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--------
In message <53F0496A.9040307@cisco.com>, Eliot Lear writes:

>> By by whitening the present HTTP plaintext traffic with TLS, even with
>> quite weak cipher-suites, we dramatically increase the cost of the
>> postanalysis step, instantly making that filter impossible.
>
>This presumes that the use of weak cipher suites is actually cheaper to
>the end points than strong ones.  Is that really the case?

I think it is an implict requirement that a COTS server can do 10Gbit/s.

Any algorithm which meets that in software is fine by me from a
performance point of view.

Notice that the breaking is most likely going to happen against a
short-ish key (32-40 bits) rather than against the algorithm.

-- 
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.

HTTP/2 and Pervasive Monitoring Mark Nottingham
Re: HTTP/2 and Pervasive Monitoring Amos Jeffries
Re: HTTP/2 and Pervasive Monitoring Greg Wilkins
RE: HTTP/2 and Pervasive Monitoring K.Morgan
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Mark Nottingham
Re: HTTP/2 and Pervasive Monitoring Mark Nottingham
Re: HTTP/2 and Pervasive Monitoring Eliot Lear
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Martin Nilsson
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
RE: HTTP/2 and Pervasive Monitoring Albert Lunde
Re: HTTP/2 and Pervasive Monitoring Cory Benfield
Re: HTTP/2 and Pervasive Monitoring Erik Nygren
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Roland Zink
Re: HTTP/2 and Pervasive Monitoring Martin Thomson
Re: HTTP/2 and Pervasive Monitoring Brian Smith
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Eliot Lear
Re: HTTP/2 and Pervasive Monitoring Greg Wilkins
Re: HTTP/2 and Pervasive Monitoring Greg Wilkins
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Stephen Farrell
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Roland Zink
Re: HTTP/2 and Pervasive Monitoring Stephen Farrell
Re: HTTP/2 and Pervasive Monitoring Amos Jeffries
Re: HTTP/2 and Pervasive Monitoring Eliot Lear
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Ilari Liusvaara
Re: HTTP/2 and Pervasive Monitoring Mark Nottingham
Re: HTTP/2 and Pervasive Monitoring Greg Wilkins
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Martin Thomson
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
Re: HTTP/2 and Pervasive Monitoring Martin Thomson
Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp