Re: Time to refresh HTTP/2?

Lucas Pardue <lucaspardue.24.7@gmail.com> Mon, 07 September 2020 11:39 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 403AE3A0C27 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Sep 2020 04:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TiKf4ri6dTf3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Sep 2020 04:39:45 -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 8C9473A0C26 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 7 Sep 2020 04:39:44 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kFFSS-0006ZJ-51 for ietf-http-wg-dist@listhub.w3.org; Mon, 07 Sep 2020 11:37:12 +0000
Resent-Date: Mon, 07 Sep 2020 11:37:12 +0000
Resent-Message-Id: <E1kFFSS-0006ZJ-51@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1kFFSP-0006D4-7I for ietf-http-wg@listhub.w3.org; Mon, 07 Sep 2020 11:37:09 +0000
Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1kFFSN-0003Eo-5p for ietf-http-wg@w3.org; Mon, 07 Sep 2020 11:37:09 +0000
Received: by mail-ej1-x62c.google.com with SMTP id a26so17842239ejc.2 for <ietf-http-wg@w3.org>; Mon, 07 Sep 2020 04:37:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Hx1l4RsXSdhfVvDVViPNgqrSYT8gBtQu9Igipcr6l50=; b=ZbKwcP3c3wlL4pwWDahuMr7LBTkSuxyIjWHmDioW5FQyyzSkQdMBDiHcJ8AzImPqHv gYktnLdaEYviDSMKlGfZnGgQKrdB5IailCxd1LlIMBfGq/fFesrUJJ9ZkTsDalQPt/n0 XU9/N33Uz/Xkcxj/DQvOx7SPmQvOtnhoKnCihP+cNGb4PhLTqUgRDeQbhOEXE2wMAaQx NSoYRMgHkMhlA/mIbbdCWyDQgA3cBN50ElW7coxNWgcZ4c9WyzbsUpsc74nLVrM+OeTx wifI5XgctBpJT8b8sOtCE8Vf/2N5S06DhZb7G0Yv0Ea13aZeSCc1vjJJgHvP0p3F47qo nYmQ==
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; bh=Hx1l4RsXSdhfVvDVViPNgqrSYT8gBtQu9Igipcr6l50=; b=oVN4D8T5/tx634a3/LIZ3U9Tpv59OxWn1iZDYB7DX20xCJV6URERPT3IzzLzUFELQ5 6zQ+ErpG+AStLUns+XQMoWrn7EdF3s5ncYGRvXPBN6wjs4PTNPJvGjY3bFb6w6wvPHqh 0kE1HwYAI9Bh7fLFemuCf//QsAOQmrzXXtgyDMaAtuRbstxEeDiqRqUU7Zb0yC4Fe2dN Ag0QjTl0jMKQgCEZKm3Pdkq3UShHF7mL5g72R+yR1IXWmVVBDbXEpVq8J9Kg+kjjzim2 uBi6vdwSW5t6bokVrIYGqI9y03rm/mGo96y2kfKh1sBj+GQcjVPjYW+PaIydz1xFHovd +N6w==
X-Gm-Message-State: AOAM532gTTvt9Kv5nfLV8nk7+ov8P/2eFbsB1U2LZBfVriC6m189MYPF 6aw0j5HkVyMcGky9JdISDzSQRNWVBWJ8H4uu5c1tLVOOi6w=
X-Google-Smtp-Source: ABdhPJwToyIEKxHhAhR6ZTVpkzJhXsc7NmrIhyU3FqP3xR9iIdlRi38+BqvjhcVNL/w90fEchzl8FkcGvwn876kuQYI=
X-Received: by 2002:a17:906:43c9:: with SMTP id j9mr20378765ejn.542.1599478615419; Mon, 07 Sep 2020 04:36:55 -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>
In-Reply-To: <c0ca4dd7-f943-44ae-9940-a679aa88e878@www.fastmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Mon, 7 Sep 2020 12:36:44 +0100
Message-ID: <CALGR9oaScPCjFjtPKpe7LBCuo=my9uEgV2U=4NWryubX7vMJcA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000b2aff105aeb7a2a2"
Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-ej1-x62c.google.com
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1kFFSN-0003Eo-5p ef32c0f15aa7d21b63e9ed430253e1cc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Time to refresh HTTP/2?
Archived-At: <https://www.w3.org/mid/CALGR9oaScPCjFjtPKpe7LBCuo=my9uEgV2U=4NWryubX7vMJcA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38027
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'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
>
>