Subject: Re: Privacy and its costs (was: Re: Mandatory encryption)

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 19 Jul 2012 17:49:15 +0200

> I think in the case of Ongoing privacy is not in fact important. But
> security is!

I think that in many cases, what matters is not 'have I got a direct
opaque un-spoofable link to the web site' (that TLS gives you) but 'is the
content I receive the same a trusted entity published' (non-tampering)

You have this problem with intermediaries but also without intermediaries

For example, all the mirroring sites that perform a service for free of
live by slapping ads around convenient ways to download content produced
by others.

What matters when someone goes to downloads.com, is not that he is talking
to downloads.com itself, but that the binary payload downloaded was
actually released by the editor downloads.com labels it with.

If HTTP/2 includes a command that basically means 'give me the signed
digest associated with URL X or Y':
1. user agents can check if intermediaries didn't mess with the relayed
content
2. user agents can check if the content they received over a supposedly
secure link was not tampered before transmission, if the web site is not
the original producer of the content (mirrors just have to mirror the
original signature in addition to the content itself). Secure link ≠
secure content

This is something TLS itself will never give you, the TLS trust model does
not work at all in any relaying situation (either direct relay with
proxies and other intermediaries, or deferred rely in the mirror case)

So you solve two problems in one go and the protocol changes are useful
even in proxy-less environments

Or am I missing something?

-- 
Nicolas Mailhot

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Jul 2012 09:05:45 -0700

No, privacy is important. There are things on my blog that people in
certain situations could get in trouble just for reading.  I should
offer privacy, and it’s a failure on my part that I don’t.  -T

---

From: Grahame Grieve <[email-masked]>
Date: Fri, 20 Jul 2012 07:22:51 +1000

> offer privacy, and it’s a failure on my part that I don’t.  -T

but in that case, merely accessing the server would be a problem.
We're going to mandate TOR everywhere?

Grahame

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 26 Jul 2012 11:13:49 +1000

> offer privacy, and it’s a failure on my part that I don’t.  -T

Privacy is important.

But I think HTTP/2.0 has to be vary careful about what it promises
with regards to privacy as it is not just content that can get readers
into trouble.  It is possible to infer a lot of private information
even from encrypted traffic, just from where it is directed and even
when it is sent.

Seeing a connection from a work computer to a TSFW server is going to
get the reader in trouble no matter if the content is encrypted or
not... it may even get them into worse trouble as imaginations can
fill in the content.

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.

In the same way, you can match traffic to/from gmail to posts on
forums and mailing lists and infer authors and subscribers on your
local network.  You can even determine lengths of passwords and other
information that can assist with breaking security.

Privacy is important, I just don't think it is something that we can
truly provide simply by encrypting the transport layer.   So there is
a danger in over promising to say that HTTP/2.0 will be TLS for
reasons of privacy.

regards

-- 
Greg Wilkins <[email-masked]>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Jul 2012 09:21:36 -0700

> 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