Re: Re[4]: Some reasons why mandating use ofSSL for HTTP is a really bad idea

In message <CABaLYCuyjE8TRHHk2O0sY4ocB=LmK7S6LrDYc1=Jz3NFU1df+w@mail.gmail.com>
, Mike Belshe writes:

>I'm taking the position of the user.  I want the user to be able to know if
>someone is spying on them in all cases.

This has been a long thread already, so I will try to make this short
and to the point.

1. I think Mike has a very valid point here, but it's not our job,
   and we could not solve the problem if it were.

   I would express it slightly differently than Mike: "If it looks
   like privacy, the user should be able to know definitively if
   it is end-to-end privacy or not."

   I'm not a card-carrying cryptographer, but it's my clear perception
   that the currently perverted and corrupt CA system deliberately
   makes that ideal very hard if not impossible.

2. There are legitimate (or legitimized) reasons for intercept.

   In the cases where the intercept is not covert, it is in the
   interest also of the interceptor, that no unnecessary weaknesses
   are introduced.

   This indicates an operating mode where the user is told "You
   have privacy only as far as SNOOP_PROXY, what happens after that
   depends on what SNOOP_PROXY does."

   Or the probably more likely case: "You have no privacy from here
   to CORP_PROXY, but CORP_PROXY claims that you have privacy from
   there to the destination."

   If I'm an employee, or inmate, that's just the rules of the game,
   but the important thing is that as a user I'm precisely and
   correctly communicated the reality of the game.

   I belive this is more or less just a matter of allowing 
	GET https://blablabla HTTP/1.1
   to proxies, but I defer fully to Adrian on this.

3. There are objective indications that TLS is not always an advantage.

   Some have been mentioned already, I'll just add another:  High
   reliability safety-of-life critical systems, such as power distribution,
   air traffic control and emergency services.

   Putting a 2 meter airgap around such a system is currently
   considered the best practice way to implement both high reliability
   and high security.

   The added failure modes of certificates, which are opaque and
   hard/impossible to debug & correct on the kind of timescales
   relevant (< 3 minutes) are not welcome.  SSH is tolerated, but
   with very strict password registration and disclosure policies,
   and often with NULL block-ciphers, to make network flight recorders
   usable.

   Mandating TLS in HTTP/2.0 will effectively force these installations
   to stick with HTTP/1.1, in order to be able to do accident
   investigations.

4. It is not our job, and it is counter productive.

   Cryptography is a layer 8-10 problem more than anything on the
   internet.

   If we tangle HTTP/2.0 into layers 8-10, it will become subject
   for discussion at diplomatic levels, will raise issues about
   ITAR rules and will meet a lot of push-back from all sorts of
   shady agendas, not to mention a damn good headline in a clueless
   press.

   Trying to mandate TLS with HTTP/2.0 would therefore be a major
   drag on HTTP/2.0's adoption and deployment and  counterproductively
   delay the benefits and improvements HTTP/2.0 (will) bring.

Conclusion:

   Make it easy to do, but don't mandate it.

   You always get better results by delivering good tools, than
   rigid policies.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 18 July 2012 08:02:54 UTC