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

Toerless Eckert <tte@cs.fau.de> Mon, 26 October 2020 20:10 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 040EC3A0EE9 for <ietf@ietfa.amsl.com>; Mon, 26 Oct 2020 13:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 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, 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 QP0I0kJTpCRO for <ietf@ietfa.amsl.com>; Mon, 26 Oct 2020 13:09:58 -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 7C1A73A0ED7 for <ietf@ietf.org>; Mon, 26 Oct 2020 13:09:58 -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 8278F548068; Mon, 26 Oct 2020 21:09:53 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7DCE2440059; Mon, 26 Oct 2020 21:09:53 +0100 (CET)
Date: Mon, 26 Oct 2020 21:09:53 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Loganaden Velvindron <loganaden@gmail.com>
Cc: Roman Danyliw <rdd@cert.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <20201026200953.GD59330@faui48f.informatik.uni-erlangen.de>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <CAOp4FwTkuF_XiAYmxZdRxo9XDJciP7xADp2xYPeDORwJ=NNA8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOp4FwTkuF_XiAYmxZdRxo9XDJciP7xADp2xYPeDORwJ=NNA8A@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/6dHMv7arRj5RZ-8rS-upkbOC6O4>
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: Mon, 26 Oct 2020 20:10:08 -0000

On Mon, Oct 26, 2020 at 11:58:33PM +0400, Loganaden Velvindron wrote:
>  There have been cases where security researchers feel that the
> organizations are taking too long and then they decide to publish full
> details including Proof of Concept. I think that the document should
> encourage researchers to wait before releasing full PoC until the
> proper errata has been published.

How do you even qualify vulnerabilities as something other than
 "text we could have added to the security considerations section, but
nobody thought the attack vector would be expoited" ?

Other question:

How do you decide between protocol and implemntation ? E.g.: the distinction
between IKEv2/ESP allows me to implement better defense against DoS with
advanced endpoint hardware. TLS does not have this. So ... implementation or
protocol issue ?

Toerless

> > This guidance will serve as a complement to the recently written IETF LLC infrastructure and protocol vulnerability disclosure statement [2].
> >
> > The IESG appreciates any input from the community on the proposed text and will consider all input received by November 7, 2020.
> >
> > Regards,
> > Roman
> > (for the IESG)
> >
> > [1] This guidance text would be added to a new URL at https://www.ietf.org/standards/rfcs/vulnerabilities, and then referenced from www.ietf.org/contact, https://www.ietf.org/standards/process/, https://www.ietf.org/standards/rfcs/, and https://www.ietf.org/topics/security/
> >
> > [2] https://www.ietf.org/about/administration/policies-procedures/vulnerability-disclosure
> >
> >

-- 
---
tte@cs.fau.de