Re: I revised the pro/contra document

"What I've been saying (repeatedly, sorry:-) is that if a
solution for inbound malware scanning or similar is developed
for HTTP, then that needs to be done without breaking TLS, and
that standardising a generic MITM attack on TLS would mean
breaking TLS, which is used by many more protocols than just
HTTP"

I agree with this point. I think we need to come up with a
protocol-supported way to solve the problems of trusted proxies without
modifying TLS.

Peter


On Mon, Nov 25, 2013 at 8:22 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie>wrote:

>
> Hiya,
>
> On 11/24/2013 08:03 PM, Adrien de Croy wrote:
> >
> > 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?
>
> I don't know to be honest. I'd say that'd be part of figuring
> out the non-trivial answers as to how to handle proxies in
> HTTP for which I think Mark has an open issue in the tracker.
>
> > Or that we need to fix things so we can scan https without
> >
> > a) breaking TLS
> > b) deploying MITM.
>
> What I've been saying (repeatedly, sorry:-) is that if a
> solution for inbound malware scanning or similar is developed
> for HTTP, then that needs to be done without breaking TLS, and
> that standardising a generic MITM attack on TLS would mean
> breaking TLS, which is used by many more protocols than just
> HTTP.
>
> S.
>
> >
> > 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
> >>>>
> >>>
> >>
> >
> >
> >
>
>