Re: [CFRG] Escalation: time commitment to fix *production* security bugs for BLS RFC v4?

Loup Vaillant-David <> Fri, 23 April 2021 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 402323A1500 for <>; Fri, 23 Apr 2021 16:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G5wKmnkgYbRk for <>; Fri, 23 Apr 2021 16:38:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 063E03A14FF for <>; Fri, 23 Apr 2021 16:38:33 -0700 (PDT)
Received: from grey-fade (unknown []) (Authenticated sender: by (Postfix) with ESMTPSA id 4C187200004; Fri, 23 Apr 2021 23:38:28 +0000 (UTC)
Message-ID: <>
From: Loup Vaillant-David <>
To: Quan Thoi Minh Nguyen <>, "Riad S. Wahby" <>
Date: Sat, 24 Apr 2021 01:38:27 +0200
In-Reply-To: <>
References: <> <20210423195504.d6f74x4jsdrzagcc@muon> <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [CFRG] Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Apr 2021 23:38:37 -0000

Hi Quan,

> It's very unfortunate that the bottleneck for fixing security bugs is
> purely voluntary and has no commitment. This sounds pretty wrong from
> a vulnerability management point of view. I don't have any proposal
> to mitigate this deadlock.

There may be one way: holding implementers accountable.

They relied on a draft. As such, they took a gamble. Now they lost that
gamble, and gambling ethics dictates that they pay up.

Specifically, they can hire a professional cryptographer to devise or
vet a fix. Or better yet, proposing a fix that is very likely to be
adopted in the RFC itself.

We could counter with the idea that it would be too expensive for the
maintainers of those implementations. You mentioned Ethereum, though. I
would expect it'd be easy for them to raise enough funds for a couple
day's worth of expertise (which I expect would cost a couple thousand

If implementers argue that they are *not* responsible for bugs
resulting of the adoption of an RFC *draft*, we can consider making
some noise on the relevant social networks and news aggregators. I do
not relish the idea of feeding them to the lynch mob, but I'm afraid
this is the closest we can have from a trial.