Re: I revised the pro/contra document

Hi Stephen

it's not clear to me in your last para about attack proxies.

Are you saying that we should only be able to scan http, and not https?

Or that we need to fix things so we can scan https without

a) breaking TLS
b) deploying MITM.

Adrien


------ Original Message ------
From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
To: "Mike Belshe" <mike@belshe.com>; "Yoav Nir" <synp71@live.com>
Cc: "Tim Bray" <tbray@textuality.com>; "Mike Bishop" 
<Michael.Bishop@microsoft.com>; "Alexandre Anzala-Yamajako" 
<anzalaya@gmail.com>; "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 25/11/2013 3:15:34 a.m.
Subject: 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 20:02:41 UTC