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

Michael Thomas <> Wed, 28 October 2020 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DD873A011B for <>; Wed, 28 Oct 2020 09:23:37 -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, HTML_MESSAGE=0.001, 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 C3yhAm2xglSw for <>; Wed, 28 Oct 2020 09:23:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C1593A0112 for <>; Wed, 28 Oct 2020 09:23:35 -0700 (PDT)
Received: by with SMTP id t24so64688pji.1 for <>; Wed, 28 Oct 2020 09:23:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=d+ETJkYeDMU/wh3ZZYpWds1bQf6uJ48X9W4qKvrzE1k=; b=EBXpgmsp0C3WioKikg4mj1AM5KdzVSE6fBf8f73TxambImU1OQhx+lkCOvqIiChmBm TVsL6t+Q34lryj9j9re/0dDPiQ2bwDqX3PfOCf05rBko+kckqmelS/FZEUOKw/x7D16D vHiauYUkCdJdzx5rkpJtQk6UdB/XLQbzxcGDrVJeHrmGV/R0PyxZw8aZTJHPj2ahGDYJ hHIuIqRSoRretqARXF4P75ppAfA7Mfy+56YMVs78063XBy9wY/UZEkAQXzx4LRCV+HIv eiFmKtCWE7NPFFd6z6EbAble8Oql90nRQgdsvPoya+hQH3quauULyJwk0/PNFnOIc3ir J3aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=d+ETJkYeDMU/wh3ZZYpWds1bQf6uJ48X9W4qKvrzE1k=; b=TlF817UXFHeJWS6W094sdPAjNRxo/07u4j1dPNSTkwY4vOGAE4VGviS64eAfkbFYvP sTqKmzbe6r0k7MU1rbBkkKDMLng5I4MrM6iBLkdgZUYRr3+FE7JUe9m1rdehlBT27DGT TzqBJxIzWFrQ1nFiUwNhrqBMDbYV8aYrftFFB1krsNIyU5IJiiiw8yh6u6+fkCnaFU8A At9VtOCvEERN3+9ArO3rHVU7oIChfA0KdNkdA1PWsMGghK2ztDfhwt5/ynBZ6+0qKP53 XxgQIUVG3W7puK89T+dG9u+dTZgpiP2KsV5QReFkcBZcXeEs3Yk2xFn4wKtp4UuHb7R2 nGeA==
X-Gm-Message-State: AOAM533FiYATUsmaoO6KnvdkognLb56pKqAKBzllIfhP8dRGCl5ccmHI sztyp9M5V7Mo4XA9TdhlX0es35a1tqMqPg==
X-Google-Smtp-Source: ABdhPJwQCcPGKKqhd3OEnVFm/LGv3DEmjooTDG4b33lLNJD1uu+Fc9qTWkdSpKrFzhP5N41ijpuzuQ==
X-Received: by 2002:a17:902:8c8f:b029:d5:f064:3da4 with SMTP id t15-20020a1709028c8fb02900d5f0643da4mr8431207plo.3.1603902214120; Wed, 28 Oct 2020 09:23:34 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id x23sm85572pfc.47.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 09:23:33 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
To: Roman Danyliw <>, "" <>
References: <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Wed, 28 Oct 2020 09:23:31 -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: multipart/alternative; boundary="------------548C76978086DB0590CAD4F4"
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 16:23:37 -0000

On 10/28/20 8:51 AM, Roman Danyliw wrote:
> [Roman] I do not believe the proposal or (defending Eliot’s) language 
> above makes this assumption, unless you are specifically reacting to 
> the words “we very much welcome your contribution.” This proposal will 
> not and isn’t intended to address authors and WG being willing to 
> accept feedback from security researchers.  This approach to 
> vulnerability validation and remediation certainly a crucial issue, 
> but a bit distinct from providing clearer guidance on reporting.  That 
> said, there is definitely interplay between poorly handled 
> validation/remediation process (e.g., untimely, unappreciative, not 
> curious, hostile) to future willingness to report.

Heh, yeah, "we very much welcome..." is painting a rosier picture than 
they are likely to get :)

> The thing about security flaws in particular is they can be very 
> subtle and hard to explain. It took me several readings of the DNS 
> Race flaw to get the jist of it years ago, and that was written up by 
> Vixie after the fact to explain it. The front line is going to be 
> considerably messier since the reporter is not likely an expert in 
> every aspect of the protocol and may get some things right and some 
> things wrong. The wrong things can then be used to dismiss the problem 
> wholesale, especially with the authors who have built in bias.
> [Roman] Completely agree.  IMO, that’s why relying on a lightly staff 
> triage alias might not dramatically improve the state of affairs.  The 
> deep expertise is going to be in the original WG or follow-on groups.  
> However, this routing function to get the information to the right 
> place is still a different issue than the validation process of this 
> vulnerability (agreeing it is actually an issue).
Yeah, I completely agree that it's the working group that ultimately 
must agree and often figure out the fix assuming that there isn't an 
obvious one.

> Don't a lot of working groups have security area liasons these days? 
> People who don't have a stake in the outcome, per se? Maybe that's 
> where you want to route this.
> [Roman] To my knowledge, formal security area liaisons are not common 
> practice across WG, unless explicitly requested. I would characterize 
> such formal arrangements as fairly rare.  More common are requests for 
> early Security Directorate (SECDIR) reviews and trying to entice those 
> with security experience to participate in WGs that feel they need 
> that review.  Likewise, there has been an informal push in recent 
> years to include language related to security in charters (which may 
> have helped only a little bit in identifying concerns and need for 
> help early in a work’s lifecycle).

I seem to recall seeing security area reviews as the document is winding 
toward last call, but it's been a long time since I've really 
participated more than just cursorily. Part of why I chimed in is 
because i'm part of the outside-looking-in kind of crowd this seems to 
be addressing. I probably know more than your average security 
researcher about ietf process, culture etc, but it's not my $DAYJOB by 
any means and i'm pretty clueless about process archana.

The other part of this is that in my two experiences, it wasn't THIS IS 
WRONG YOU MUST FIX!!! It was "is there a problem here? can somebody 
explain to me why it isn't?" I expect that most credible submissions are 
going to be more like the latter than the former, but even those were 
met with either hostility or indifference. Assuming it's been filtered 
to being a credible concern, it seems to me that it ought to be 
independently validated (or not), and better with somebody who doesn't 
have a stake in the rfc (authors, participants) who aren't eager to open 
pandora's box. At the point somebody with known clue can vouch that 
there's a good probability there's some there there, it become much 
harder for the working group and authors to ignore.