Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Toerless Eckert <tte@cs.fau.de> Wed, 28 October 2020 15:25 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 63F813A0A9B for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 08:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 Fbnd5WfgwWL3 for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 08:25:43 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff: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 1FD193A0A92 for <ietf@ietf.org>; Wed, 28 Oct 2020 08:25:38 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1169D548687; Wed, 28 Oct 2020 16:25:34 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0AF38440059; Wed, 28 Oct 2020 16:25:34 +0100 (CET)
Date: Wed, 28 Oct 2020 16:25:34 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Roman Danyliw <rdd@cert.org>, The IETF List <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <20201028152533.GC57039@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> <20201027142612.GB11207@faui48f.informatik.uni-erlangen.de> <C8ED3CFD-47FC-4746-8CE6-ADB48850A7AC@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C8ED3CFD-47FC-4746-8CE6-ADB48850A7AC@akamai.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/gG11mAst41zGpDLkYMebnzY_7Tg>
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: Wed, 28 Oct 2020 15:25:45 -0000
On Tue, Oct 27, 2020 at 02:52:01PM +0000, Salz, Rich wrote: > > > 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 ? > > I am not sure what you are trying to say. That it's hard to determine where the fault is sometimes? I don't think anyone disagrees with that. I have seen in the past and still a lot of resistance in standards track work to go beyond a mathematical proveable change of packets on a physical long enough wire. In discussions with past ADs, this has even gone as far as examples of "protocols" between two (possibly different vendor sourced) software components within a single box as being something not appropriately called standards protocol work for the IETF. Not sure if you remember the history of not allowing standardization of APIs, and only fairly recently having seen that changing. So, i am concerned about dogmatic restrictions on what can and can not be called "protocol" wrt. vulnerabilities, and hence i would strongly suggest not to use it in the name. > I worry about something like "protocol-vulnerabilities@ietf.org" becoming swamped with implementation issues, but I would support this if we agreed it was a two-year experiment or something. Too much success ? We are not paying money, so why the fear ? Any similar problems in other places ? But of course: How could we ever start something like this (that we are unfamiliar with) without calling it experimental. Same goes also for what is already proposed by Roman. > > 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. > > Patents (at least in the US) typically have an "escape clause" near the beginning, often written like "As will be readily obvious to one familiar with the field" So I see the same parallel to standards: avoiding memory exhaustion under load should be readily obvious to one familiar with the field. Except those who develop product. IMHO my one example is an ongoingly unsolved problem: how to dynamically manage limited resources in routers amongst different usrs of such resources. There are no tools to predict memory utilization for routers, so you can not even build a simulation of a network and validate upfront that it will run without memory problems. Just had a nice pondering about millions of dollars of outages regularily being fined for network failures where live&death services are running over (911). Try to figure out what type of network and operational design you need to proactively avoid such fines in the future (and the associated loss of life of such services failing). And that is in the absence of evil attackers, think about how much harder this becomes when attackers are present. Everything is easy when worst case a service can just fail, and the worst outcome is that people have to read a book instead of streaming a movie. Cheers Toerless > -- --- tte@cs.fau.de
- Call for Community Feedback: Guidance on Reportin… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Dan Harkins
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Töma Gavrichenkov
- Re: Call for Community Feedback: Guidance on Repo… Michael Richardson
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Loganaden Velvindron
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Michael Richardson
- Re: Call for Community Feedback: Guidance on Repo… Phillip Hallam-Baker
- Re: Call for Community Feedback: Guidance on Repo… ned+ietf
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Pete Resnick
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… ned+ietf
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Pete Resnick
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Pete Resnick
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Joel M. Halpern
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Jay Daley
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Dan Harkins