Re: I revised the pro/contra document

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 19:21:57 UTC