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

Pete Resnick <resnick@episteme.net> Tue, 27 October 2020 20:28 UTC

Return-Path: <resnick@episteme.net>
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 7E6603A159C for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 13:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 m-3HqjjMqjKI for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 13:28:06 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC35C3A1597 for <ietf@ietf.org>; Tue, 27 Oct 2020 13:28:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 91DC0C373218; Tue, 27 Oct 2020 15:27:58 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ4S33kIuX_F; Tue, 27 Oct 2020 15:27:56 -0500 (CDT)
Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id B80BDC37320F; Tue, 27 Oct 2020 15:27:55 -0500 (CDT)
From: Pete Resnick <resnick@episteme.net>
To: Michael Thomas <mike@mtcc.com>
Cc: Ned Freed <ned.freed@mrochek.com>, IETF <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Date: Tue, 27 Oct 2020 15:27:54 -0500
X-Mailer: MailMate (1.13.2r5726)
Message-ID: <4679D0DD-7EBB-48BF-973B-6BCA9C4D5F8D@episteme.net>
In-Reply-To: <3552cbcd-2d6e-da06-5d66-d0218f6c57ac@mtcc.com>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <09B0A1A1-6534-4A44-A162-9962FFF8D8B8@cisco.com> <362d68dd6117452f925322f8180de423@cert.org> <B864FFAE-3E3E-4CEF-B832-4552C8BAE70B@cisco.com> <61d17bb9-9056-ecbd-e7f8-e7bd5bd27d97@mtcc.com> <01RRASWVT8OO005PTU@mauve.mrochek.com> <3552cbcd-2d6e-da06-5d66-d0218f6c57ac@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rud1IZH5K2jxk_UZpLXBKXH-fbM>
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 20:28:09 -0000

On 27 Oct 2020, at 12:48, Michael Thomas wrote:

> The most recent was with the STIR wg. I found some problems and 
> brought it up on the working group list and was ignored. This was 
> after they had issued RFC 8226 so I interpreted it at the time as just 
> not wanting revisit anything. I started writing a blog post about the 
> things I found, but ended giving up because there were so many things 
> wrong/underspecified. I then went through the wg archives and saw that 
> Dave Crocker had written a list of about 100 things that were 
> wrong/questionable at last call almost all of which were ignored. 
> Worse: there wasn't much intersection between our lists. So that reads 
> to me as a wg that isn't interested in hearing about problems. The 
> same thing happened to me commenting on OAUTH which caused the then 
> editor to go ballistic. None of this should be especially surprising: 
> nobody likes somebody attacking (literally in the case of security) 
> their baby.

So I presume you walked through the conflict resolution and appeals 
process, in the case of STIR starting with the STIR Chair, the ART Area 
Director, and/or the IESG as per RFC 2026 6.5.1, and in the case of 
OAUTH with the OAUTH Chair, the SEC Area Director and/or the IESG?

6.5.1 Working Group Disputes

    An individual (whether a participant in the relevant Working Group 
or
    not) may disagree with a Working Group recommendation based on his 
or
    her belief that either (a) his or her own views have not been
    adequately considered by the Working Group, or (b) the Working Group
    has made an incorrect technical choice which places the quality
    and/or integrity of the Working Group's product(s) in significant
    jeopardy.  The first issue is a difficulty with Working Group
    process;  the latter is an assertion of technical error.  These two
    types of disagreement are quite different, but both are handled by
    the same process of review.

    A person who disagrees with a Working Group recommendation shall
    always first discuss the matter with the Working Group's chair(s),
    who may involve other members of the Working Group (or the Working
    Group as a whole) in the discussion.

    If the disagreement cannot be resolved in this way, any of the
    parties involved may bring it to the attention of the Area
    Director(s) for the area in which the Working Group is chartered.
    The Area Director(s) shall attempt to resolve the dispute.

    If the disagreement cannot be resolved by the Area Director(s) any 
of
    the parties involved may then appeal to the IESG as a whole.  The
    IESG shall then review the situation and attempt to resolve it in a
    manner of its own choosing.

    If the disagreement is not resolved to the satisfaction of the
    parties at the IESG level, any of the parties involved may appeal 
the
    decision to the IAB.  The IAB shall then review the situation and
    attempt to resolve it in a manner of its own choosing.

    The IAB decision is final with respect to the question of whether or
    not the Internet standards procedures have been followed and with
    respect to all questions of technical merit.

Particularly in the case of OAUTH, if a document editor is misbehaving, 
then that needs to be dealt with. All it takes is an email message to 
start.

Unless you actually engaged with the process and actually made 
leadership aware that something was going pear-shaped, I'm not terribly 
sympathetic.

People seem very unwilling to walk through the conflict resolution and 
appeals process, and it's absolutely essential to the good functioning 
of the IETF that people use it from time to time. Again, the start of it 
is simply an email message to the chair saying "My comments are being 
ignored" or "The WG screwed up and made a bad technical choice". If you 
don't like the answers you get, well that's a different thing, but if 
you haven't actually engaged, you have only yourself to blame.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best