H2: Should there be a limit to tolerance ?

Poul-Henning Kamp <phk@phk.freebsd.dk> Fri, 17 February 2017 09:55 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 AC9131295D7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Feb 2017 01:55:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uSIIcstLWCbJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Feb 2017 01:55:07 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E80129490 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 17 Feb 2017 01:55:06 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cefDQ-0005W0-FD for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Feb 2017 09:52:36 +0000
Resent-Date: Fri, 17 Feb 2017 09:52:36 +0000
Resent-Message-Id: <E1cefDQ-0005W0-FD@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <phk@phk.freebsd.dk>) id 1cefDJ-0005VB-N8 for ietf-http-wg@listhub.w3.org; Fri, 17 Feb 2017 09:52:29 +0000
Received: from phk.freebsd.dk ([130.225.244.222]) by mimas.w3.org with esmtp (Exim 4.84_2) (envelope-from <phk@phk.freebsd.dk>) id 1cefDD-0003g2-Ej for ietf-http-wg@w3.org; Fri, 17 Feb 2017 09:52:24 +0000
Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6856B27366 for <ietf-http-wg@w3.org>; Fri, 17 Feb 2017 09:52:01 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v1H9q0u0090503 for <ietf-http-wg@w3.org>; Fri, 17 Feb 2017 09:52:00 GMT (envelope-from phk@phk.freebsd.dk)
To: ietf-http-wg@w3.org
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <90501.1487325120.1@critter.freebsd.dk>
Date: Fri, 17 Feb 2017 09:52:00 +0000
Message-ID: <90502.1487325120@critter.freebsd.dk>
Received-SPF: none client-ip=130.225.244.222; envelope-from=phk@phk.freebsd.dk; helo=phk.freebsd.dk
X-W3C-Hub-Spam-Status: No, score=-5.3
X-W3C-Hub-Spam-Report: AWL=-1.407, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cefDD-0003g2-Ej 26f46e7b685035666b8f87c93001a4d7
X-Original-To: ietf-http-wg@w3.org
Subject: H2: Should there be a limit to tolerance ?
Archived-At: <http://www.w3.org/mid/90502.1487325120@critter.freebsd.dk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33571
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

In RFC7540, 5.5 we have:

   Implementations MUST ignore unknown or unsupported values in all
   extensible protocol elements.  Implementations MUST discard frames
   that have unknown or unsupported types.  This means that any of these
   extension points can be safely used by extensions without prior
   arrangement or negotiation.

Such unlimited tolerance for what might be plain garbage seems unwise.

We have covered the trivial case of an endless stream of zero bytes
(DATA on stream=0 is CONN::PROTOCOL_ERROR) but a surprisingly large
percentage of random garbage runs straight through the clause above
and into /dev/null.

Has anybody else implemented limits to patience in this area, and if
so should we try to coordinate our criteria ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.