Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
Amos Jeffries <squid3@treenet.co.nz> Tue, 13 January 2015 04:15 UTC
Return-Path: <squid3@treenet.co.nz>
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 5D5561A8855; Mon, 12 Jan 2015 20:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.923
X-Spam-Level:
X-Spam-Status: No, score=0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 qNX7xQBwtFX9; Mon, 12 Jan 2015 20:15:09 -0800 (PST)
Received: from treenet.co.nz (121-99-228-82.static.orcon.net.nz [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 06BBD1A8850; Mon, 12 Jan 2015 20:15:06 -0800 (PST)
Received: from [192.168.2.25] (121-98-144-114.bng1.mdr.orcon.net.nz [121.98.144.114]) by treenet.co.nz (Postfix) with ESMTP id BFAA5E6D88; Tue, 13 Jan 2015 17:14:34 +1300 (NZDT)
Message-ID: <54B49BA8.4050900@treenet.co.nz>
Date: Tue, 13 Jan 2015 17:14:32 +1300
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Constantine A. Murenin" <cnst@NetBSD.org>
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> <54B4764C.6080106@NetBSD.org>
In-Reply-To: <54B4764C.6080106@NetBSD.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/fHMjKyPefdHURnIHM9EPpDDCxgQ>
X-Mailman-Approved-At: Tue, 13 Jan 2015 08:02:54 -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 04:15:11 -0000
-----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-----
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Delan Azabani
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Eliot Lear
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … John C Klensin
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Måns Nilsson
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Patrik Fältström
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Eliot Lear
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Delan Azabani
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Mark Andrews
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Patrik Fältström
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Patrik Fältström
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Mark Andrews
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Måns Nilsson
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Patrik Fältström
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Eliot Lear
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Måns Nilsson
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Mark Andrews
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Eliot Lear
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Dave Cridland
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … James M Snell
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Poul-Henning Kamp
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Doug Barton
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Doug Barton
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Matthew Kerwin
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Greg Wilkins
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Chris Dailey
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Julian Reschke
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Martin Thomson
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Julian Reschke
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Constantine A. Murenin
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Constantine A. Murenin
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Cory Benfield
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Daniel Stenberg
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Amos Jeffries
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Willy Tarreau