- From: Phillip Hallam-Baker <phill@hallambaker.com>
- Date: Mon, 17 Nov 2014 13:29:19 -0500
- To: Mike Belshe <mike@belshe.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, Roland Zink <roland@zinks.de>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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.
Received on Monday, 17 November 2014 18:29:47 UTC