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

Re: I revised the pro/contra document

From: Yoav Nir <synp71@live.com>
Date: Sun, 24 Nov 2013 11:00:45 +0200
Message-ID: <BLU0-SMTP650FA2AC0AC9394F634F26B1E20@phx.gbl>
To: Mike Belshe <mike@belshe.com>, Tim Bray <tbray@textuality.com>
CC: Mike Bishop <Michael.Bishop@microsoft.com>, Alexandre Anzala-Yamajako <anzalaya@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 24/11/13 12:53 AM, Mike Belshe 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 neighbor to steal your taxes as you print them?
My home does not have the IT department of a Fortune 500 company. I'm 
sort of a techie guy, so I can probably figure out the web interface of 
a network-attached printer. But how can I get a certificate for my 
printer? I know you believe that the tools will magically appear to make 
certificate management easy. But if the numbers stated are correct, that 
30% of websites already have valid certificates, then the growth of 
HTTPS will not be enough to make tools where none existed before.
> 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.
It's not contentious, it's just false. Go to the pricing page for Amazon 
cloundfront CDN <http://aws.amazon.com/cloudfront/#pricing> (I would 
have picked Akamai, but they don't put pricing on their website), and 
you pay 33% more plus a special fee for the certificate for using HTTPS. 
That's pretty much in line with the 40% figure. That's real cost that 
everybody has to bear. And you will get similar numbers if you host your 
site on your own servers.
> 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.
Right along with the price of serving plaintext HTTP. That is also 
getting 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.
All true, but I don't see how that is a counter-argument. HTTPS 
inspection is more expensive than HTTP inspection, and requires more 
user inconvenience.
> 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.
There are many examples we can think of, but the question of whether 
information is sensitive depends on many factors, and it's not 
necessarily always true that the requirement for privacy comes from the 
client side of TCP. A good TLS proxy solution would have to allow both 
client and server to veto non-E2E encryption.
> 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!
Great! How do I get some?


Received on Sunday, 24 November 2013 09:01:14 UTC

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