Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Pete Resnick <resnick@episteme.net> Wed, 28 October 2020 16:42 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 273773A047D for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 09:42:18 -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 7_3LDqE_qOEq for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 09:42:16 -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 B0FD93A05A6 for <ietf@ietf.org>; Wed, 28 Oct 2020 09:42:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id B254CC39B2CE; Wed, 28 Oct 2020 11:42:10 -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 4vDi5Vmai5oM; Wed, 28 Oct 2020 11:42:07 -0500 (CDT)
Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 031A6C39B2C0; Wed, 28 Oct 2020 11:42:06 -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: Wed, 28 Oct 2020 11:42:05 -0500
X-Mailer: MailMate (1.13.2r5726)
Message-ID: <47EC23B7-2B5A-4C79-9B1A-FC5F5CB75631@episteme.net>
In-Reply-To: <ec504816-a90c-f551-1ded-1866119ec2c5@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> <4679D0DD-7EBB-48BF-973B-6BCA9C4D5F8D@episteme.net> <18e2e799-cf48-9a4f-c324-29533800b2cf@mtcc.com> <01RRB7O4NQ0S005PTU@mauve.mrochek.com> <ec504816-a90c-f551-1ded-1866119ec2c5@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EtFsBiDqIF_k9FmOSRNHw8koOQk>
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: 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 into. > 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 problem. > ...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 part. > 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. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best
- Call for Community Feedback: Guidance on Reportin… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Dan Harkins
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Töma Gavrichenkov
- Re: Call for Community Feedback: Guidance on Repo… Michael Richardson
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Loganaden Velvindron
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Michael Richardson
- Re: Call for Community Feedback: Guidance on Repo… Phillip Hallam-Baker
- Re: Call for Community Feedback: Guidance on Repo… ned+ietf
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Pete Resnick
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… ned+ietf
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Salz, Rich
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Pete Resnick
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- Re: Call for Community Feedback: Guidance on Repo… Pete Resnick
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Toerless Eckert
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Joel M. Halpern
- Re: Call for Community Feedback: Guidance on Repo… Benjamin Kaduk
- Re: Call for Community Feedback: Guidance on Repo… Jay Daley
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- Re: Call for Community Feedback: Guidance on Repo… Michael Thomas
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Eliot Lear
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- RE: Call for Community Feedback: Guidance on Repo… Roman Danyliw
- Re: Call for Community Feedback: Guidance on Repo… Dan Harkins