-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/01/2015 2:35 p.m., Constantine A. Murenin wrote: > On 2015-01-12 16:30, Willy Tarreau wrote: >> Hello, >> >> On Sat, Jan 10, 2015 at 12:09:38AM -0800, Constantine A. Murenin >> wrote: >>> I am sincerely asking for the IETF to not approve HTTP/2 as a >>> standard without the compatibility issues as above being >>> addressed first. The policy to abandon the http:// address >>> scheme and adopt https:// will only promote a significant link >>> rot for the future generations to experience well into the >>> future (didn't we think TLS 1.0 was good enough?), and will >>> curtail independent and hobbyist operators. >> >> Please note that the protocol *does* support http:// address >> scheme, it's only that two browsers decided that they will not >> implement it. Let's hope that they'll change their mind when >> HTTP/2 starts reaching normal users and is no more limited to >> huge sites with lots of people to manage certificates. > > Has this been changed since the publication of > http://queue.acm.org/detail.cfm?id=2716278, which claims that it's > 3 out of 4 major browsers that will only do HTTP/2.0 with TLS? Nothing has changed. You just seem to be slightly misunderstanding the situation. The protocol spec defines both http:// and https:// on equal footing for HTTP/2 just as they were for HTTP/1. As Willy mentioned. Those browsers have chosen (for now) to ignore whole sections of the specification and the WG chartered requirements that HTTP/2 to be usable in *all* use-cases where 1.1 was. By vehemently not implementing that support and forcing their users through all those problems you describe (I pity their users but karma will have its way). PHK, and others including myself, are at the other extreme of the spectrum not implementing https://. Though we have not been refusing to ever do so (that just seems a stupid claim to make). It is a reflection on some implementers arbitrary choice to ignore the specification text (er, "forever"). Not an explicit lacking in the specification itself. It makes little sense for a protocol to say "MUST implement this specification". But it does make for an interesting birth to the new protocol. > > PHK>>>> Yet, despite this, HTTP/2.0 will be SSL/TLS only, in at > least three out of four of the major browsers, in order to force a > particular political agenda. The same browsers, ironically, treat > self-signed certificates as if they were mortally dangerous, > despite the fact that they offer secrecy at trivial cost. > > Regardless, this doesn't change the fact that HTTP/2, as proposed, > lacks soft upgrade/downgrade provisions -- from the server side, > you either have to carry the whole pre-HTTP/2 SSL/TLS baggage, > pre-TLSv1.2 and all, or not deploy HTTP/2 at all; else, some of > your customers won't be able to access the site at all, after they > get the https:// links from customers that do. > > This wouldn't have been the case with opportunistic encryption. > It would have ensured full protection against passive monitoring > attacks, in compliance with Best Current Practice 188. HTTP/2 does > nothing to combat the widespread passive monitoring. This is incorrect. Soft upgrade/downgrade in https:// is done with ALPN and the reason why that TLS feature is now mandatory for https://. Soft upgrade in http:// is done via HTTP Upgrade mechanism same as with HTTP/1. The sad reality that it lacks widespread HTTP/1.1 implementation support to actually perform the switch does not detract from its existence as a feature in the protocol and potential use when opportunity presents it. Its active use by HTTP/2 implementations to transition should also improve the environment/availability for opportunistic upgrades. The TLS/SSL baggage needing to be implemented is no different for HTTP/2 as for HTTP/1.x. The expectation is that the baggage requirements become smaller over time. After the events of the past few months in particular all the SSL baggage should not be an issue for any HTTP/2 implementation and the TLS built-in upgrade mechanism is actively minimizing the remaining legacy issues. The HTTP/2 does change the BCP 188 state over HTTP/1.1: * explicitly forbids use of the crypto schemes currently known to be (or expected soon to be) vulnerable to monitoring. * multiplex+compressed traffic raising the difficulty bar to passive monitoring identifying any given client from packet statistics through intermediaries. * provides extensibility points for future strong cryptography even in the "clear-text" HTTP/2 connections. * provision to opportunistically remove (or compress away) features of HTTP/1 used as client identification/signature footprints by monitors. * lack of opportunistic downgrade for http:// raises the difficulty bar for active attackers to impose a weak HTTP/1.x environment on clients initiating native HTTP/2. It also does a few things which lower the bar in some ways if implemented (TLS ALPN, and the native magic prefix can still be hijacked). So your assertion that it "does nothing" is incorrect. It does what can be done in HTTP at this point in time. True it is just a small improvement, but non-zero. Amos Jeffries Squid Software Foundation -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUtJuoAAoJELJo5wb/XPRjh9cH+QFm3Nv+jJ6YJGWr1VEbDr6T h2vSet/JfR92MR9TC0S1CKn2lEN1XQ1wyHB+7BHjn0pYCUcrg5qv1jorI5CbS8ci a1o/PYb3T30DAAjCUeacinc3ZgECeDWHuCJxLODsXDffq8Hn+jp5lfxBT3t67Dj0 nmg2zIWO+77CiHd8BpgfPjxRq4lp192bgARPr2Y/4OFADV9zKRrDM7H8KuoswG/V sPeAEx+48c745swXN7042k+KmHk0KG8rIyO8+j6eqSjs+kx6wnS2380AQJ1DQsXG m2rDWEw2H8XUjOgHEg+PopIHo/WMBUsNSIz5PtqSYjT8sJ0bOThTCSy3RIWfQUo= =7vN9 -----END PGP SIGNATURE-----