Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

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, which claims that it's 3 out 
of 4 major browsers that will only do HTTP/2.0 with TLS?

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.


Received on Tuesday, 13 January 2015 01:36:18 UTC