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

Eliot Lear <> Tue, 27 October 2020 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABB983A128C for <>; Tue, 27 Oct 2020 11:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id meYvWv2aoecN for <>; Tue, 27 Oct 2020 11:00:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 684253A149E for <>; Tue, 27 Oct 2020 11:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14006; q=dns/txt; s=iport; t=1603821632; x=1605031232; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=cv5+ZbrJLQEWXsoJYUFgeXHADdX2C8DCxf7GowN4MKE=; b=UmRF/gs+21eBd0iHMxCPVm8kduO+U6+A/69WYjh+PIYHJj/uDN2PDet6 DA/USQHauUAKhqXlfUNT2o5NXqtYf1C0lnpuwKEL9Rg3w4IZIN2Dx7Rhk DBj/As77eCgdD7VELKqicYsKc3JlcIriNXM16JZfefApclUX+Yixm5M4s g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAgC7X5hf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BI1KBegEgEi2NQogOlAuIGgsBAQENAQEvBAEBhEoCggY?= =?us-ascii?q?mOBMCAwEBCwEBBQEBAQIBBgRthW2FcgEBAQMBHVwFCwsOCi5XBhMUgxKCXSC?= =?us-ascii?q?nLXSBNIVXhHqBOI1UggCBOByCTT6EFINzgiwEpm2RGYJ1gxeXZQMfgxeKDYU?= =?us-ascii?q?gjxqVPJpdg18CBAYFAhWBayOBVzMaCBsVOyoBgj4+EhkNnGlAAzA4AgYKAQE?= =?us-ascii?q?DCYwCBoJAAQE?=
X-IronPort-AV: E=Sophos; i="5.77,424,1596499200"; d="scan'208,217"; a="30614250"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Oct 2020 18:00:28 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 09RI0Q7I021590 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Oct 2020 18:00:27 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4DF2CCF5-1F2A-4DA6-9A1B-4776B82AF38A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Date: Tue, 27 Oct 2020 19:00:26 +0100
In-Reply-To: <>
Cc: Ned Freed <>, The IETF List <>
To: Michael Thomas <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-Outbound-SMTP-Client:, []
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 18:00:43 -0000

I think what you are pointing out is that maybe it would help if these things were properly tracked against anything that would update or obsolete existing work.  We might even be able to automate the response along the lines of:

A working group is currently working on an update.  Please feel free to join in the fun at...
A working group is currently working on a replacement (e.g., obsolete). Please feel free to join in the fun at ...
No current update is in progress.  In addition to filing an erratum, we invite you to provide an update through our errata process, and perhaps through our standards process.  You can contact <insert AD here> for more information.

Or some such.


> On 27 Oct 2020, at 18:48, Michael Thomas <> wrote:
> 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.
> Mike