- From: Adrien W. de Croy <adrien@qbik.com>
- Date: Wed, 18 Jul 2012 03:25:11 +0000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-Id: <em7dabfa75-0cf3-48ce-ba8d-30e3057d5485@bombed>
Mandating use of (c.f. support for) crypto in HTTP will prevent it from being deployable in a significant number of scenarios, thereby requiring ongoing use of HTTP/1.1. DESIRABILITY OF PRIVACY Proponents of mandatory crypto are making an assumption that privacy is ALWAYS desirable. It is not ALWAYS desirable. In many cases privacy is undesirable or even illegal. 1. Many states have outlawed use of crypto. So will this be HTTP only for the "free" societies? Or is the IETF trying to achieve political change in "repressed" countries? I've dealt with our equivalent of the NSA on this matter. Have you? I know the IETF has a neutral position on enabling wiretapping. Mandating SSL is not a neutral / apolitical stance. Steering HTTP into a collision course with governments just doesn't seem like much of a smart idea. 2. Most prisons do not allow inmates to have privacy when it comes to communications. Would you deny [*] all prisoners access to the web? There are other scenarios where privacy is not expected, permitted or desirable. 3. Many situations require communications to be open and visible. Would you rather your network infrastructure phoned home with SSL or HTTP that you can see. 4. Scanning for malware at a gateway. This requirement is NOT going away, and the SSL will be brute-forced / spoofed etc to achieve this. Mandating SSL will just make it easier for malware to propagate, since you make it harder to scan [**]. COST Google, Facebook and Twitter don't need to spend much on SSL certs from CAs. Not in the scheme of things. What about the other hundreds of millions of us running web servers. You gonna buy us our certs? I better buy me some shares in Verisign et al.. SECURITY Mandating SSL on all devices with HTTP stacks (e.g. your home network infrastructure, NAS, Modem etc) cannot be practically done while we rely on CAs to issue certs, and while those certs must be installed, expired, updated etc etc. Or do you think manufacturers of such hardware should just ship with some default cert? Self-signed maybe? And while you're at it, why not get every machine in the world to trust that cert... Oh dear, do we have a security problem? Frankly I think mandating SSL for all HTTP/2.0 will just break SSL for the world (or more likely consign HTTP/2.0 to relative obscurity). It's been alluded to that we'd replace the CA infrastructure. Don't you think it's premature to propose mandatory use of SSL when you haven't proposed what would replace the CA infrastructure yet? That's like starting building a spaceship for Alpha Centauri based on a rocket engine that hasn't been invented yet. You'd have to replace CRL and OCSP checking protocols, because they use HTTP, and mandating use of SSL for that would create a paradox (how do you check the cert on the connection used to check the cert ad infinitum). OTHER Most people here seem to focus on issues such as CPU load, extra R-Ts introduced by the SSL setup etc. Those are valid concerns, but they are easier to overcome than the others. They aren't easy to overcome, just easier. Seems to me it would be a whole lot simpler and more compatible with the actual world we actually live on just to make crypto optional. Adrien [*] We can't realistically expect server operators to indefinitely support both HTTP/2.0 and HTTP/1.1. Some will inevitably drop HTTP/1.1 support, and that part of the internet will then become unavailable to those forced to keep using HTTP/1.1, effectively denying those users. [**] T here has been some discussion about enabling intermediaries to be able to see plaintext payload by terminating the SSL connection at each end. This hasn't progressed enough, and the current proposals still basically bypass intermediaries AFAICT.
Received on Wednesday, 18 July 2012 03:25:35 UTC