- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Sun, 15 Jul 2012 08:08:48 -0400
- To: Willy Tarreau <w@1wt.eu>
- Cc: Doug Beaver <doug@fb.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I can't see a value to mandating use of TLS in HTTP/2.0. There might be an argument for requiring support for TLS but even that represents a layer violation. But almost no Web browsers lack support for TLS. Mandating use of or support for TLS in HTTP/2.0 is only going to have a coercive effect if people are forced to stop using HTTP/1.1 which isn't possible. TLS is only as secure as the credentials used to secure it. If you have weak credentials you have weak security. The strength of a credential really depends on whether the credential is making a statement about the real-world holder: Is this facebook.ru certificate really for a corporation with officers that would be on the hook if they did something criminal or was it issued to the Russian maffia who have grabbed the local domain name? Confidentiality is actually a very minor direct requirement in most security sensitive systems. Having the Russian maffia look at my bank account matters much less to me than having them modify it. The underlying concern here seems to be that we need to move from a situation where security is optional on the Internet to where security is the default. I very much endorse that requirement but simply mandating TLS in HTTP/2.0 does not get us there unless clients have a way to know that a site is offering HTTP/2.0 In short what we really need is a policy mechanism that enables a client to know whether a site supports TLS and/or HTTP/2.0. This is what I have been working on with my Omnibroker proposal and my DNS security policy extensions. Using the DNS to effect security policy means opening up a can of worms. Even though the DNS is the authoritative source for making statements about DNS names, direct access to the unfiltered DNS is not available on many networks. DNSSEC has still to prove it is more than a science project. We need to define the right policy statements and it might take us more than one try. And finally, and most importantly, authoritative DNS statements are not necessarily safe ones. I do not want my browser to visit sites controlled by the Russian maffia even if they did pay ICANN for their domain name. That is why I have developed Omnibroker which allows the client to use a simple, stable interface that does not require it to do more than ask a service 'how should I connect to site X with protocol Y'. The question is then answered by a service chosen by the user to meet their security concerns.
Received on Sunday, 15 July 2012 12:09:16 UTC