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

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

From: Mike Belshe <mike@belshe.com>
Date: Mon, 6 Aug 2012 13:23:06 -0700
Message-ID: <CABaLYCt1i7P4zqDk4i81yOSE9XbPnN6iVW8tttOQip=0DBnY6w@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: ietf-http-wg@w3.org
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


On Mon, Aug 6, 2012 at 10:32 AM, Mike Belshe <mike@belshe.com> wrote:

>
>
> On Sun, Aug 5, 2012 at 6:44 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>> On 31 July 2012 14:43, Mike Belshe <mike@belshe.com> wrote:
>> >
>> >
>> > On Wed, Jul 18, 2012 at 8:23 PM, Tim Bray <tbray@textuality.com> 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.
>>
>
> 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
>
>
>
>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Greg Wilkins <gregw@intalio.com>
>> http://www.webtide.com
>> Developer advice and support from the Jetty & CometD experts.
>>
>>
>
Received on Monday, 6 August 2012 20:23:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 August 2012 20:23:43 GMT