- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Tue, 17 Jul 2012 21:22:24 -0400
- To: Paul Hoffman <paul.hoffman@gmail.com>
- Cc: grahame@healthintersections.com.au, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
-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. 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. On Tue, Jul 17, 2012 at 8:51 PM, Paul Hoffman <paul.hoffman@gmail.com> wrote: > +1 to what seems to be a lot of developers: make TLS mandatory. > >> so, even when used in an internal application protocol, it's going to >> be end to end >> encrypted to make it super hard to debug? > > In an internal application protocol, why would it be "super hard to > debug"? The client can do an HTTP dump before TLS, the server can do > an HTTP dump after TLS; either of the sides could debug the TLS. > >> http is about more than users using >> web browsers. > > Completely true, and not relevant. Insecure HTTP for non-browser > applications still has the same bad properties, no? > -- Website: http://hallambaker.com/
Received on Wednesday, 18 July 2012 01:22:52 UTC