Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Toerless Eckert <tte@cs.fau.de> Tue, 27 October 2020 14:26 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366E53A0D36 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 07:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 yS96wxdkugc0 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 07:26:18 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3793A0D2B for <ietf@ietf.org>; Tue, 27 Oct 2020 07:26:17 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id CC561548019; Tue, 27 Oct 2020 15:26:12 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C6A8B440059; Tue, 27 Oct 2020 15:26:12 +0100 (CET)
Date: Tue, 27 Oct 2020 15:26:12 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, Roman Danyliw <rdd@cert.org>, The IETF List <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <20201027142612.GB11207@faui48f.informatik.uni-erlangen.de>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <09B0A1A1-6534-4A44-A162-9962FFF8D8B8@cisco.com> <362d68dd6117452f925322f8180de423@cert.org> <B864FFAE-3E3E-4CEF-B832-4552C8BAE70B@cisco.com> <11D079DF-614B-44CD-93F4-F53E353E31C7@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <11D079DF-614B-44CD-93F4-F53E353E31C7@akamai.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hbP8tO7olYlunaUIhOk8_4wgoJs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 14:26:20 -0000

On Tue, Oct 27, 2020 at 01:59:35PM +0000, Salz, Rich wrote:
> Having worked on OpenSSL for many years, the absolute worst thing you can do is not respond to reported vulnerabilities.  Even if it???s just an auto-reply that says ???thanks we got it.???
> 
> I also think it would be worth pointing out more strongly that we are interested in *protocol* errors, not *implementation* errors, and making that distinction clear.

Again, just to re-emphasize my desire that three should be an open discussion list for
vulnerabilities (vulnerability-discuss), because IMHO this is one of the likely repeatedly
 incurring points of contentions as to where to draw the line. Which IMHO needs to be explored.

One initial definition might be "implementation error is one that can be fixed without
changing the protocol spec text" (i guess, i have not seen a better definition).

So lets say i have seen enough cases where routers stopped forwarding any traffic because
they ran out of memory because someone attacked the router creating to much protocol
state. Lets pick your poison, in my case it was easily user generated multicast state,
others may prefer BGP or IGPs.

So... should the protcol spec have a requirement stating that implementations
MUST ensure this can not happen, and - oh, go figure out how to do that, not a
protocol issue ?

In patents, patent protection is only granted when the description is
sufficient to build a working model. So if you want to claim that a protocol
is not at fault for an attack, its description needs to be sufficient to
make it clear how to build a working model protecting against the attack.

If you apply that guideline to IETF protocol specs, you will draw blanks all
over the place. At least in routing.

Cheers
    Toerless