Re: HTTP/2 GREASE, Results, and Implications

Tom Bergan <tombergan@chromium.org> Fri, 15 November 2019 19:38 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 D640F120956 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Nov 2019 11:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 kEEpB-xHo_ff for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Nov 2019 11:38:09 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 298E91208E0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 Nov 2019 11:38:09 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iVhNU-0008Pa-Cn for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Nov 2019 19:35:32 +0000
Resent-Date: Fri, 15 Nov 2019 19:35:32 +0000
Resent-Message-Id: <E1iVhNU-0008Pa-Cn@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <tombergan@chromium.org>) id 1iVhNS-0008Of-7z for ietf-http-wg@listhub.w3.org; Fri, 15 Nov 2019 19:35:30 +0000
Received: from mail-ot1-x32b.google.com ([2607:f8b0:4864:20::32b]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <tombergan@chromium.org>) id 1iVhNQ-0004ay-OP for ietf-http-wg@w3.org; Fri, 15 Nov 2019 19:35:30 +0000
Received: by mail-ot1-x32b.google.com with SMTP id 5so8993778otk.1 for <ietf-http-wg@w3.org>; Fri, 15 Nov 2019 11:35:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x+4ilDMBnsyZkA+Sa0t257btWVAXYAk0wk3YG4Ya2Ak=; b=Zt8SPBLXf0dbEWTgbYadu+dA/ojJLSwK/t15xc2OQTXDht8S99Jc94+5lzDZUkghKh nHSeYtdop7BeEM9nhw6RwSV7E8lEb7qmIqHY6PwQ6RyLdKvvw+NZtqYnkFtJABMc4LJS SPehNo6drVeuAx1S6diGj05CNbiEHREHU/zm0=
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=x+4ilDMBnsyZkA+Sa0t257btWVAXYAk0wk3YG4Ya2Ak=; b=b6HLJkh5Q5zBODsQbhu8K4auLkk5HBB1tU7PBUo7vO+zN//NREeQiqHEVV3krKcwyH ov98CjqR1Z8PsuYvd8/i7/0OYGvzZkkNSkYQr09FIGZinowo9LNoidUuGnpDb6ad4NGA fbFBv39oeCNvUOFGkQ/GoAzedBMYkxcDhd6lLKInWw0Mb7EhwuM463EaapnFRDQERxti 0vOjAcz2bZ7chANEqbx1osKCqqny6Ay0nwd9QIVB5EhFZMXlqfgkhV1fdawqt8qZmOiP BKueVjeEjjNwQGV7qYxoSlyTu2HwrPUfstHGqmNc2hIYcPTVO4Jhlo09uCiDmi1x+LWJ RYEQ==
X-Gm-Message-State: APjAAAX/L/MYlkU6kl7abMfVD9Slx2SGmO0zoWj5ImAK3W36nl29JYA+ z0/P593D9sPMy1qpB/YxaktR/XzO+ig=
X-Google-Smtp-Source: APXvYqxlthFmMCZX0EG2QW3iuizW9R3+Sf5dRT7TreixA/p+RtAe6JIeqyAnxOj5U0mHcu9Tg75MYg==
X-Received: by 2002:a9d:3d76:: with SMTP id a109mr13074267otc.233.1573846526940; Fri, 15 Nov 2019 11:35:26 -0800 (PST)
Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com. [209.85.210.54]) by smtp.gmail.com with ESMTPSA id h79sm3170462oib.3.2019.11.15.11.35.26 for <ietf-http-wg@w3.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Nov 2019 11:35:26 -0800 (PST)
Received: by mail-ot1-f54.google.com with SMTP id m15so8970971otq.7 for <ietf-http-wg@w3.org>; Fri, 15 Nov 2019 11:35:26 -0800 (PST)
X-Received: by 2002:a05:6830:11c1:: with SMTP id v1mr5876455otq.13.1573846525652; Fri, 15 Nov 2019 11:35:25 -0800 (PST)
MIME-Version: 1.0
References: <BN6PR2201MB1700D10A34C72213C78E09A6DA630@BN6PR2201MB1700.namprd22.prod.outlook.com> <20191031155259.GC30674@1wt.eu> <CACMu3trL5UMukoPd8Nr4W-bMsyH+WKUnwg16yxu3tN5D=uZt8w@mail.gmail.com> <20191031203458.GA31017@1wt.eu> <CACMu3toue60Y_6Qxpzsqw-fOByc3Qjv=AG8Ed_DGvkR1EYn+4w@mail.gmail.com> <20191101131903.GA1988@1wt.eu> <6F4160E3-D460-4DD9-9931-348479F6437F@greenbytes.de> <CACMu3trFUKpywX1GoChNn59B1tOmOUuaPESVFPy2u7Ah3gy0Jw@mail.gmail.com> <20191106202411.GA15081@1wt.eu> <CA+3+x5GyCgh2JROXwd+mo3Rsew1EDzJ6diyvHoLv3JwbJLg6Xg@mail.gmail.com> <20191115155913.GD25181@1wt.eu>
In-Reply-To: <20191115155913.GD25181@1wt.eu>
From: Tom Bergan <tombergan@chromium.org>
Date: Fri, 15 Nov 2019 11:35:13 -0800
X-Gmail-Original-Message-ID: <CA+3+x5GNnHn-MyYO0cDhc6ma1A4CfJMTZ5KBV+ifD5VYkj6brA@mail.gmail.com>
Message-ID: <CA+3+x5GNnHn-MyYO0cDhc6ma1A4CfJMTZ5KBV+ifD5VYkj6brA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: =?UTF-8?Q?Bence_B=C3=A9ky?= <bnc@chromium.org>, Stefan Eissing <stefan.eissing@greenbytes.de>, Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000182a00059767b349"
Received-SPF: pass client-ip=2607:f8b0:4864:20::32b; envelope-from=tombergan@chromium.org; helo=mail-ot1-x32b.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1iVhNQ-0004ay-OP 0a0b1e602a6a02a4ccf4a81d450e94b5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <https://www.w3.org/mid/CA+3+x5GNnHn-MyYO0cDhc6ma1A4CfJMTZ5KBV+ifD5VYkj6brA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37138
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>

On Fri, Nov 15, 2019 at 7:59 AM Willy Tarreau <w@1wt.eu> wrote:

> I do have a real concern regarding
> deployed code now based on the fact that the way this ambiguity is present
> can have caused solid roots to be set inside some software. For example
> when trying to address the issue in haproxy, I noticed that we've used
> bit fields of permitted frame types to more easily match what's allowed
> or not. When working around them I figured that changing tests constructed
> this way to think in terms of exclusion instead wasn't always as riskfree
> as I initially imagined, and if we relax certain rules we need to be sure
> that (almost) all implementations will accept to revisit their code and
> take such risks in maintenance versions to allow smooth updates of deployed
> components, or we really risk the same type of fragmentation that we've
> known with HTTP/1.1.
>

It's important to work through these implementation issues. If
implementations are difficult to change, then we'll probably need to take
Bence's suggestion, or something similar.

That said, I don't fully understand the problem here. Can you elaborate?
Assuming the implementation throws away unknown frames immediately, as
suggested by Section 5.5, only the known frames are left. At that point, it
shouldn't matter whether the bit mask describes permitted frames or
forbidden frames -- both approaches are equivalent. FWIW, the Go H2 library
(client
<https://github.com/golang/net/blob/42ef8dbebecb1aa62a4f25c93e117a1de4d9f4fc/http2/transport.go#L1783>,
server
<https://github.com/golang/net/blob/42ef8dbebecb1aa62a4f25c93e117a1de4d9f4fc/http2/server.go#L1430>)
and Chrome both "throw away unknown frames immediately" (although Chrome
has a small bug; crbug.com/1025311).


> But I still do have some concerns about our ability to extend the
> protocol even without this. What if a new frame expects an ACK for
> example ? Probably this one will also require an extension.
>

I agree. If a new frame type requires an ACK, that needs to be negotiated.