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

Quan Thoi Minh Nguyen <> Sun, 25 April 2021 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79FD73A1143 for <>; Sun, 25 Apr 2021 11:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 D7PwyYpA2g19 for <>; Sun, 25 Apr 2021 11:24:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2DC13A1140 for <>; Sun, 25 Apr 2021 11:24:03 -0700 (PDT)
Received: by with SMTP id f2-20020a17090a4a82b02900c67bf8dc69so3875550pjh.1 for <>; Sun, 25 Apr 2021 11:24:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xHMyEFzn89KGvEhmQObE/dP0YyXAZJYy6WacsnSHSu0=; b=KY2l+qkFO8qZJkwdfjvw0Pe6b74ptye9r53d8t68vK4gVp5dSlR6X+FCrx5awgLPfF dXl3Q3qFw1c2sOYW+6KL5PU0TrBbbhm51th8mUvp+QYk7ahdebvi7SuF9Sc4knvV7unA +X2t3qCrSbbsCA++L0CsUrkYIaG4q47sNK1a1AzMCeIUXEkTeMiNuEfhsdOp8w0h3d2w cZ6AiXxFXe+gtKa+iOVrqUp4NinITc13gL4jHEro4/TG7G7/FtyyR/dx01DajFbJyUa2 L313KJtV1wjTF66Q9+l1ajVRPDmstU5VefctopkVlPud+Rjj82KSCwAtgks9/lL+bruU UWHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xHMyEFzn89KGvEhmQObE/dP0YyXAZJYy6WacsnSHSu0=; b=SdXaqkZPUkK0nnAo8uuZ5aIUtamqpN9UilHf3eZeWitfn7B95GSv7iYNDJGksgZoYY f5rW0k+avuRwUBkuXAZBVkloOhtRRZlXFxp2ePEIj+N6Pe/iSs64UdD4aVv/xpXpVO69 eItvoULhyqOw+HE8At9gZQCZSP1dqoDTlyhxJ30OUyPJgzOCPik6RJEbyjgjYH4P+s3j UkrxZXT6PSoRSH0n85QJJP2W+IFI15twX+oFRrEohdVLMKWKITFhaArwBNU7XBahS5fg NPtTieZyWEI4S7vU966pLxVj9VRubKuIGBhdfe1DzNLtfUCQV1tp9GmBsojb/TkSyIPN VWUg==
X-Gm-Message-State: AOAM532SLJyZ+lVc23ha3iiP+pMdfkP9D2BHeECP227fobicE6Nn/0aZ IElhuIH1e+qyDqNlCQ7LJWcJKKMSNaXKDw7QLhCN2DfztjY=
X-Google-Smtp-Source: ABdhPJxpGHNcHGBx+FbQa+hNfD+090N06W4zRPpEwI6f+FGj7plzm9RyjPUSxn0l4iJcmp53zvjj7ZO9LeBPi3EZAmY=
X-Received: by 2002:a17:902:b687:b029:eb:6491:b3f7 with SMTP id c7-20020a170902b687b02900eb6491b3f7mr14511380pls.38.1619375042415; Sun, 25 Apr 2021 11:24:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210423195504.d6f74x4jsdrzagcc@muon> <> <> <> <>
In-Reply-To: <>
From: Quan Thoi Minh Nguyen <>
Date: Sun, 25 Apr 2021 11:23:26 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000029514405c0d022a7"
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: Sun, 25 Apr 2021 18:24:09 -0000


Thanks for your information and responses.

As a software engineer (SWE) myself, let me give you a bit more sympathetic
view from a SWE's perspective. Let's say product teams decide to use BLS
aggregate signature. Implementing it purely from academic papers is very
risky because in cryptography, details matter. They see some BLS RFC
"draft" v4 published by world well-known authors in the field, so they
rightly trust it. It's a reasonable thing to do. I think the current BLS
"draft" series helped implementers avoid several serious security issues.

Now, I reported reproducible security bugs. I proposed a fix that can't
decrease security because it only adds *extra* checks but my fix may be
*useless* as it might not fix the core issues. Furthermore, product teams
also worry about *consensus*. If they follow my fix and BLS RFC's authors
disagree, different implementations will have different
interpretations/views of the same data causing consensus bugs. Things will
get messier quickly.

To make it crystal clear, my email is not about security bugs in BLS RFC
draft v4. Security bugs are a natural part of software development cycles
and everyone (including me, of course) can make mistakes. When security
bugs are found, we have to fix them. My email is about the *fixing* part
because it's a deadlock now.

- Quan

On Sat, Apr 24, 2021 at 10:53 AM Paul Hoffman <> wrote:

> On a tangential note, but one that is relevant to your complaint:
> - Internet Drafts are absolutely not RFCs. RFCs always have been more
> reviewed than Internet Drafts. That is, even the "final" draft that is
> given to the RFC Editor has additional reviews that sometime surface
> technical bugs that must be fixed before the RFC is published. As others
> have pointed out, implementing from an Internet Draft comes with
> significant risks.
> - The CFRG does not create standards. All RFCs from the CFRG have a
> status of "informational", not "standard". They might be treated as
> standards by implementers, but they are not in fact standards. In the
> IETF, standards have more reviews than CFRG RFCs.
> (I note that
> incorrectly uses the word "standard" at the top of the repo. Maybe the
> CFRG chairs could review all of the repos in to
> make sure that their wording is accurate.)
> --Paul Hoffman