Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Michael Thomas <mike@mtcc.com> Wed, 28 October 2020 17:35 UTC
Return-Path: <mike@fresheez.com>
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 800A83A064A for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 10:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com
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 OIv45_tcYKxk for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 10:35:47 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742583A0408 for <ietf@ietf.org>; Wed, 28 Oct 2020 10:35:47 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id a17so183719pju.1 for <ietf@ietf.org>; Wed, 28 Oct 2020 10:35:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=wo+2CK04FnJUoe29M5OaIVVRjczUJOnOWvKYejqbm1Y=; b=f51tv5hCLWfIK+kybYcwPdf2et1+miwIn3EijgOqG9J9jrmVyGMQqagsrw+r/sl1sE e8mnVbD5qxyr8IMcVkmoSFjL4VSuypQhZwquLtbjB2t+yhQ6C6Q82ck7MvMaJQg72EvP DLZQspIeRo0plcGVXJp1kycmuap69dKE0mhD6ahPipKcWGpQU7K2oDjD6xFZQFj8Q3jp vY52nnN0oIz8SfZt3dkD1bfIu20tV3VxmAjVesgYvjAHeO57XZRzW9DoTAIgI2+l7S4G rIHwZd4nduuWvFiEAdITJ7AQTW5XhFa6lJyyrfdkLMGEYDZgJ5aNHJeA+2ghJMJuRWI7 f1Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=wo+2CK04FnJUoe29M5OaIVVRjczUJOnOWvKYejqbm1Y=; b=Ukwy+OnA9tRChxIz7ix3ZHcEYURd344ziUqDSFFlWx7lRIN/NB7RYR6qn8lyBIvUR9 XgOeuduSm9DbcBT66dEbRI7WM2vJYPiiS/U3xAgufsEnjhmkfgqpz413YMa76duzjN8e 3Yvn+woPS3ui/3qxOHPQGnbTmrcW3fSrBloRaILN0YCsiJmU7ucU3pJ1lkWFY0hvByrT lXzFKJ5FCdCHBxSkMkwcKmSZzeTzEanjQn+ofyuLiX/Wt26lFi7OQiwQItaOkKRDZCrF 0Z9J9plTOClYInjR2RiGISSFTCPif7g4qTbyJzYs3Izg0W3aVLb8pgP3oxlPUGcmH4bN 81DQ==
X-Gm-Message-State: AOAM530ymp7kk71xgM4pheJVx7ZX7EwnJhNQufCr3GWZxENbMdgt/aKn Es3MmWA6k7cOvQHN6A+SC6gOZM3ALCw/TA==
X-Google-Smtp-Source: ABdhPJzxBjw5hWDE19rG/GPbxMvwvJWmdS4go90+0ymWm5Th/aWmHvTIgfcuqjjIQxxcMKkcnTIktA==
X-Received: by 2002:a17:902:8eca:b029:d2:4276:1b2d with SMTP id x10-20020a1709028ecab02900d242761b2dmr353799plo.17.1603906546035; Wed, 28 Oct 2020 10:35:46 -0700 (PDT)
Received: from mike-mac.lan (107-182-45-196.volcanocom.com. [107.182.45.196]) by smtp.gmail.com with ESMTPSA id u13sm199274pfl.162.2020.10.28.10.35.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 10:35:45 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
To: Pete Resnick <resnick@episteme.net>
Cc: Ned Freed <ned.freed@mrochek.com>, IETF <ietf@ietf.org>
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> <47EC23B7-2B5A-4C79-9B1A-FC5F5CB75631@episteme.net>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <39970930-aa95-a28c-9221-6496c30d443c@mtcc.com>
Date: Wed, 28 Oct 2020 10:35:43 -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: <47EC23B7-2B5A-4C79-9B1A-FC5F5CB75631@episteme.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/o20TkWtU3Y9j_qg8bS0Hj6M6oYE>
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 17:35:50 -0000
On 10/28/20 9:42 AM, Pete Resnick wrote: > 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. You realize that this is a thread about outsiders contributing vulnerability clue without necessarily having any IETF knowledge here, right? Your hectoring is particularly ironic. I don't go to meetings anymore. I only occasionally look at things rfc/groups/etc that interest me. I was never a creature of process archana even when I did. So I'm not a terrible proxy for somebody who is completely naive. > >> 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? I just said that Barry Lieba -- wg chair -- handled the hysterical author well. Well, as well as could be expected. > >> 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. I'm mostly an outsider these days. So I'm bringing the perspective of somebody who knows some of the process that I wouldn't need the kind of guidance being hatched here, but have been on the receiving end of where it goes once routed. I imagine that people who also got the same treatment are not going to bitch about it on the ietf list because... they don't even know about it, and don't care enough about the meta problem. > > 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. I could have done that, but after reading the archives made the calculation that it was a waste of time. Frankly the security flaw I found is probably the least of its worries. It is so underspecified that apparently I can use gopher: or ftp: method in the URI that fetches certs. That is the level of carelessness and underspecification we're talking about. So I did what any sane person would at that point: "You're on your own, son". > >> 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. Uh, living proof right here. I'm willing to believe that it's uncommon though because that particular author was particularly egregious. But the entire thing turned into a "it's not a problem because it's not fixable" wtf twilight zone. > >> 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. What exactly is the alternative? I mean that is what last call is for, right? If I don't have a lot of involvement with something but am interested in the outcome, that is the time that I'm going to read it over and see if there are problems. In that particular case, there were so many that the comments it was pretty much a novel. That doesn't bode well especially given who gave the feedback. I scanned it over afterward and eyeballing it maybe 10% of the comments were incorporated. A lot of them were stylistic, but a lot of the substantive ones didn't lead to any changes in the document. > >> 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. On the list I was only interested in a couple of things: a potential security flaw that I found, and whether STIR covered the sip:mike@mtcc.com case. The first got ignored, the second got discussed quite a bit but it's still not entirely clear whether it does or doesn't which is its own kind of flaw. As I said, I just casually participate in things that interest me and then go back into hibernation. So I'm sort of a maybe more process clueful type of person this thread is about. I'm definitely not interested working some long process to prove a point. Too much work, too little gain. > > 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. I made no architectural arguments, though I do have opinions not expressed. Just the quality of the document and potential security problems. > > 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. Look at the years before that. It's been very sporadic since I left Cisco 12 years ago. > >> 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. 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. Hence why I've responded. yes, it should be we but i don't feel entirely we these days. IETF does allow for this sort of meta state, which is maybe one of its charms. Mike > > pr
- 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