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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 27 October 2020 16:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 5630D3A1069 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 09:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1HAmSPxwEP77 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 09:15:59 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A073A1065 for <ietf@ietf.org>; Tue, 27 Oct 2020 09:15:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5A5FB389C9; Tue, 27 Oct 2020 12:22:36 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jAildeMquIOL; Tue, 27 Oct 2020 12:22:35 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E39CD389C8; Tue, 27 Oct 2020 12:22:35 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2E6F718B; Tue, 27 Oct 2020 12:15:57 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Salz\, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, Roman Danyliw <rdd@cert.org>, The IETF List <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
In-Reply-To: <11D079DF-614B-44CD-93F4-F53E353E31C7@akamai.com>
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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 27 Oct 2020 12:15:57 -0400
Message-ID: <17993.1603815357@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EnnDUPNT8_VuE-eTihw8A2_rBXI>
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:16:00 -0000

Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org> wrote:
    >> Having worked on OpenSSL for many years, the absolute worst thing you
    >> can do is not respond to reported vulnerabilities.  Even if it’s just an
    >> auto-reply that says “thanks we got it.”

Agreed.  And this is a place where I think it's worth having a link sent to
them that they can manage their report. (With a JWT bearer token of course)
That way, we can age-out reports for which the link was never followed,
otherwise the spam load is going to kill us.

    > I also think it would be worth pointing out more strongly that we are
    > interested in *protocol* errors, not *implementation* errors, and
    > making that distinction clear.

Given the number of people who can't distinguish openssh from openssl, I am
rather skeptical that we will get far here.   I think that we will need a
button sending implementation/protocol FAQ, and it's probably not
unreasonable that we might need three iterations to get that explanation
right, and perhaps even engage some kind of communications expert to help us
draft it.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide