- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 18 Jul 2012 08:02:21 +0000
- To: Mike Belshe <mike@belshe.com>
- cc: "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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