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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BED6E3A0B37 for <>; Tue, 27 Oct 2020 18:14:42 -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 90X_44wKtEyt for <>; Tue, 27 Oct 2020 18:14:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E03003A0B39 for <>; Tue, 27 Oct 2020 18:14:40 -0700 (PDT)
Received: by with SMTP id r3so1685682plo.1 for <>; Tue, 27 Oct 2020 18:14:40 -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=OdY42ZvPP3HTRLjOFb4qhhSkPxEfj+kYBIf+lYQPh34=; b=utTvvA4cgjHjI1Miqf7C/EYIe9DrpSd0UOibCuaTurgdxbySysMoaTLvQ4d2z4VuNF RrE+PlqKP0QtJ7ww5pPtLyCy1QIk4R+w6EIYWzp0jCx5uo6H1YXuimzh/0aLj4dYDQs3 qVo3yybAXWgKGxtvrzycvpz42Pp6VI9CYEchspsUZyzZiHB4onemAl/o87pCa2bQE7tn RHSeCJu06ifvHJbjYoam8bYVcHGecIkiCmMR7wzZW0npuSF8p05tBjGqJLwXSdrS5j6p JOxQmuJjeaeTCIpb2Zp87lkNzROlmU6LIz2AQt8ejL5FsbC2jGsetv9bAbcXcpUZVD3o GM4g==
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=OdY42ZvPP3HTRLjOFb4qhhSkPxEfj+kYBIf+lYQPh34=; b=mfneNH0dTHLFtX5OgzYHwwhfYoGcfJIcNNkBuvLVUM+eRoPR6/nAsiD6GVB8fqbpip J+qMixqhofKTpNvXsC0ZDrl7xEhoF0t2n3n1OFr1YyFqZlYQauRAnViM6hGHL/aQAQDo PCaFTt2vYFBkiMMu3xreI88B4w2IFmqQJdA6zSvHhTRu4cot7FbWSYwTsfuklQGhTfyF e3usmoV4rhBEpgpmhsyTe/g5h9OukLW+kh1rqSd6O2FrJxl0ZE4zpmy3RvSjdpciAmCd AeqeCKJvaOQIpeI3yqJ9KQGqmMXsn1It0E1sUzkXszFWLe994N5AJNPRGJULWygV3345 tSug==
X-Gm-Message-State: AOAM533vaV+vlXYlVT1lBflo2AKXkOTLJB3nAgHAnVo7BoQh57/QkRgc 5r1u1vLKDI7QiKuVaYiBXAqeBVQucjCIrQ==
X-Google-Smtp-Source: ABdhPJxxuRDn1JnTzlmGiE7S27oyWlVOwn8puwk1HgIo4NpBTyokRvgiHbId+A7VHsq0bFEAt6zFfQ==
X-Received: by 2002:a17:90a:cc17:: with SMTP id b23mr705251pju.31.1603847679892; Tue, 27 Oct 2020 18:14:39 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id t13sm3833338pfc.1.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 18:14:39 -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:14:37 -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:14:43 -0000

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.
This thread is about what happens when people find things that are 
broken in protocols. If you think that ossification is an acceptable 
outcome just say so.
>> >> 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.

Look in the email archives. I can't believe that I have to defend Dave 
as well as myself. They treated him like shit.

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

This is a strawman. 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.

> 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.
When I looked at it years later it was like "holy shit, what a mess". 
That was well before I saw Crocker's comments.

I came upon it completely in an orthogonal way thinking it was probably 
DKIM-like trying to understand what they actually did. It took me a very 
long time to understand that it wasn't and was a complete mess. It took 
me months to get answers of what in hell was going on. Have you actually 
looked at it? It's a complete mess. Crocker and I don't even get alone 
but he's completely right. This is what you are up against.

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

I wasn't paying attention to it. This entire thread is about getting 
community feedback. Either you want that or you don't. My point is that 
there is a culture that snarls at that feedback after the fact, and if 
you truly want constructive feedback you need to address that. And I 
have no clue what the processes are. Why should I? I only cursorily pay 
attention to IETF stuff these days. Is that to say that you don't give a 
shit about somebody who looked at something with fresh eyes and was like 
wtf? It's like Pete Resnick dismissing me because I didn't properly 
escalate things. are you serious? all i'm trying to do is bring 
something up and you are bureaucratically disqualify it because i didn't 
check off the right forms? you deserve what you get in that case.

>> >> 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.
The author was a fool and flamed out soon after for different reasons. I 
was not vitriolic but it was an "attack" in the security sense against a 
security protocol. It has still not been addressed and i wouldn't be 
shocked that it has been exploited in the wild a million times over. 
That's what you are actually up against with this problem. Engineering 
prima donnas who feel attacked personally and use their stature to 
discount people with clue.

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

What processes? 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. Otherwise you're just preaching to the echo chamber.


>                 Ned