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

Michael Thomas <> Wed, 28 October 2020 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF3AF3A0C00 for <>; Wed, 28 Oct 2020 12:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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] 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 5CqpTuWvAcHt for <>; Wed, 28 Oct 2020 12:42:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1D013A0BFD for <>; Wed, 28 Oct 2020 12:42:14 -0700 (PDT)
Received: by with SMTP id x13so283066pfa.9 for <>; Wed, 28 Oct 2020 12:42:14 -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=A1RAJK1nuGPjBE/IpY01B1tSXGCVcy9EQSTANqogqco=; b=wYK442hH7OCVPZ9Kdj7R+LCsx++Oa5CjR2XSucJeFiLQAGYdj4OWehsbN3gk32u97q AUTaFeAFQkj0H0YWWB/+SiKqs3wo64gE1EVSVMmRMb3jfnLt0xLkV36lpTdaz7+TdlTO wivSKrMX6Dh23RLSR8CoIlkDku6xNca+j9b+OrrqWG9Oyt3J97f4dGnMWhbhm33tICUO tB1b6zTRwCXuXpaZglb6WtIlnrmFpnIs3TghMfwpqQh2MJVA11OQTrSiiZ4B/ZXw4+5p B+njuIGs6VD4vJLrVFgMYhSwbOb0bNJQXu33Df8C0PwJmxxRQmnRgJO/8nrj6OfFxWIW eaGg==
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=A1RAJK1nuGPjBE/IpY01B1tSXGCVcy9EQSTANqogqco=; b=qN7MpkLhAXvIkcf90zBjn8PTbnbTQOZrWehFU9mMCh7H2xuFIa547a40ArgOx/Hmkx mPLLo/bToz88uM9L2WrrnUO5pdliyihJCWILF8zRl1WuoVO2qmwKZEl5BXy0FgBjyFdo 9SvzM5Wc9LUcQ5m7HTM+6SSH7u3bkO53wjQxBwA/zY4yoVEYvxgXofKSrXM/D11H3NI3 puIJ1wRiXLk+abd2ipJBsbXktfCfg83EMc3ghec8YPBl+uHcS/Eac7Jowk40fGy+dKVs wQVgVMG31B4dQhBAg71Yv4rEOBrARtkcoOv89KDeVp5ElpxM8Qa7FdTHMG7IXlhHV3Na UIeg==
X-Gm-Message-State: AOAM532xZlxKLhaWbDJau1AIlxY8fvYmde3lFUmM9dLmOd8vVsZHJLjl YBCgywukg2Ixy2HjZKVRsn8dc0eCBU/iig==
X-Google-Smtp-Source: ABdhPJwnpW5LvcDsocctmffoQ9axZpOeGVMwsCM+4522Ot5NVIcsKcA8RI3DI4k0zIvsYAebY3BI2w==
X-Received: by 2002:a63:c042:: with SMTP id z2mr910643pgi.32.1603914133604; Wed, 28 Oct 2020 12:42:13 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id p22sm185921pju.48.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 12:42:13 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
To: Benjamin Kaduk <>
Cc: The IETF List <>
References: <> <> <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Wed, 28 Oct 2020 12:42:11 -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: Wed, 28 Oct 2020 19:42:16 -0000

On 10/28/20 11:42 AM, Benjamin Kaduk wrote:
>> If errata is that mechanism for something controversial, it's news to
>> me. Mostly what i've seen with errata are minor fixes which the wg chair
>> and/or authors can sign off easily.
> I don't think that errata are the definitive mechanism for potentially
> controversial things or things that require intrusive changes to resolve,
> but they can be an appropriate tool.  A drive-by errata report without
> additional discussion is probably not going to be the most effective way to
> make progress on such issues, but it can definitely be useful to have the
> issue documented in an errata report, even as a revision to the RFC is
> underway to fix the issue.

Yeah, there is a massive energy bandgap between errata and revving an 
RFC. Obviously you want clue to look over the problem and find the fix, 
but the current process isn't set up to quickly rev an RFC, especially 
if it is critical from what I've seen. Maybe distinction needs to be 
drawn on errata that are not very controversial if at all, and ones that 
require protocol changes to make fixes where there are different process 
rules for each?