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

Benjamin Kaduk <kaduk@mit.edu> Wed, 28 October 2020 18:47 UTC

Return-Path: <kaduk@mit.edu>
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 ABB713A0AE0 for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 11:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 A03vp2zEAIGw for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 11:47:11 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8AA803A0AE7 for <ietf@ietf.org>; Wed, 28 Oct 2020 11:47:10 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09SIkpuP032036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 14:46:56 -0400
Date: Wed, 28 Oct 2020 11:46:51 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Toerless Eckert <tte@cs.fau.de>
Cc: "Salz, Rich" <rsalz@akamai.com>, The IETF List <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <20201028184651.GH39170@kduck.mit.edu>
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> <20201028152533.GC57039@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20201028152533.GC57039@faui48f.informatik.uni-erlangen.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Q2w4_6ZJUlc0f4lAiJuu9tBS78s>
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 18:47:13 -0000

On Wed, Oct 28, 2020 at 04:25:34PM +0100, Toerless Eckert wrote:
> 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.

FWIW, any reluctance to standardize APIs is not universal -- RFC 1508 dates
from 1993.

-Ben