Re: I revised the pro/contra document

On Sun, Nov 24, 2013 at 1:00 AM, Yoav Nir <synp71@live.com> wrote:

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

I doubt you would bother to install a valid certificate; you'd just use a
self-signed cert or something, and because you've said you don't care about
it, you'd ignore the warnings.



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

I think you're thinking like an engineer.  You're right, they do charge
more (and I'm right those prices will continue to come down).  But those
prices are already TINY.  I know 33% sounds like a lot, but this is not the
primary cost of operating a business.  So if you want to do a price
comparison, do an all-in price comparison.  And you'll find that the cost
of TLS is less than a fraction of a percent difference in operating cost
for most businesses.

And if you're not talking about businesses, but consumers, CDNs aren't
really relevant.  As an example, I run my home site at Amazon for zero
extra cost, but I did buy a 5yr $50 cert.




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

agree


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

My point is that if you're interested in filtering, you already have to do
HTTPS inspection today.  And that is the real driver for why companies are
employing those solutions.   So this is not relevant as we decide how to
use TLS in HTTP/2.



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

I'd like to hear an example where the user requested a secure channel and
the server should have the right to veto.  Why would either endpoint want
to, actually?  Only middleware that wants to insert itself ever wants to do
that.


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