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

Pete Resnick <> Wed, 28 October 2020 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 273773A047D for <>; Wed, 28 Oct 2020 09:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7_3LDqE_qOEq for <>; Wed, 28 Oct 2020 09:42:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0FD93A05A6 for <>; Wed, 28 Oct 2020 09:42:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B254CC39B2CE; Wed, 28 Oct 2020 11:42:10 -0500 (CDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4vDi5Vmai5oM; Wed, 28 Oct 2020 11:42:07 -0500 (CDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 031A6C39B2C0; Wed, 28 Oct 2020 11:42:06 -0500 (CDT)
From: "Pete Resnick" <>
To: "Michael Thomas" <>
Cc: "Ned Freed" <>, IETF <>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Date: Wed, 28 Oct 2020 11:42:05 -0500
X-Mailer: MailMate (1.13.2r5726)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
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 16:42:18 -0000

On 27 Oct 2020, at 16:16, Michael Thomas wrote:

> Why on earth would I want to be a drama queen? Especially since I had 
> no dog in either fight?

The fact that you think invoking them makes you a "drama queen" means 
that you are part of the problem. And the idea that if you "don't have a 
dog in the fight" means that you shouldn't fully participate (including 
using the pushback mechanisms we have), you're not understanding what 
the IETF is supposed to be about: We have plenary meetings and Last 
Calls and the like so that groups can get cross-area and outside 
feedback. Failure to call out problems simply because you're not a 
primary player is exacerbating the cultural problem you claim to see.

> Barry handled the author fine, iirc. It's just that wg as a whole 
> dismissed the problem even though what I predicted is exactly what 
> happened. They wrote my concern into the security requirements with 
> like a one sentence dismissal and everybody ignored it.

And you didn't follow up with the chair or AD when that happened?

> Isn't this thread about getting outside clue to the attention of the 
> working groups more seamlessly? Your quoted process and sympathy is 
> exactly the wrong way to foster that.

Well, let's be clear here: The original thread was about how people who 
are outside of the IETF community can communicate protocol 
vulnerabilities. Your original response was "isn't the basic problem is 
that working groups don't want to hear criticism or take it seriously?" 
and then gave examples of your recent experiences dealing with feedback 
not being taken by WGs. But you are a regular IETF participant, insofar 
as you're subscribed to the IETF list and are participating (however 
much) by directly communicating concerns to WGs. I was addressing your 
comments, not the kinds of problems that a complete outsider would run 

> In OAUTH's case I did talk to Barry. For STIR after seeing what they 
> did to Crocker at last call it was apparent that it would fall on deaf 
> ears so why bother?

Because everyone not bothering actually makes the problem worse.

> I did bring it up my concern on their mailing list before I read the 
> archives, but crickets.

At which point you should have gone to the chair. If a mailing list is 
misbehaving (which includes ignoring comments), that's a failure on the 
part of the chair and needs to be dealt with.

> The flip side of this that nobody wants to be seen as an insane 
> Casandra in case you are actually wrong.

Nobody who says, "I think there may be a serious problem here. This 
protocol does X, Y, and Z, and those appear to be serious security 
vulnerabilities. Am I off the mark here?" gets seen as an insane 
Casandra. On the other hand, if someone comes in saying, "This protocol 
is a complete mess because of X, Y, and Z. WTF?", yeah, they might be so 
labeled. On the other hand, someone like that strikes me as someone who 
doesn't care about such labels.

> If you want outside clue but the reality is that they treat you as the 
> enemy, you're not going to get the desired result. Any fix for this 
> needs to account for that.

The problem you're identifying is fixed by IETF participants pushing 
back on such behavior using the mechanisms we have in place to do so.

On 27 Oct 2020, at 20:14, Michael Thomas wrote:

> I said that most of Dave's problems were ignored and that there was a 
> lot of snarling about it being brought up in last call. Peterson in 
> particular impugned Crocker for that, as if last call was a bad time 
> for comments.

It is always the case that late comments, particularly ones that require 
substantial changes to address, will always be a bummer and, being human 
beings, sometimes cause grumpiness. But our processes are designed to 
deal with such things, and if they are being invoked appropriately or 
otherwise being ignored, that's a problem.

> When I looked at it years later it was like "holy shit, what a mess". 
> That was well before I saw Crocker's comments.

So the correct moves for an IETF participant in such a situation are to 
do one of the following: (1) Bring the concerns up on the list and see 
if the WG can address them; (2) If the problems are individual points in 
the document that are correctable, file one or more errata; (3) If there 
is a serious flaw, start the appeal process for the case where "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." Yes, that process is normally used for 
pre-publication, but I see no reason it can't be instantiated for 
post-publication. Resolutions could be the IESG chartering new work to 
correct the problem or adding a work item to a still existing WG, the 
IAB deciding to publish a document describing the problem, etc.

I will point out however that "I would have done this completely 
differently" or even "this is an architectural mess" are not valid 
reasons to make a change: Internet email is arguably an architectural 
mess compared to X.400, but deployment and successful interoperation 
tend to be overriding in IETF discussions.

> It took me months to get answers of what in hell was going on. [...] 
> This is what you are up against.

I'm still trying to figure out what you in particular are up against.

> My point is that there is a culture that snarls at that feedback after 
> the fact...

Look, as I said above, we are human beings in the IETF, and people will 
sometimes react poorly to feedback. (Again, I'm speaking generally; I 
don't know what actually happened in the cases you pointed out.) But 
when this happens completely internally to the IETF, it is incumbent 
upon participants to pull the levers we've got to correct those 
problems, because failure to do so will absolutely develop a culture of 
poor handling of feedback, both internally and externally. When a 
regular IETF participant complains about outcomes but has never used the 
procedures we have for handling problems, that person is part of the 

> ...and if you truly want constructive feedback you need to address 
> that.

Who is this "you" you speak of?

> And I have no clue what the processes are. Why should I? I only 
> cursorily pay attention to IETF.
> stuff these days.

Sorry Michael. I count 83 messages from you in the past year in the IETF 
mail archives. You don't get to claim "drive by" status. You are an IETF 
participant. At this point, you should at least know what RFC 2026 is 
and have a passing understanding of our processes. I'm certainly bummed 
by Rich's comment that the conflict resolution process is not mentioned 
in the newcomer's orientation; that seems like a gaping hole to fix and 
I'll try to be part of fixing it. But if you're going to participate as 
you have been, you should know some of this stuff, or at least be able 
to ask about it when need be.

> Is that to say that you don't give a shit about somebody who looked at 
> something with fresh eyes and was
> like wtf?

Nonsense. We get feedback like that all the time. Sometimes, that 
feedback is good and we take it on. Sometimes that feedback is nonsense 
and we try to respond respectfully and ignore it. Sometimes, due to the 
grumpiness of the sender or even of the receiver, that feedback can get 
inappropriately. It's all of our collective responsibilities to make 
sure that is corrected.

> It's like Pete Resnick dismissing me because I didn't properly 
> escalate things.

I'm not dismissing you. I'm saying you haven't made your case. You said 
there is this systemic cultural problem, yet you are part of the culture 
and haven't used the mechanisms we have in place to deal with the 
problems you have described. If you were an outsider, I wouldn't have 
pointed you to those procedures if you had a complaint; I would have 
simply helped you find the right person to talk and helped you address 
the problem. But you're not an outsider. You are an IETF participant. 
Take responsibility for changing the things that you can and do your 

> 99.9999999% of people are not encultured in IETF process. If you want 
> casual people to be able to have a say about "hey, something is wrong 
> here!" you need to accommodate their lack of clue about process.

Yeah, absolutely, but my point is that this isn't you or the incidents 
you identified. You identified internal IETF participants (yourself 
included) not being listened to. If that's the case, you should have 
known enough to use the processes. The original thread is absolutely 
about how to get the comments of external folks into the mix. But that's 
not what you've been talking about.

On 27 Oct 2020, at 20:26, Michael Thomas wrote:

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

Totally agreed.

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

Again, the "you" you mention includes you, Michael. You don't get to 
push this out as if you are not part of the community. And the way you 
individually can address this kind of problem is to actually use the 
mechanisms we have in place to do so.

Pete Resnick
All connections to the world are tenuous at best