W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: I revised the pro/contra document

From: Roland Zink <roland@zinks.de>
Date: Sun, 24 Nov 2013 22:10:48 +0100
Message-ID: <52926B58.50200@zinks.de>
To: ietf-http-wg@w3.org
Encryption doesn't come for free. It costs energy even when the hardware 
is able to do the encryption. When it is unnecessary this should be avoided.


On 24.11.2013 20:21, Zhong Yu wrote:
> On Sat, Nov 23, 2013 at 4:53 PM, Mike Belshe <mike@belshe.com> wrote:
>> Alexandre -
>> Your question is a reasonable one.  And personally, I agree with Tim, that
>> TLS is useful for all data transmitted over HTTP.
>> In the case of printers, TLS is absolutely suitable, and in fact employed
>> today at most fortune-500 companies.  Imagine employees being able to snoop
>> insider information as it flows over wifi to the printers?  Corporate IT
>> guys long ago fixed this problem.  Even for home use, do you want your
> If the problem has been fixed, and presumably nobody can sniff any
> bits sent by others, regardless of protocol, why is it still necessary
> to encrypt traffic to printers?
>> neighbor to steal your taxes as you print them?
> If my neighbors can sniff my network traffic, I got a huge problem,
> and solution is not to encrypt my data to my printer.
>> For media content, TLS is also appropriate.
>> Mike Bishop brought up the DRM case, which is fine, but somewhat orthogonal
>> to HTTP.  You see, DRM is protecting data at rest (e.g. stored on a disk
>> somewhere) rather than data-in-motion (e.g. being transmitted over HTTP.
>> There are many interesting facets to data-at-rest protections.  But they out
>> of scope for HTTP.  HTTP is a transport protocol and only deals with
>> data-in-motion.   It is worth elaborating on Mike's example, however,
>> because he didn't mention that transmitting the DRM-protected data over HTTP
>> contains metadata (e.g. the name of the video, keywords, authors, people,
>> links, etc) which can also be sensitive itself.  Should your neighbor know
>> that you're watching porn right now?  Should your neighbor know that you're
>> researching <insert sensitive topic here>?  When discussing HTTP, we should
>> be talking about data in motion only, and even encoded content, like DRM
>> content still benefits from TLS.
>> Ok, so when it comes to data in motion, how do we decide if TLS is useful?
>> First let's consider which parties are involved in a HTTP transaction.
>> There are:
>>      a) the user
>>      b) the server
>>      c) the middleware in between
>> The user, of course, expects his data to be sent privately.  We don't want
>> random others to view our communications.  The only downside would be if
>> there were side effects to transmitting privately.  For instance, if my
>> network were slower, or it cost more, etc - some users would be willing to
>> exchange private communications for lower cost.  However, those of us that
>> have researched TLS in depth know that it can be deployed at near zero cost
>> today.  This is contentious on this list.  But as we look forward, with
>> computer speeds increasing and the Internet growing larger, it is clear that
>> any cost of TLS will only get cheaper.  As a second counter argument, some
>> on this list observe that some users that employ proxies to help filter
>> malware over their unencrypted streams.  This is still possible with TLS,
>> you just need to move to a Trusted Proxy that uses TLS as well.  And of
>> course, virus writers have already figured this out too.  They're starting
>> to use TLS because they know these users can't currently detect viruses over
>> encrypted channels.  So regardless of whether you like HTTP using TLS all
>> the time, we still need Trusted Proxies for our TLS.  It's just an
>> independent issue.
>> The server, unfortunately, can't tell whether TLS is appropriate or not,
>> because the need for privacy depends on the user.   As an example, we
>> discussed the case where a user is downloading public information about a
>> disease.  If the user is a medical student studying for an exam, it's
>> probably okay in the clear.  But that exact information, when sent to a
>> patient for a real case, suddenly *does* need to be transmitted privately.
>> Using TLS all the time has no negative issue, while using TLS some of the
>> time does.  To solve this for their users, servers should always use TLS.
>> Finally, we can discuss the middleware.  Nobody knows exactly how much
>> middleware exists between a user and a server.   As noted, we could use
>> non-authenticated encryption (non-TLS, or unverified TLS), which would at
>> least make it more difficult for passive middleware to decode the traffic
>> running through it.  However, using authenticated encryption (what TLS
>> already does) eliminates passive snooping, and also makes it quite difficult
>> to snoop without detection.  Although those on this list like to say that
>> "MITM" is everywhere, MITM is usually discoverable, and none of the
>> off-the-shelf MITM solutions today can employ MITM with complete
>> invisibility.  Using TLS today would eliminate all but the most
>> sophisticated attacks by middleware stealing our data in motion.
>> So, to answer your question, of are media files and printers well suited for
>> TLS?   Yes, of course!
>> Mike
>> On Sat, Nov 23, 2013 at 2:07 PM, Tim Bray <tbray@textuality.com> wrote:
>>> Iím just enumerating the arguments that have been expressed a
>>> critical-mass number of times on-list.  I personally think the notion that
>>> you donít need to encrypt media files is completely wrong, but it has been
>>> repeatedly asserted.
>>> On Sat, Nov 23, 2013 at 1:42 PM, Mike Bishop
>>> <Michael.Bishop@microsoft.com> wrote:
>>>> Media files often have DRM, which provides encryption at the content
>>>> layer; it's potentially a waste of resources to re-encrypt content that's
>>>> already encrypted.  The printers being discussed are intra-home, and care
>>>> more about ease of setup than providing confidentiality across a
>>>> fully-controlled network.
>>>> -----Original Message-----
>>>> From: Alexandre Anzala-Yamajako [mailto:anzalaya@gmail.com]
>>>> Sent: Saturday, November 23, 2013 1:27 PM
>>>> To: Tim Bray
>>>> Cc: ietf-http-wg@w3.org
>>>> Subject: Re: I revised the pro/contra document
>>>> I am sorry if these points were discussed before but i don't get why tls
>>>> isn't appropriate for media files or why we shouldn't secure our connections
>>>> to printers ?
>>>> Cheers
Received on Sunday, 24 November 2013 21:11:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC