- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 17 Nov 2014 19:59:31 +0100
- To: Phillip Hallam-Baker <phill@hallambaker.com>
- Cc: Mike Belshe <mike@belshe.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Roland Zink <roland@zinks.de>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Mon, Nov 17, 2014 at 01:29:19PM -0500, Phillip Hallam-Baker wrote: > On Mon, Nov 17, 2014 at 12:50 PM, Mike Belshe <mike@belshe.com> wrote: > > > > > > On Mon, Nov 17, 2014 at 9:06 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> > > wrote: > >> > >> -------- > >> In message <20141117163914.GA14542@1wt.eu>, Willy Tarreau writes: > >> > >> >That's exactly what I hate in the "tls everywhere" model : > >> > >> I think the major mistake in "tls everywhere" is that while the > >> OSI models protocols sucked, the basic idea of layering did not. > >> > >> IMO the HTTP/2.0 spec shouldn't mention encryption or TLS with > >> a single word, making it robust for future changes in transport > >> or encryption technologies and policies. > >> > >> By welding HTTP/2.0 to TLS (as hard as they can), the "tls everywhere" > >> crowd is effectively making it harder to replace TLS with something > >> better in due time. > > > > > > This is a false claim. An example would be HTTP binding on top of SCTP. > > HTTP didn't define it, but it was defined later in a separate RFC. It just > > takes someone defining how to do it. Obviously, you have to know what > > you're binding to in order to define it. > > > > Defining how to bind HTTP to today's leading secure transport protocol does > > not detract from defining how it would be bound to future protocols, if/when > > they should emerge. > > I have a different concern. > > I think that the outcome will be as follows: > > 1) Mandate use of TLS with HTTP. > 2) Decide that using 'full TLS' is too much inconvenience. > 3) Browsers race to the bottom weakening the TLS security model to > meet the mandate > 4) Bad TLS drives out the good. > 5) Net reduction in security. Exactly! Willy
Received on Monday, 17 November 2014 19:00:04 UTC