- From: Mike Belshe <mike@belshe.com>
- Date: Tue, 17 Jul 2012 23:54:00 -0700
- To: Willy Tarreau <w@1wt.eu>
- Cc: Phillip Hallam-Baker <hallam@gmail.com>, Paul Hoffman <paul.hoffman@gmail.com>, grahame@healthintersections.com.au, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CABaLYCvZF0zwQZnAkyvggWMoo0U+xOYU4t5uLCU=fYz6Yzx8aw@mail.gmail.com>
On Tue, Jul 17, 2012 at 11:09 PM, Willy Tarreau <w@1wt.eu> wrote: > On Tue, Jul 17, 2012 at 09:22:24PM -0400, Phillip Hallam-Baker wrote: > > -1 > > > > I don't want to have a mandatory requirement unless it is going to > > change behavior. > > > > We already have ubiquitous deployment of TLS in browsers. The code is > > freely available, everyone knows the benefit. > > > > The only HTTP servers or clients I am aware of that don't have TLS > > support are either toolsets that the provider expects to be used with > > OpenSSL or the like and embedded systems. > > > > Incidentally, suport for IPSEC is mandatory in IPv6 but that does not > > seem to do any good either. It just means that IPv6 is harder to > > deploy as implementations are required to support a security layer > > almost nobody uses as TLS has proved better. > > The issue with HTTP/2 will indeed be the same as with IPv6 : HTTP/2 will > be deployed between the browser and the load balancer, and everything > behind will remain HTTP/1 due to the added nuisances of deploying 2.0 > everywhere. Almost nobody does IPv6 between LB and server nowadays, it's > added cost for no benefit. > > This will force us to continue to support the crappy parsers of 1.1 > forever and not to have MUX between the LB and the server, and that's > precisely the situation I'd like to avoid, by having a protocol which > *supports* more privacy but does not impose it where it's not expected. > This is not true; you can use whatever you want in your backoffice. I've talked about this many times before, with or without TLS; whatever you want. It's the browser channel which will be TLS only. > > > Making TLS a mandatory requirement seems like a feelgood approach to > > security to me. Instead of doing something useful, we pass a > > resolution telling people to do what they plan to do anyway. > > Agreed. As I already said multiple times, sensible services requiring > privacy are already secured by TLS and it does not save them from being > tampered. But with TLS everywhere, we'll make the situation worse by > accustoming users to click all the day on "I accept the risks..." when > connecting to most of the poorly managed sites including the self-signed > equipments they run at home. > > I'm really against making such a thing mandatory because it will only > improve privacy on a few services which actually do not need it and will > globally deteriorate the overall security by lowering the level of control > of users. > We just disagree. And I keep going back to the same argument over and over: Show me the user that will stand up and say, "Yes, I would like my communications to be snoopable and changeable by 3rd parties without my knowledge." When we find those users, we can design a protocol for them. Until then, let's design for the existing users of the Internet that want privacy, they want security, they want to be free of tampering, and they want to know if someone else can snoop their traffic. Sorry - that will be the last time I say that for a while... Mike > Willy > > >
Received on Wednesday, 18 July 2012 06:54:28 UTC