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

Brian E Carpenter <> Mon, 26 April 2021 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABEEF3A304B for <>; Mon, 26 Apr 2021 14:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-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 XzdnyH2XGGSu for <>; Mon, 26 Apr 2021 14:15:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D2FC3A304A for <>; Mon, 26 Apr 2021 14:15:21 -0700 (PDT)
Received: by with SMTP id y22-20020a17090a8b16b0290150ae1a6d2bso6071232pjn.0 for <>; Mon, 26 Apr 2021 14:15:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HDY0k9wwyxj5Aemx5x8mhtjppPh6T1bVHjZBi68htFQ=; b=qy4V4ppuIuLMxkYe0/FQx/ScSrh0zE6/UoEQnJ1mkDbprjuc8ajyTAzWWgZKDtLGBO 8Oly9MaJWRebddIpnaVTx+AosQbNjJNJlvaw6zr0pw7sxPIh7vF8OIFd4usR8GwO19KT voN1dN02Gvn0rPPJv4Sa4Pluz86J5RUcWbchi4bw4ocjpF9DY5DoaaNeRX+ESP25WD2M JXpMhLpZ/T0mDEnLxidZ0SNNzguCuQrckcYv095vmuRcJd65PitcqJkNxHy29aSz/iZM bTJtJWfBGzDTn7FtwKQl34mLNQ97Ek4UfBFRjFj18PrlJljvS8mtXrfY6fKnU+2+NwOS QB2w==
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-language :content-transfer-encoding; bh=HDY0k9wwyxj5Aemx5x8mhtjppPh6T1bVHjZBi68htFQ=; b=jbrkXz6Xg4xLv3mxcOll5VmM23de/qd3YZ/McEyurttmczt/RndGd4nN20IWgVqEIF Frmo58n9j7bwrXdMyf49hP6GtfqXZU4MmRNOmDFU6SeSJcvy7WPWWzK2TiNi0NK24NMV 841L72WiUcqerIDwPDWUocCJ3niILSW+UodDbqUi2fP+hixPUdCl0tvzEC1xoO2w/MTb /OoizcdHKrlYlMldUmKjpDkRhTb86d39DfGi5+7aLPNvt2OzKJLc4Pvhfz0xBQGaDcRH FKtHoPzOqYvm972HTiYUsNXRQU9rzpRfVvxaov0BXeNSCV6n3MOHrkJ8tPSplAJ+ckrL xdkw==
X-Gm-Message-State: AOAM533uN7f1iedWLSo00nw3yNXVCtm8FJPb5ySKNhLZnZAZSvgXq52D kre4+UDx7viqi6aBacnCgZSR7K4qrsyaxQ==
X-Google-Smtp-Source: ABdhPJwcJ1ddyUrFtdu0FZP3bwWyx4rn8PTAmVMVmsltOnffKzq1QQmdRZnpbKbAAwXvvlkZIB/bng==
X-Received: by 2002:a17:90b:4017:: with SMTP id ie23mr1123419pjb.155.1619471718963; Mon, 26 Apr 2021 14:15:18 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id d4sm264935pjz.49.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Apr 2021 14:15:18 -0700 (PDT)
Subject: Re: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
To: Quan Thoi Minh Nguyen <>
Cc: "Salz, Rich" <>, "" <>
References: <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 27 Apr 2021 09:15:13 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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: Mon, 26 Apr 2021 21:15:26 -0000

Hi Quan,

I think you are misunderstanding something here. Yes, of course, bugs and weaknesses in draft documents need to be fixed. Actually that is a very large part of what happens in all IETF mailing lists and meetings. But authors only fix their drafts when they have time or when there is deadline pressure. There's no direction from above, only requests. And as others have said, *nothing* is a "standard" or even a "draft standard" until it is duly approved and published as an RFC with an RFC number. (Since you mentioned that you are new to our lists, I suggest starting at for a detailed introduction.)

If people make early implementations based on drafts, bugs and vulnerabilities are to be expected.

But there is more. I gather that you are referring to an issue in draft-irtf-cfrg-bls-signature-04. That is not even an IETF draft; it's an IRTF draft, apparently being discussed in an IRTF Research Group. So it is not even remotely under consideration to become an IETF standard, so raising an issue here is completely beside the point and can have no possible results.

But there is even more. The draft is more than 6 months old and has therefore formally expired. Its own text says so: "Internet-Drafts are draft documents valid for a maximum of six months."

To be frank, anyone who runs code based on an expired research draft outside a testbed is asking for trouble. But since this is not an IETF issue, we should probably end this thread now.

   Brian Carpenter

On 27-Apr-21 03:46, Quan Thoi Minh Nguyen wrote:
> On Mon, Apr 26, 2021 at 8:24 AM Salz, Rich < <>> wrote:
>       * It doesn't matter to you, but it does matter to other people like me. ____
>     __ __
>     You have been told several times, by several people, that a draft is not a standard.  No matter what vendors do, no matter what emails say about it. Even if the subject of the document says “A Standard BLS Mechanism,” until it is an RFC it is not a standard.____
>     __ __
>     People within the IETF often use the word standard in a number of ways.  That doesn’t mean the document IS a standard.____
>     __ __
>     I unmderstand this is frustrating to you, but just because some vendors implemented a draft, and you found a bug, that doesn’t mean the draft authors have to push out an update immediately.
> Not immediately. I reported the bugs privately a long time ago by a responsible disclosure mechanism, no fixing action and then I reported it publicly, no fixing action, no time commitment. I have been reporting security bugs many time (e.g. I reported most bugs (mine and on behalf of other people) in, but this is the 1st time there is a strange deadlock. I understand BLS Internet-Draft authors' perspectives and I understand libraries authors' perspectives. I tried but failed in convincing everyone to compromise in moving and fixing it :(
>     There is a reason, after all, why the document is called a **draft**____
>     __ __