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

From: Greg Wilkins <[email-masked]>
Date: Mon, 6 Aug 2012 11:33:46 +1000

On 31 July 2012 16:55, Tim Bray <[email-masked]> wrote:
> This is why it’s reasonable to think it important that privacy be the
> default

Again, let's not overstate what TLS can provide.  It cannot fully
provide privacy because it does not conceal who you are talking to and
when you talk or even how much to talk or in what size chunks you
talk, or if you listen more or less than you speak.

TLS can provide some degree of confidentiality and/or integrity, but
these are different from privacy.  If you wanted to hide your sexual
related browsing from network sniffers, the solution is not to use TLS
but not to establish a connection to www.someSexualPreference.com

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

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 6 Aug 2012 11:44:33 +1000

On 31 July 2012 14:43, Mike Belshe <[email-masked]> wrote:
>
>
> On Wed, Jul 18, 2012 at 8:23 PM, Tim Bray <[email-masked]> wrote:
>>
>> Fair point; I should. -T
>
>
> Yeah, belshe.com should too :-)
>

Mike,

I don't understand the benefit of encrypting traffic to/from a public
blog site?    There is no privacy obtained by doing so.

If I can see somebody on my network make a connection to belshe.com,
then I can go browse that site myself and see all the content that the
encrypted connection has available to it.  By looking at the dates and
sizes of the data transfers, I can make a pretty good estimate of the
pages that the encrypted connection has accessed.

TLS provides little privacy in this situation as I will know who the
client connected to, what they saw and when they saw it.   Even if the
browser pushes content, for a blog site that is more often than not a
comment, so that will get published as well and again size/date
matching can be very effective at working out who said what.

If privacy is a necessary attribute of HTTP/2.0, then we will have to
prevent direct connections to servers and all traffic will need to go
via anonymous proxy services.

There may well be good arguments for having confidential content as
the default for HTTP/2.0, but privacy is not one of them.

cheers

---

From: Tim Bray <[email-masked]>
Date: Sun, 5 Aug 2012 20:12:26 -0700

> If I can see somebody on my network make a connection to belshe.com,

Um, suppose you observe that I have connected to 204.45.137.222 or
225.173.34.64.   You’re a bad guy and can’t see the content.  What
have you learned about me?  -T

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Aug 2012 08:06:15 -0400

> have you learned about me?  -T

If you are a common criminal, nothing of importance.

If you are a criminal government, pretty much everything you need.

Social network analysis is how oppressive regimes track the
opposition. If you know who is talking to whom, you know who is likely
to follow whom. That is why Iran was trying to get into Facebook.

Responding to that type of attack is important and rather more central
to the history of the Web than people might imagine. But it isn't a
sensible attack to base the design of the core specification on. That
is what schemes like Tor are for.

It used to be 'one war, one rifle'. The US army had to throw out their
old guns and replace them after each major conflict as opponents
adapted to the capabilities of the old one. Today it is one revolution
one application. Fortunately the number of really bad regimes is
falling fast enough that we will run out of crappy regimes before we
run out of ideas. And that is taking into account the fact that the
success rate is about 75% and 25% of the successor regimes need a
repeat revolution.

-- 
Website: http://hallambaker.com/

---

From: Mike Belshe <[email-masked]>
Date: Mon, 6 Aug 2012 10:32:41 -0700

> blog site?    There is no privacy obtained by doing so.

Hey Greg -

I don't want to restate things over and over, so I'll be brief.  For the
most part, I just see this as a natural evolution.  We should be constantly
innovating and raising the bar in the security and privacy space.  This is
just one step.  Many many more are needed to.  But this is the most simple
and logical one to take now.

My opinions:
   a) With all else being equal, encrypted is always better than not
encrypted
   b) Encryption doesn't "fix" everything, but there is no "fix".  With
security and privacy its always about "raising the bar".
   c) Users expect and want encryption.  It's only site operators/proxy
vendors/server vendors that complain.
   d) The cost of encryption is tiny.  (I know others disagree on this
point)
   e) Debugging is not a real issue and can be mitigated with better tools.
   f) As the world comes online, there are many amateur site
operator/content owners. They don't know when it is important to encrypt or
not.  We should help them protect themselves and their users by building
stronger protocols.
   g) The most common theft is cookie hijacking, which can still be done
today on a plethora of services - hotmail, yahoo mail, flickr, etc etc.
   h) The larger security issues to be fixed, like the CA system, can't be
fixed until we turn on TLS everywhere.  Once we do, we'll quickly see
browsers innovate with new CA/trust systems.  Without more TLS everywhere,
everyone just side-steps the issue.

Mike

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Aug 2012 13:50:44 -0500

Folks,

We discussed these topics in the second meeting last week. The feeling in the room there needs to be confirmed as consensus around the new charter on this list, but as it is, this topic (mandatory TLS, impact of use of TLS, finer aspects of privacy) should be assumed to be off-topic for this list.

In an nutshell, while we are talking about mechanisms to negotiate or otherwise enable the use of TLS in various situations, we are not talking about what's mandatory to use, the impact of that decision, etc. These discussions are appropriate in places that define the use of HTTP (e.g., in coordination between browser vendors, such as in the W3C), not the protocol definition itself.

If we somehow fail to get consensus on this aspect of the charter (very doubtful, based on what I saw expressed in Vancouver), we can reopen this discussion, but as it is, it isn't helping.

Thanks,

--
Mark Nottingham
http://www.mnot.net/

---

From: Mike Belshe <[email-masked]>
Date: Mon, 6 Aug 2012 13:23:06 -0700

BTW - thanks to Mark for reiterating that "mandatory SSL" is out-of-scope
for HTTP/2.0.

So I apologize if my comments today are confusing in this regard.

I'll reiterate what I said at the mic in Vancouver:
Although I think we're losing an opportunity to better secure HTTP, I don't
think we'll get consensus around it for HTTP/2.  The current SPDY draft
doesn't require SSL, and the HTTP/2.0 spec won't either.

Mike

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 7 Aug 2012 19:12:50 +1000

On 7 August 2012 03:32, Mike Belshe <[email-masked]> wrote:
> I don't want to restate things over and over, so I'll be brief.

ditto

>> blog site?    There is no privacy obtained by doing so.

Reading that again, I see I chose my words badly.       I'm not trying
to speak for or against encrypting (and agree that there is likely a
natural evolution towards it just as there was will cell phone).
I'm just saying that encryption does not provide privacy.

cheers