Re: Time to refresh HTTP/2?

Ian Swett <ianswett@google.com> Mon, 07 September 2020 23:44 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4831D3A0F9E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Sep 2020 16:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 dC4yUa2bxch7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Sep 2020 16:44:22 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E3E3A0F9D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 7 Sep 2020 16:44:21 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kFQm0-0006qI-IU for ietf-http-wg-dist@listhub.w3.org; Mon, 07 Sep 2020 23:42:09 +0000
Resent-Date: Mon, 07 Sep 2020 23:42:08 +0000
Resent-Message-Id: <E1kFQm0-0006qI-IU@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ianswett@google.com>) id 1kFQlz-0006pa-9r for ietf-http-wg@listhub.w3.org; Mon, 07 Sep 2020 23:42:07 +0000
Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <ianswett@google.com>) id 1kFQlx-0008Md-Du for ietf-http-wg@w3.org; Mon, 07 Sep 2020 23:42:07 +0000
Received: by mail-il1-x12c.google.com with SMTP id w8so13695164ilj.8 for <ietf-http-wg@w3.org>; Mon, 07 Sep 2020 16:42:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=68aLm8f1R0qXlwBk9P13YhvIs4OaDcWuEzZOkDyS0a0=; b=RbWk0Yt8B5czKaXdRD0kJY2s2l49mViEE3hy/FW0cNkrp13qHkoqem4TqOpY0VdPBj bg78Se6TQFyE1zAY0NCjLtJVUUGoCYKw4nOb3CBF6xvh9ITcOo2kSD/0NFR2z5j7sVYd /8Sv39ep1vecy6pKAAJV5F2+U31nilc1gkqJl4jetYS7aOOGlmrQufv+AIcrSaIIei1Z cz4TdGWoQ70Nh8fHpmtSDGTzYr7Dup7cFIYGqJGRDp62PNznVAM+HQpvVx9wixZKp8Fz /WQOVfpGypDyc3sQbK8PwHpzQIrJOqiay8N/VhTF7XxhfCHq29iZ/7E8zavva4v9+jNt DDYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=68aLm8f1R0qXlwBk9P13YhvIs4OaDcWuEzZOkDyS0a0=; b=NuSsR7JHwZYiNnQnIQNObQAbkaCSrnKq0nUZbF3/Xx1MD6twBkl1W0NDDURr0y5+wN abyiGLPid7VvDwRQmWGVZn4Sq4eGZcsWIwRbiXb/WwQSEncL44PHSLldKRAeumVuBcPT 2OaC7Cc1fJhqrLGVkvTOTjFcJczYJCFYjLsdhr/dCjxMlv+zX5lmnGn550EoAfp8vzaw RubnSFa3+J/hCZw6ADfyRY91iNn2I9kb6BrEnNSl38/LORc+vZXK9lV9GbeTIyweNxLm OpY/hM6LXga7PNx5jbQGjNMmQKhp5nqOolqo3a9F5BT8urpdpbHc68jnytbdMgn3ZS1R X2IA==
X-Gm-Message-State: AOAM533S8rZsVyHb2P230Uo8l8klbU98Cscq2jisMALghmZ2Ls1oorKF VYFAPLQlh/65RhQhm9W3IUfXrF5S7E8y/gWVfj9Rfn0jpC0=
X-Google-Smtp-Source: ABdhPJyQTkzdhs3+tf5nB8bdv+NF+o/D5ZU+AvJ28SsPJIxcQtjnFBVlSe/1qTH6BYOwcfDyn7JhtnaZswi2Pc9IY5Y=
X-Received: by 2002:a92:4d1:: with SMTP id 200mr21627175ile.223.1599522113996; Mon, 07 Sep 2020 16:41:53 -0700 (PDT)
MIME-Version: 1.0
References: <4facac0f-867d-4947-840c-fcd675a09d51@www.fastmail.com> <19ED7610-A661-4E96-B25A-352109DFFFCD@mnot.net> <c0ca4dd7-f943-44ae-9940-a679aa88e878@www.fastmail.com> <CALGR9oaScPCjFjtPKpe7LBCuo=my9uEgV2U=4NWryubX7vMJcA@mail.gmail.com>
In-Reply-To: <CALGR9oaScPCjFjtPKpe7LBCuo=my9uEgV2U=4NWryubX7vMJcA@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Mon, 07 Sep 2020 19:41:42 -0400
Message-ID: <CAKcm_gMtfNF-s4NndcyNUBBhRzMQFmGhm6MX_WC2S=7Eoui10A@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>, Bence Béky <bnc@google.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000006acf0e05aec1c3ba"
Received-SPF: pass client-ip=2607:f8b0:4864:20::12c; envelope-from=ianswett@google.com; helo=mail-il1-x12c.google.com
X-W3C-Hub-Spam-Status: No, score=-19.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1kFQlx-0008Md-Du 3ba3cd4e0c465f4a291523eaa881c585
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Time to refresh HTTP/2?
Archived-At: <https://www.w3.org/mid/CAKcm_gMtfNF-s4NndcyNUBBhRzMQFmGhm6MX_WC2S=7Eoui10A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38030
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

I'd support:

1) Removing h2c!
2) Removing priorities entirely, but not adding anything new
3) Adding TLS 1.3
4) Adding GREASE, or at least clarifying the text to make it clear that
greasing is allowed, since there was some confusion on that.
5) Adding security considerations/etc for the Netflix/Purple Wolf attack
vectors.

Hopefully, not much else, besides errata.

Is the intent to change the ALPN?  Because given the
challenges GREASEing SETTINGS and various extension frames, I think that
could be helpful. +Bence Béky <bnc@google.com>


On Mon, Sep 7, 2020 at 7:40 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> I'll add one more to the laundry list. In August 2019 Netflix disclosed
> resource exhaustion vectors [1]. Given the range of affected
> implementations, I wonder if there is any room to improve or expand RFC
> 7540 section 10.5
>
> Lucas
>
> [1] -
> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md
>
> On Mon, Aug 31, 2020 at 1:14 AM Martin Thomson <mt@lowentropy.net> wrote:
>
>> It seems like everyone wants their swing at this.
>>
>> To be perfectly frank, I wasn't planning on addressing any of these.
>> It's a long and slippery slope.
>>
>> But I will start a list and we can discuss where to draw the line.
>>
>> On Fri, Aug 28, 2020, at 23:00, Mark Nottingham wrote:
>> > What about priorities?
>>
>> I would be opposed to publishing a new version with a replacement
>> priorities scheme before that scheme were proven.  It might be OK to
>> publish a version with text with the priority scheme removed, with a note
>> about it not being interoperable in practice or some such.
>>
>> Here's some historical info that seems relevant.  The following text
>> appears in the draft, commented out:
>>
>> > Note that stream dependencies have not yet been validated in practice.
>> The theory
>> > might be fairly sound, but there are no implementations currently
>> sending these.  If it
>> > turns out that they are not useful, or actively harmful,
>> implementations will be requested
>> > to avoid creating stream dependencies.
>>
>> While this might be true, I don't want a reprise.
>>
>> On Sat, Aug 29, 2020, at 00:54, Cory Benfield wrote:
>> > I'm +1 on this as well. I'd like to see the extensions rolled in,
>> > along with GREASE. I'm a bit more nervous about the priority changes
>> > given how relatively young they are.
>>
>> Cory agrees with me, so I'm probably right....  As for GREASE, I'm
>> reluctant to include new design work, but it might be small enough to meet
>> the cut.
>>
>> On Fri, Aug 28, 2020 at 12:59:03PM +0200, Julian Reschke wrote:
>> > Actually, I was going to suggest that as well, but mainly to align
>> > HTTP/2 with the new core specs - it would be good to say how the cleanup
>> > affects the references from HTTP/2.
>>
>> I definitely had that in mind.  My plan is to do that once the -core
>> drafts leave the working group (so that there is no further risk of
>> reshuffling.
>>
>> > Am 28.08.2020 um 13:27 schrieb Willy Tarreau:
>> > +1 as well. Wouldn't it be an opportunity to also reference (or even
>> merge)
>> > the extensions such as RFC8441 which adds the ":protocol" pseudo-header
>> ?
>>
>> I tend to think that 8441 wouldn't make the cut; it's discrete in the
>> same way that the ORIGIN or ALTSVC frames are.
>>
>> On Fri, Aug 28, 2020, at 21:52, Julian Reschke wrote:
>> > And it probably should include RFC 8740 ("Using TLS 1.3 with HTTP/2")...
>>
>> 8740 might make the cut.
>>
>> Just to add to the list:
>>
>> * midders (or multiple trailers or whatever they are) are something I'm
>> still uncertain about
>> * a re-design that included better 0-RTT design is probably off the table
>> * removing h2c is very tempting, with similar rationale to PRIORITY
>>
>>