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=
> >
> >
>
>