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

Michael Thomas <> Wed, 28 October 2020 01:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 488BC3A03FB for <>; Tue, 27 Oct 2020 18:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o8jV_C7fazTi for <>; Tue, 27 Oct 2020 18:26:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CCB03A03F2 for <>; Tue, 27 Oct 2020 18:26:06 -0700 (PDT)
Received: by with SMTP id c20so1961084pfr.8 for <>; Tue, 27 Oct 2020 18:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=GnMQRfzLRdAFDvsbQJEG6XLFHSksETSXyeFn/cuKN4I=; b=H92qSRv0Hri+w6vXOHFieAtFUnp+WgfKa+kWc97pnSdDQo5QBV5ANWOO8qYYSxYX/F zJJryR11k96LblzKXEVpgTabdNi/YzUAkVP9tCEvijdv30It73TjRdGSjCHaF2bHR5w9 t6G3YeyGB+qybMiEp1kx5D7finz7v41/WkbRZJ3Z9D/8Ib/wzgbtJ5ZNbGmhpY9eokmJ Xjqcg33UpB9PFT+9eZ/BiMvi6x7XLgbZ4GDPLtrznHN+wKeGbzwDrGWOKOB+yIz1+4AH omqPgc868oRBoOjpmPx1jSpl9POpEs769UT9tpGJ6jq1sKclEIPdnHpRyRMr2HX8jbY0 3XAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GnMQRfzLRdAFDvsbQJEG6XLFHSksETSXyeFn/cuKN4I=; b=eQr/NcqpC4S6SnU170eTKt2aM7hzGlVKL4K/R3kvJSAGkxiD57d2Sno/qPpdpD6cZq DJBc/YnuQUujEzmoPxvApSaGfReT1kjqP28gWTu+CoRRXG3Sz+/J0GvRFzCIpc2muhhr 2L7P6mjiD2WhBKkXpIRRs+cOKjm9KkSpLY5STMzvabr6k8lU9eeMJdx/ly+PwJLW97Fh uIdSc5yrqLjqgQqoaf0B3hWb/CtZhyN1rWj+B1UXmvxm2rgHqvQyDkZJ6cX9yR2IeeWJ Wj14QFM5N52SlX1WjvpzQ05I4e4xiroHXw0SZudSSG7XG4/5iHGgiwcSLBmJbRz1sBZt EY5Q==
X-Gm-Message-State: AOAM531BQQcVTLp/QdZuZd8vrDJmF34J4Wl9S7v/lUhGnStYqc++s1wk A0NCdE1E03nYfQGq1Zg9MAPbYg==
X-Google-Smtp-Source: ABdhPJysGsDYlJGF9HeJwo5Gacl434ytbHgHgZn6jDJaYzwtsvcp/W+N/DMG4PGLnyrgJiChn5CQkQ==
X-Received: by 2002:a62:5803:0:b029:154:2c79:41ac with SMTP id m3-20020a6258030000b02901542c7941acmr5007013pfb.55.1603848365697; Tue, 27 Oct 2020 18:26:05 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id g15sm3182585pgi.89.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 18:26:05 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
To: Ned Freed <>, IETF <>
Cc: Pete Resnick <>
References: <> <> <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Tue, 27 Oct 2020 18:26:03 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Oct 2020 01:26:08 -0000

PS: i hope that this doesn't turn into a prosecution of whether my 
examples are right or wrong because that utterly misses the point. The 
issue here is that working groups are tribalistic and people who upset 
that tribalism are the enemy. until you deal with that problem, nothing 
will happen.


On 10/27/20 4:29 PM, Ned Freed wrote:
> Michael Thomas <> wrote:
>> On 10/27/20 1:27 PM, Pete Resnick wrote:
>> > 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.
> RFC publication removes the work item from the WG's to-do list. Even 
> if it
> wanted to the WG cannot change the RFC willy-nilly; the WG would have 
> to be
> rechartered in order to do the work. That's intentionally a very 
> substantial
> bar to doing that.
>> >> I started writing a blog post
>> >> about the things I found, but ended giving up because there were so
>> >> many things wrong/underspecified.
> The document is 26 pages long. I find it hard to believe it's 
> impossible to
> list all the problems you found.
>> >> 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.
> I tracked down what I think is the message you're referring to - which 
> was sent
> back back in 2016:
> I'm afaid your claim that the issues raised were all ignored is simply 
> false.
> Sean Turner responded point by point to Dave's message here:
> Now, you may not agree with that response. You may think that Dave was 
> correct
> in every point and Sean was wrong, and it may be the case that none of 
> the
> points were ever addressed to Dave's satisfaction. But this is all 
> beside the
> point: There's a big difference between not getting what you want and 
> being
> ignored.
> I note in passing that there was enough wrong with the document that 
> it went
> through another two years of work and another last call. So it's not 
> at all
> like it didn't undergo signiicant review and revision after that.
>> >> 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.
> Whereas it reads to me like a WG that didn't agree with the issues 
> raised by
> one participant, and that you were late to the party and decided not 
> to avail
> yourself of the processes used to report problems with an RFC.
>> >> 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.
> Your choice of words here speaks volumes... Of course nobody like being
> attacked; why on earth would thay? But only a fool rejects valid 
> constructive
> criticism, especially when doing so will sifnificantly improve the 
> result.
> Now FWIW, I think the right thing to do with attacks - and I've been 
> on the
> receiving end of some real doozies - is to ignore the vitriol and look 
> for the
> actual critique, assuming there is one. And if it is valid, deal with it
> appropriately, even if you don't respond directly.
>> > 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?
>> Why on earth would I want to be a drama queen? Especially since I had no
>> dog in either fight?
> So what you're saying is that only drama queens avail themselves of 
> the processes put in place to deal with exactly the isues you say you 
> had?
> Processes that a lot of people worked very hard to devise and who 
> many, myself
> included, take very seriously?
> Of course you have a right to believe whatever you want, even if that 
> belief
> limits your own options. But doing so is entirely your choice.
>                 Ned