Re: I revised the pro/contra document

A general point - *please* don't talk about adding "privacy"
to HTTP - we're discussing confidentiality and server-auth.
Making confidentiality or both be the default for HTTP/2.0
will be a wonderful thing IMO. But the end result of doing
that is just not "privacy" and folks sloppily arguing that
you do get privacy as a result are just damaging the argument
to get confidentiality by default.

On 11/24/2013 10:05 AM, Mike Belshe wrote:
> 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.

First Yoav is entirely correct that getting a certificate that chains
up to a browser-trusted root is not doable for printers except within
enterprises that install their own roots into employee browsers. That
nicely shows up the benefit of the http:// URI via opportunistic TLS
in HTTP/2.0 approach again. That's the approach we should take. It
needs no new PKI tooling or admin to solve a problem that we have
repeatedly failed to solve over the last 20 years. The "problem" I
mean there is a PKI enrollment setup that just works well everywhere.
There isn't one. Not unless you completely re-do the CA business
model. And assuming that would not be a good thing when designing
HTTP/2.0. (The CA business model will evolve sure, and maybe in a
good direction, but we cannot assume that.)

I find Mike's response very odd. Browsers have been adding UI to make
SSC's (self-signed certs) less usable for years. Now that's not an
easy thing to get right, since there are many web sites (e.g. one of
mine [1]) that use SSCs for reasonable purposes, but once you have
users accepting SSCs (as studies show does happen) then the
server-auth aspect of TLS is damaged. (In the case of [1] I'm fine
that it cause browser barfs since I use that to mess with students'
heads. And I did have a good reason to turn on confidentiality
since I used to host some kids-football-team contact info there.
I just have never had a good enough reason to deal with a real PKI
for it.)

   [1] https://down.dsg.cs.tcd.ie/

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

Here, Mike is entirely correct. The network stack cannot know when
the payload or meta-data are sensitive so the only approach that
makes sense is to encrypt the lot to the extent that that is practical.
Snowdonia should be evidence enough for that approach even for those
who previously doubted pervasive monitoring.

HTTP is used for lots of sensitive data all the time in places that
don't use https:// URIs today. Sensitive data doesn't require any
life or death argument, it can be nicely mundane, e.g. a doctor
visit being the example Alissa used in the plenary in Vancouver.

We now can, and just should, fix that. There's no hyperbole needed
to make that argument compelling.

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

So if HTTP/2.0 uses TLS by default then the relevant difference
will be between HTTP/2.0 and HTTP/1.1 without TLS, right?

If this wg does a good job on the overall efficiency of the
protocol then I can't see any good reason why a cloudy provider
wouldn't be able to offer the same pricing for HTTP/2.0 and
cleartext HTTP/1.1 (other than having to pay a CA, but then I
don't think we should require that). And that's about as much
as should concern us here I think.

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

Disagree. The costs of moving the bits around in clear will get
cheaper. But the risk associated with doing that is getting high
enough that e.g. /. today tells me [2] twitter turned on ECDH with
PFS. Plaintext is not really cheaper once there's a significant
enough adversary.

   [2]
http://techcrunch.com/2013/11/22/twitter-enables-perfect-forward-secrecy-across-sites-to-protect-user-data-against-future-decryption/

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

This wg should IMO not even consider the requirements for such MITM
attack boxes. (Except as a threat.) And the term "trusted proxy" is
pure BS. (I'm not sorry for being blunt there, but apologies if my
bluntness offends.) I've never seen an acceptable technical solution
in any of the proposals that have been made for MITM attack boxes.
And that's ignoring RFC 2804, and what I hope will be a new RFC on
that topic resulting from Vancouver. [3]

   [3] http://tools.ietf.org/html/draft-farrell-perpass-attack

I do think the wg should consider HTTP proxies and how those work
with HTTP/2.0. That is where you should consider requirements for
HTTP filtering or scanning. And if that requires a less efficient
use of HTTP/2.0 (e.g. I think it'll need two TLS sessions and some
new browser config and/or of leap-of-faith processing in the
browser) then so be it.

But starting from an approach that assumes you can break TLS to
solve an HTTP problem would be sheer folly. Its been tried and
failed. If its tried again it'll fail again.

Cheers,
S.


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

Received on Sunday, 24 November 2013 14:15:59 UTC