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

"Constantine A. Murenin" <cnst@NetBSD.org> Tue, 13 January 2015 01:36 UTC

Return-Path: <cnst@NetBSD.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68A81A8991; Mon, 12 Jan 2015 17:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLzQRN7hjK1H; Mon, 12 Jan 2015 17:36:20 -0800 (PST)
Received: from Cns.Cns.SU (IPv6.Cns.SU [IPv6:2001:470:7240::]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BC01ACE50; Mon, 12 Jan 2015 17:35:53 -0800 (PST)
Received: from [127.0.0.1] (cnst@localhost [127.0.0.1]) by Cns.Cns.SU (8.14.5/8.14.5) with ESMTP id t0D1ZRvp020308; Mon, 12 Jan 2015 17:35:27 -0800 (PST)
Message-ID: <54B4764C.6080106@NetBSD.org>
Date: Mon, 12 Jan 2015 17:35:08 -0800
From: "Constantine A. Murenin" <cnst@NetBSD.org>
Organization: NetBSD
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 SeaMonkey/2.13.2
MIME-Version: 1.0
To: Willy Tarreau <w@1wt.eu>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
References: <20141231153045.2584.87794.idtracker@ietfa.amsl.com> <20141231153045.2584.87794.idtracker@ietfa.amsl.com> <54B0DE42.5010103@NetBSD.org> <20150113003055.GB30295@1wt.eu>
In-Reply-To: <20150113003055.GB30295@1wt.eu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dGpB5Rs0pAqFqidK-dJE-JP_qxw>
X-Mailman-Approved-At: Tue, 13 Jan 2015 08:01:56 -0800
Cc: iesg@ietf.org, iesg-secretary@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jan 2015 01:36:28 -0000

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?

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.

Cheers,
Constantine.