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

Michael Thomas <> Tue, 27 October 2020 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EED6D3A127E for <>; Tue, 27 Oct 2020 10:48:45 -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 pFiPB_k3XxJY for <>; Tue, 27 Oct 2020 10:48:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C9D03A127C for <>; Tue, 27 Oct 2020 10:48:44 -0700 (PDT)
Received: by with SMTP id f21so1157368plr.5 for <>; Tue, 27 Oct 2020 10:48:44 -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=tDGNaGXShzSxqAzqf5ay6RXauRwljlNbO2mzceWOpZQ=; b=Jh2HdcAjC+Ru0YvuQOW5hzArPSsFs83edp0CMnwirX+bRkQuO152qvmOhdCFPEl8iB 17txjEeUuezbLSdR2430xI+t1VPGbxS+4Zo4mV5XaJ+YZ0sw1nN93G8ahZAmUxiVQht2 9rj3rDqNZG2QOv5qNLXYplemUL5kySXFNChKRqCKG7w+Oc6A5kjGMbMCWuJhT61BaQd+ gasa7ZPb6T1zRzarSYDwlbPnbD85qMQX1ivDurf42bgOmXQY0Vi8TLMNFykZjAmTzzMo UCEe8+nIUGSR1MxUxyBuoh0h+R0iMc1Z+7slrDA+L6p0HcFX9ptZ7MGkXERKcA4bMjkS uxew==
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=tDGNaGXShzSxqAzqf5ay6RXauRwljlNbO2mzceWOpZQ=; b=WJCe1eRCY8qlaSiVfkRvkMXwtDSzRU/9UswJMp505uEeYEbmTEFnpT5dY0Sr86XLgT 2+9nMmsaFHxWzhHhx0P7vFrCB8ISLFOUBZvhT2mHSozI2RaLiL8q3rJxRkcudDN5tyGp AGz8HAOiQsXUCTB/S8GNA3rS7CnE2g+baa3pWpb3Detn5sjXnTBNT7pCUbTt1+K+F5wE uhaIwrV3jtju5GAyABrmeojFp2uo2uxnNke3AwmQdqb/hrr4dIBtBJ/oblDGbjl5jMFw RZiAPs9uNSdBK1F7IMX1w6aPCgW+OsZJs4RAUfrV4YzTqtHfU0xtj/fjeZunJhBlHLkg jHtg==
X-Gm-Message-State: AOAM533wFtmdbM5mVnkqR+xh6tQxC4KumIRtEuGMVNmYBAwwnGlHWWKG dMFv589tHLdXT4fC9PE7dt16w08UgwG+iA==
X-Google-Smtp-Source: ABdhPJyXm074XCIjOn88+8fAz9iooNnbfrsNqUcwrNhtmDBzsOLxKSYo2ZWHaf78apbJZfL+b2aY3w==
X-Received: by 2002:a17:90a:6309:: with SMTP id e9mr2873421pjj.115.1603820923435; Tue, 27 Oct 2020 10:48:43 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id k127sm2690095pgk.10.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 10:48:42 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
To: Ned Freed <>
References: <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Tue, 27 Oct 2020 10:48:41 -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: 7bit
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: Tue, 27 Oct 2020 17:48:46 -0000

On 10/27/20 9:48 AM, Ned Freed wrote:
> Michael Thomas <> wrote:
>> So coming in here a bit late, but isn't the basic problem is that
>> working groups don't want to hear criticism or take it seriously? So if
>> you figure out problems with the protocol it's pushing on string at best
>> and snarl inducing at worst.
> I've been on both the sending and receiving end of many security 
> concerns, both
> here and elsewhere. This includes, but is not limited to, my work as a 
> media
> types reviewer for 20+ years, where I've written dozens of responses, 
> including
> responses to working groups, pointing out inadequate security 
> considerations.
> In all of that, I can count the number of times where my concerns were 
> ignored
> or not taken seriously on the fingers of one hand. And while I'm 
> obviously not
> the best judge when I'm on the receiving end, I can't think of a time 
> when I've
> observed the sort of behavior you describe in a working group.

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. I started writing a blog post about the things I 
found, but ended giving up because there were so many things 
wrong/underspecified. 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. 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. 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.

> What does happen sometimes is someone raises what is effectively a 
> nonissue:
> It's either already been dealt with, so trivial it's not worth the 
> bits to
> describe, out of scope, or simply nonsense. And when they are told as 
> much,
> sometimes they get upset.

In the OAUTH case it was -- and is -- a critical problem in the 
applicability of when you can safely use OAUTH. Browser, groovy. Native 
apps, bad. How many native apps use OAUTH these days? Lots? It got one 
sentence buried in the security considerations for my effort. It 
manifestly didn't change (m)any outcomes.