- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 26 Jul 2012 09:21:36 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: ietf-http-wg@w3.org
On 25 July 2012 18:13, Greg Wilkins <gregw@intalio.com> wrote: > Also consider a Server using some HTTP/2.0 push feature to push out > stock market prices as they change and users can have a custom > portfolio of stocks that they can watch. It can be very valuable > information to know what stocks a top trader has in their portfolio, > so if you sniff packets on their network, it does not matter that the > contents are encrypted, because over a period you can correlate the > time that they receive encrypted packets with known fluctuations of > stock prices and thus work out the contents of their portfolio. I don't want to disagree with your general argument, but what you are describing is a traffic analysis attack on the application that works even when TLS is employed. That's a good argument against the idea that TLS solves all security problems, but not one that supports the case for cleartext HTTP. We've seen a number of compelling cases for intermediation based on the value that intermediaries can provide. But we've also seen that with the right solution, the decision to enable intermediation can be made independently of the choice to require or disallow TLS. But, so far, I've not seen a workable solution for this problem - only expressions that it should be possible (i.e., draft-rpeon-httpbis-exproxy). Until such a solution manifests with reasonable backing, I'd consider these to form a fairly strong argument in favour of allowing use of HTTP/2 without TLS. That doesn't mean that we can't also motivate the use of cleartext HTTP/2 by pointing out disadvantages of secured HTTP/2 or advantages of cleartext HTTP/2. The fact that you can't hide who you are talking to is perhaps one such disadvantage. Intermediation actually helps those cases by creating K-anonymity sets... and in the end, that's half of what TOR does. --Martin
Received on Thursday, 26 July 2012 16:22:08 UTC