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

Michael Thomas <> Wed, 28 October 2020 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F43A3A067A for <>; Wed, 28 Oct 2020 10:43:03 -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 TQPD8CER1IvW for <>; Wed, 28 Oct 2020 10:43:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DD143A0657 for <>; Wed, 28 Oct 2020 10:43:02 -0700 (PDT)
Received: by with SMTP id m17so187686pjz.3 for <>; Wed, 28 Oct 2020 10:43:02 -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=XyhlLlnJVP2DcgdKXO11JKBqXviqzDnTaFvcBTsctaE=; b=g2l2RHfsBiiwbqOwp5+hRqGtKObciw+domXmjmz0WXu6/YS9dqtpR9owrHuimBSsEj FCxRsoamPEiATd+qIMl04KaYBHYZrZVNhj5w4UtgxSIqKZOsXdq/ejL/4WghwLtu9wVi 4phhfLPCm7z/2WuX+mKHPhVIIIT1oguubLJ8OBUlIUvE9SjMIYSuAtmfKqIH1l00YReX 0QNeS4oqlgNvUTSk65m7HB3O+lXtp1hCod/HBxkShzJ4x05jct96qDByWN3CI15fd2ov uqVs7pAst88LLMQCf5jBV6Wa80qbAurYG9ZgUb8EsOO+Rq+uFeYM/u2cuQgmhSzsPh66 eagQ==
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=XyhlLlnJVP2DcgdKXO11JKBqXviqzDnTaFvcBTsctaE=; b=b5Z6malx61nPTUS58P6tpKCm3G0CZOfIOnTKwRzl+ehcOYv5Fp8lutW1eC62iavZUC HIumQUC0vRRnxNKHDO7EePqRKYskWRIlx3HMcWnAsCWsDOCu2KsgUEbimxxoaRAfRM9s 66Uzrmuroelss/WMpoyUYk9nINleF3zQUKYUydK7SVO3JqqOyLKhr//Qv5N01jIlXwJ2 tOpzdI7weMrhBGKBc5Zt3kVE56tjmcR62NmCO5C+yB0+N8+MbpW3Hz6v/HrfyrQ13ySx u4cgJioe4Y6fV4/lP4tWVKHsUjo6hfr0TcHLUi9F/3hnSpFGswzFUMv9W5JSUbs8R0kA Ih8w==
X-Gm-Message-State: AOAM530q1OP2PCuhSlChFOWnXYoDAb9Mc0mzODzD5gjajVGs21yYNSo9 e6Vif2MbMtIE5OsYnHqvAvCoEi/7lHfNvQ==
X-Google-Smtp-Source: ABdhPJzNz8Emewf5twXS2yvOrkrWeT0y7ev7RbqoqOrpSZdvFaj5fVx3HAUsSzMD0TTRfcqf99Y7QA==
X-Received: by 2002:a17:902:b78c:b029:d4:da94:8766 with SMTP id e12-20020a170902b78cb02900d4da948766mr387137pls.31.1603906981213; Wed, 28 Oct 2020 10:43:01 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id y5sm5383pgo.5.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 10:43:00 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
To: Pete Resnick <>, Eliot Lear <>
Cc: Ned Freed <>, The IETF List <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Wed, 28 Oct 2020 10:42:58 -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 17:43:03 -0000

On 10/28/20 10:27 AM, Pete Resnick wrote:
> On 28 Oct 2020, at 12:00, Eliot Lear wrote:
>> This is where I think there may be some subtle issue, and I don’t 
>> want to make this all about Mike.  Many researchers have no equities 
>> in our organization.  They may not even have a fix available for the 
>> very problem that they have found.  We have red teams for a reason: 
>> it’s just a different muscle.  So they see their job as finished when 
>> they’ve reported.  And then they’re on to the next thing.  That’s 
>> their incentive model.  Mike just happens to care more than most, but 
>> we shouldn’t optimize around him.
> Lest there be any question: I completely agree with you on the above 
> Eliot. The proposal on the table from the IESG that Roman posted is a 
> great start into how to deal with exactly those researchers you are 
> talking about, and I fully support the idea. I don't want those folks 
> to have to wade through the rest of IETF process if they have no 
> intention to be part of the whole kit and caboodle of WG protocol 
> development. The one and only thing I was responding to was Mike's 
> analysis of the core problem based on his personal experiences. He is 
> not like one of those researchers in that he does participate in the 
> IETF as a regular participant, and we should absolutely not be 
> optimizing around the cases he's concerned with.
As I mentioned earlier, security issues can be very subtle and not easy 
to explain or understand. Lobbing a write-only report over the wall is 
hardly ideal. They have every right to do that, of course, but if they 
can be coaxed to participate while it gets digested, that would be a lot 
better. And then of course, there are the cases where somebody thinks 
something might be wrong, but isn't sure of it. That more resembles me. 
Maybe I'm a unicorn though. I'll check for glitter in a bit.