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

Roman Danyliw <rdd@cert.org> Tue, 27 October 2020 19:49 UTC

Return-Path: <rdd@cert.org>
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 E0DBC3A16D7; Tue, 27 Oct 2020 12:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 zDjAhPq7In4v; Tue, 27 Oct 2020 12:49:15 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 8F3AD3A1678; Tue, 27 Oct 2020 12:49:06 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09RJmq3k023071; Tue, 27 Oct 2020 15:48:52 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 09RJmq3k023071
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1603828132; bh=mPEaFzBRWe2nq804GDoEiLtak2ZTkVrsKKEfZ5g8UIQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=cBA93vCmm2y1JGy0U0gcVQfdc69FSqF6HZIp0LfVJfIKZzrAoqJpzxAke/8jR6Bbd U2zM4Bg/XV2D6U7MarTmLDBw85CNN/wLetcTOQ4fKyxA8YXbQ+5mTn2HQM3Uszw5GV 100GaGysErpuhsFWJyUXmnlUS+h1QpLdWi7i+SH0=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09RJmnYm013042; Tue, 27 Oct 2020 15:48:49 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 27 Oct 2020 15:48:48 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 27 Oct 2020 15:48:48 -0400
From: Roman Danyliw <rdd@cert.org>
To: Toerless Eckert <tte@cs.fau.de>
CC: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Thread-Topic: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Thread-Index: Adapa+D5Cfcs8r0xT9Wg091feiESVgACv7UAAJ6CsYAAA2INcAAhWx0AAASe4YA=
Date: Tue, 27 Oct 2020 19:48:48 +0000
Message-ID: <773cac97c1ca407ab8745cbfa002dd7f@cert.org>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <EB7E8597-087A-4E84-A90E-DC8DF7F089EB@akamai.com> <20201026193707.GC59330@faui48f.informatik.uni-erlangen.de> <fb5d37904b3d4cf5877a715192971f6b@cert.org> <20201027130903.GA11207@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20201027130903.GA11207@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.126]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/aGsi2CKH0h8ojwk6z7MYibLALVo>
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 19:49:21 -0000

Hi Toerless!

> -----Original Message-----
> From: Toerless Eckert <tte@cs.fau.de>
> Sent: Tuesday, October 27, 2020 9:09 AM
> To: Roman Danyliw <rdd@cert.org>
> Cc: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>; ietf@ietf.org
> Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol
> Vulnerabilities
> 
> Roman:
> 
> What you describe in the text is already suficiently convoluted (yepp, that's
> what we are, you can't significanlty simplify it ;-)) that anyone not already
> actively engaged in the IETF for longer would certainly be confused enough to
> have question about process, how to follow up from reporting, looking for help
> and so on. Hence the proposal to not only set up a list like vulnerability-
> report@ietf.org, but also an open discussion mailing lists vulnerability-
> discuss@ietf.org so that there is at least an easy, open point to discuss.
>
> Or let me put it differently: I would not like for IETF to pick up on a process like
> vulnerability reporting if it ends up being solely behind closed doors without
> having a list for the community and those we want to attact to discuss it. As
> any non-WG mailing list, discussion doesn't mean to give any responsibility to
> produce IETF output to such a list.
>
> Of course your text should go to the web page. I was merely pointing out that
> anything beyond the established process we have today might want to be
> starting less informal, as i think we wouldn't know by now what an ideal
> process would be.

Sure.  Irrespective of what we do with the proposed text or future process, we can definitely create non-WG mailing list to discuss vulnerability disclosure processes in the IETF.  

To be clear, this list isn't intended to handle actual vulnerability information, but to discuss the processes by which the IETF might want to handle it, right?

Regards,
Roman

> Finally: don't worry about taking the word "vulnerability" away from possible
> later WGs. Its always been FCFS on names.
>
> Cheers
>     toerless
> 
> 
> On Tue, Oct 27, 2020 at 11:56:35AM +0000, Roman Danyliw wrote:
> > Hi Toerless!
> >
> > Thanks for the review.  Inline ...
> >
> > > -----Original Message-----
> > > From: Toerless Eckert <tte@cs.fau.de>
> > > Sent: Monday, October 26, 2020 3:37 PM
> > > To: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
> > > Cc: Roman Danyliw <rdd@cert.org>; ietf@ietf.org
> > > Subject: Re: Call for Community Feedback: Guidance on Reporting
> > > Protocol Vulnerabilities
> > >
> > > Thanks, Roman
> > >
> > > Great job on describing the "process". Unfortunately, i think our
> > > process sucks, e.g. errata will only be applicable in a small subset of cases.
> > >
> > > In general, it will not be possible to find community consensus to
> > > resolve vulnerabilities, and even if there is consensus, doing
> > > document updates takes even longer. Especially because in most cases
> > > you want to see good evidence that the attack vector is likely to be
> > > used
> > >
> > > (just had a discussion today on dnsop, where the first reaction to a
> > > protocol implementation hardening suggestion i wanted to make in a
> > > draft  was rejected with "we have not seen this attack vector being a
> problem so far").
> > >
> > > So, maybe we can while we have time step back a bit and think about
> > > what we could do to incrementally improve our processes:
> >
> > I want to separate the above into discrete problems in the vulnerability
> coordination process -- there is the reporting (how and to who to convey the
> information), validation/triage (how to ensure the accuracy of the information)
> and remediation (what does one do about it).  No question that the processes
> by which the community finds consensus on the remediation is challenging.  As
> might be convincing a recipient on the validating of the vulnerability to begin
> with.  However, neither of these is the scope of the proposal which is intended
> to be a much less ambitious scope -- how to _report_ the vulnerability to the
> IETF.
> >
> > > I would suggest creating two mailing lists:
> > >
> > >   vulnerability-discuss@ietf.org or vulnerability-dispatch@ietf.org
> > >   vulnerability-report@ietf.org
> >
> > Point taken about the different between issues with operational practices and
> protocol vulnerabilities.
> >
> > The thinking behind the last-resort alias name (protocol-vulnerability@ietf)
> was to provide sufficient distance from future WG names (*-dispatch@ietf), the
> LLC disclosure alias (operational-vulnerability@ietf.org), and any sense of it
> looking like it was triaging implementation issues.
> >
> > > I think we don't need "protocol" in the names, because there are
> > > also vulnerabilities to operational practices from OPS. Or probably
> > > vulnerabilities in data models (hmm... are there ? -).
> > >
> > > The first list of course should serve as an easy entry point for
> > > anyone worried about a particular vulnerability or the process and
> > > wants to get answers. And hopefully it can be dispatched to the right WG
> or more specific mailing list.
> > > And then of course discuss about the process because with something
> > > as new to the IETF as this we probably want to experiment with the
> process.
> > >
> > > The second list of course is what you called
> > > protocol-vulnerability@ietf.org
> >
> > As I noted in my response to Eliot, the IETF could definitely go this way and
> have a centralized reporting, triage and dispatch process.  However, this would
> require a deliberate, consensus process.  The proposal here is a text for the
> website to explain what we do now.
> >
> > > Ultimately, i think we will have the classical issue that more
> > > process on this front would likely benefit from some intermediate
> > > output format between draft/RFC and errata, i think Warren once
> > > called this "living documents". And i think we should just experiment with
> that starting with Wiki or the like.
> >
> > There is no reason why we couldn't put this text on a wiki, however it might
> be less impactful there.  The thinking was to make the text prominent on the
> main website.
> >
> > Regards,
> > Roman
> >
> >
> > > Cheers
> > >     Toerless
> > >
> > >
> > > On Fri, Oct 23, 2020 at 07:58:29PM +0000, Salz, Rich wrote:
> > > > I would put the "WE don't pay" sentence at the top, right after
> > > > the intro
> > > paragraph.
> > > >
> > > > ???On 10/23/20, 2:46 PM, "Roman Danyliw" <rdd@cert.org> wrote:
> > > >
> > > >     Hi!
> > > >
> > > >     The Internet Engineering Steering Group (IESG) is seeking
> > > > community input
> > > on reporting protocol vulnerabilities to the IETF.  Specifically,
> > > the IESG is proposing guidance to be added to the website at [1] to
> > > raise awareness on how the IETF handles this information in the
> > > standards process.  The full text (which would be converted to a web page)
> is at:
> > > >
> > > >
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > > medi
> > > > a_documents_Guidance-5Fon-5FReporting-5FVulnerabilities-5Fto-5Fthe
> > > > -5FI
> > > > ETF-
> > >
> 5FsqEX1Ly.pdf&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx8
> > > 6F
> > > > tsKI-
> > >
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=WZ8lhkI2-
> > > LqfcEW
> > > > 09br2ItDhqh8U456y_8xZlTzatI0&e=
> > > >
> > > >     This text is intended to be written in an accessible style to
> > > > help
> > > vulnerability researchers, who may not be familiar with the IETF,
> > > navigate existing processes to disclose and remediate these
> > > vulnerabilities.  With the exception of creating a last resort
> > > reporting email alias (protocol- vulnerability@ietf.org), this text
> > > is describing current practices in the IETF, albeit ones that may not be
> consistently applied.
> > > >
> > > >     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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > > stan
> > > >
> > >
> dards_rfcs_vulnerabilities&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0
> > > GbR
> > > > 0h9Fvx86FtsKI-
> > > w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=lWrYlX
> > > > 1pV0mIGIcyUbXXN4Bl4YdeeGExr508slPDgW8&e= , and then referenced
> > > > from
> > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_c
> > > > onta
> > > > ct&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
> > > w&m=ZJ9CHN
> > > >
> > >
> axYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=dVVEqnGAgxYTWKmevWh
> > > 2AwAdymUCMQ
> > > > Gs85MMBB2FYPs&e= ,
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > > stan
> > > >
> > >
> dards_process_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx
> > > 86FtsK
> > > > I-
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=A2QnAr-
> > > kezfIPFF3J9
> > > > 2rsAfyrfHzpdFR2gquELSO_5w&e= ,
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > > stan
> > > >
> > >
> dards_rfcs_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86F
> > > tsKI-w
> > > >
> > >
> &m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=KtvC1SVlfZTcF
> > > hsHQ9RvF
> > > > _nm856pcSrouxEKNahI5UQ&e= , and
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > > topi
> > > >
> > >
> cs_security_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86
> > > FtsKI-
> > > >
> > >
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=EN9keXxRYE
> > > MvBt-h9ugF
> > > > VkY3-MUUAv-X9mP7OpOa_po&e=
> > > >
> > > >     [2]
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > > abou
> > > > t_administration_policies-2Dprocedures_vulnerability-2Ddisclosure&
> > > > d=Dw
> > > > IFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
> > > w&m=ZJ9CHNaxYta4R
> > > >
> > >
> wzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=VAKeetf0jcEomZCLvqzNjCqSADPvs
> > > RZPugO5C
> > > > UryXDI&e=
> > > >
> > > >
> 
> --
> ---
> tte@cs.fau.de