Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Phillip Hallam-Baker <phill@hallambaker.com> Tue, 27 October 2020 16:24 UTC
Return-Path: <hallam@gmail.com>
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 5BB1E3A10C4 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 09:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 zwHB3NKSzWvg for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 09:24:48 -0700 (PDT)
Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599703A10C3 for <ietf@ietf.org>; Tue, 27 Oct 2020 09:24:48 -0700 (PDT)
Received: by mail-yb1-f172.google.com with SMTP id b138so1744138yba.5 for <ietf@ietf.org>; Tue, 27 Oct 2020 09:24:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q9MjKL9iJFS2kMy2MVgrq1gQ1rVv14wh+QzhGUpzIFE=; b=k3z8LOxOh1JBQzbM/nbVKl+UTtRg6HjH6xE3mTR4QbPS613Ei/+LB9hDXDwhs9Ewzo 5C1HRPoOoNtymQtjDWT9Lo4OY5RU8Fr/hV6cxKz+OJQSRGJQegerYFB4GANB43aroWJA YzE6b3UpD1NRcoBwixMHEhQVsfTu44ehKtFYiUW7P81ScJx6uQB2hOCp4cQ36NTRCx2B tPDI8USridLSSC6rv9QLKE1slRcNPjNJtl7zQsP6GXD3OpGAKdD0sVN3nj7HIhjhkPCY DB4VjFoQZsqKfjWVXbhaiyeNWoUuR5FiogFkKCt985xAXieD9tifU0nMUojOlLURf2/1 0wFw==
X-Gm-Message-State: AOAM533BpOyi611xaH+57voXhgwTjxgrOvgswnSljuimBC43TUKyP6Hp sHwwddrVZjbbLd8SS+/7E6WWSC6fh6QoGbEmFTjCOTCVbJs=
X-Google-Smtp-Source: ABdhPJzU3hmJti2PktmGH17Ya8qFSFDx924INNpV3yII9vg0+HtOun7Jhv/LcIsLVNB1oA6IKe+JzIpUj1CGVlqkB90=
X-Received: by 2002:a25:6e8b:: with SMTP id j133mr4546843ybc.273.1603815887419; Tue, 27 Oct 2020 09:24:47 -0700 (PDT)
MIME-Version: 1.0
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <EB7E8597-087A-4E84-A90E-DC8DF7F089EB@akamai.com> <20201026193707.GC59330@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20201026193707.GC59330@faui48f.informatik.uni-erlangen.de>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 27 Oct 2020 12:24:36 -0400
Message-ID: <CAMm+LwhCgY4s2roVTWVLAML7_geR+aHNqrjeyWjSq+2ure4ckw@mail.gmail.com>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
To: Toerless Eckert <tte@cs.fau.de>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000413dbf05b2a97cce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/SFOxHRUg-eSDPsATKrBeMhV_Le4>
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 16:24:50 -0000
I am not sure that we can define a process. A meta-process is probably better. Every issue tends to be different. Take the response to the Kaminsky attack for instance, that wasn't really a protocol error, it was an implementation issue. But the nexus of developers was here. What we need is to balance the need to prevent hostile exploits of a vulnerability and providing a forcing function to get things done. I am not at all impressed by certain companies who have a policy of disclosing vulnerabilities in their competitor's products on a fixed timetable of their choosing. On the other hand, I did tell Netscape about the issues in their random number generation system 18 months before they were rediscovered by reverse engineering the code. A good rule of thumb that I try to follow is to consider how I would respond (or tell my CEO to respond) if asked to defend my actions in a Congressional hearing. That was not a purely theoretical possibility in the 1990s. On Mon, Oct 26, 2020 at 3:37 PM Toerless Eckert <tte@cs.fau.de> wrote: > 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 would suggest creating two mailing lists: > > vulnerability-discuss@ietf.org or vulnerability-dispatch@ietf.org > vulnerability-report@ietf.org > > 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 > > 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. > > 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_media_documents_Guidance-5Fon-5FReporting-5FVulnerabilities-5Fto-5Fthe-5FIETF-5FsqEX1Ly.pdf&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=WZ8lhkI2-LqfcEW09br2ItDhqh8U456y_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_standards_rfcs_vulnerabilities&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=lWrYlX1pV0mIGIcyUbXXN4Bl4YdeeGExr508slPDgW8&e= > , and then referenced from > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_contact&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=dVVEqnGAgxYTWKmevWh2AwAdymUCMQGs85MMBB2FYPs&e= > , > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_standards_process_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=A2QnAr-kezfIPFF3J92rsAfyrfHzpdFR2gquELSO_5w&e= > , > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_standards_rfcs_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=KtvC1SVlfZTcFhsHQ9RvF_nm856pcSrouxEKNahI5UQ&e= > , and > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_topics_security_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=EN9keXxRYEMvBt-h9ugFVkY3-MUUAv-X9mP7OpOa_po&e= > > > > [2] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_about_administration_policies-2Dprocedures_vulnerability-2Ddisclosure&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=VAKeetf0jcEomZCLvqzNjCqSADPvsRZPugO5CUryXDI&e= > > > > > >
- 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