Re: I revised the pro/contra document

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
neighbor to steal your taxes as you print them?

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
>>
>
>