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, 07 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 > >
- Time to refresh HTTP/2? Martin Thomson
- Re: Time to refresh HTTP/2? Julian Reschke
- Re: Time to refresh HTTP/2? Willy Tarreau
- Re: Time to refresh HTTP/2? Julian Reschke
- Re: Time to refresh HTTP/2? Amos Jeffries
- Re: Time to refresh HTTP/2? Mark Nottingham
- Re: Time to refresh HTTP/2? Lucas Pardue
- Re: Time to refresh HTTP/2? Cory Benfield
- Re: Time to refresh HTTP/2? Martin Thomson
- Re: Time to refresh HTTP/2? Willy Tarreau
- Re: Time to refresh HTTP/2? Cory Benfield
- Re: Time to refresh HTTP/2? Julian Reschke
- Re: Time to refresh HTTP/2? Lucas Pardue
- Re: Time to refresh HTTP/2? Ian Swett
- Re: Time to refresh HTTP/2? Martin Thomson