BitCoin delenda est Was: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 26 April 2021 19:10 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEEB3A2359 for <ietf@ietfa.amsl.com>; Mon, 26 Apr 2021 12:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUHlec7OvZ9u for <ietf@ietfa.amsl.com>; Mon, 26 Apr 2021 12:10:13 -0700 (PDT)
Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A9D3A2362 for <ietf@ietf.org>; Mon, 26 Apr 2021 12:10:12 -0700 (PDT)
Received: by mail-yb1-f169.google.com with SMTP id e8so6340519ybq.11 for <ietf@ietf.org>; Mon, 26 Apr 2021 12:10:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=awXG9rh9RuuBt/UcLvIh/uZIBCCo7fWkteEAizN3MkA=; b=aio0MSmvoKLiEOTFMT9it2fN2SHS4yKxT+uL7Ha6Y9G9itw2vMEaY4W1CgvjHxXYOq XlabXLZ/mivislJ5rPfowAwnGaPWicNNL2QnEzcfStAy4YJkk0g0AZXmN3hetv2TuizU aMkh3D91buOM4UNGJ1RofpNR6y8GAt0As81IUIu129+Y8Pi7g674Oyy0fMcLjNsOtGx8 NmWcwovqXXC+QoD0LNk1AHnDk4kGh0SStknJzIbi4URG0yL6Ukf7CaEO/R8ZPdgZlHCM K4Gf8TfxYLtVunm8rbyWgiPFUjeDZaYK0V1DQDrqgOBwzF1a6QGUQIgaqjrreTFBoo9/ ZJtQ==
X-Gm-Message-State: AOAM532ORq9ExFALm5SRYrFxaBqhqHnB+nX8wb5T8k6AZts7CNx0dnvk 0vi7ipIEFNDega3riOC16LDKDetaPlABOnPGM3A=
X-Google-Smtp-Source: ABdhPJwNRoVy7rHCwVTtUpVdrA7VmB3GELr4jBKgaFZFSohvE1fDEjizLhIf8sBBPrj5te3U2W8ieVTPv/svPpXG7Io=
X-Received: by 2002:a25:b7d4:: with SMTP id u20mr26529557ybj.522.1619464212002; Mon, 26 Apr 2021 12:10:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAAEB6g=tU=MF1_QKduEN55ft0rWe+7x0wBbywS083fJrjzP=XA@mail.gmail.com> <CAAEB6gn+QWuCX4BxCJuofz6JF6amaPtWiDtg7ZAmRT9FwaX8vA@mail.gmail.com>
In-Reply-To: <CAAEB6gn+QWuCX4BxCJuofz6JF6amaPtWiDtg7ZAmRT9FwaX8vA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 26 Apr 2021 15:10:01 -0400
Message-ID: <CAMm+Lwg_BJv5JE5To28d+nKdugV4QZg5VC8bLhBiFJQSwOQ4sA@mail.gmail.com>
Subject: BitCoin delenda est Was: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
To: Quan Thoi Minh Nguyen <msuntmquan@gmail.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000153a5705c0e4e505"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZyqgttmZUbcAvgjkZyUrOAI6b1U>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2021 19:10:17 -0000

OK, if we are escalating to IETF wide discussion...


As a human being living on a planet threatened by environmental damage from
CO2 emissions, I am strongly opposed to any IETF work to support any form
of purported 'cryptocurrency' that relies on any form of 'proof of work' or
'proof of waste'.

The electricity requirements of cryptocurrencies have been larger than that
of entire countries. This is an experiment that it is time to stop.

I am entirely serious in this position.


Besides the environmental issues, there is the fact that the
crypto-currency community has consistently failed to establish any
effective means of preventing the endemic frauds in their systems.
Fraudulent exchanges regularly steal money from their customers.
Applications developed by individuals with minimal expertise are used for
transfers of vast quantities of fictional cash with no effective oversight
and this results in further frauds.

The cryptocurrency community has a long history of misrepresenting the
engagement of parties with established reputations as endorsing their
'product'. And this presents real risk to the IETF when the least
objectionable use of the product in question is to evade currency controls.
Cryptocurrency became popular as a means of paying for illegal drugs and
has since become the enabler for ransomware.

The cryptocurrency world has no shortage of people who will trash anyone
criticizing their activities as 'stupid', 'uninformed', 'need to do some
research'. Fine, let them sort their own messes out.

IETF should take no action that risks a headline 'IETF endorses
cryptocurrency'. If the ransomware, child abuse and Ponzi scheme industries
have a problem as a result of a bad technology decision, we should not lift
a finger to save them.


The only conversations I want to have on cryptocurrencies is with
government regulators looking for ways to regulate these criminal
facilitation enterprises out of existence as they previously did with
eGold, Gold Age and BTC's very long line of predecessors which like BTC
were entirely different but completely the same.


On Mon, Apr 26, 2021 at 9:19 AM Quan Thoi Minh Nguyen <msuntmquan@gmail.com>
wrote:

>
>
> ---------- Forwarded message ---------
> From: Quan Thoi Minh Nguyen <msuntmquan@gmail.com>
> Date: Fri, Apr 23, 2021 at 9:13 AM
> Subject: Escalation: time commitment to fix *production* security bugs for
> BLS RFC v4?
> To: <cfrg@irtf.org>
>
>
> Hi,
>
> I'd like to escalate this issue to the CFRG chairs as a last resort. By
> responsibility disclosure mechanism, I reported the bugs *privately far
> before* I posted it publicly at
> https://github.com/cfrg/draft-irtf-cfrg-bls-signature/issues/38. I did
> everything in my capability: reported the bugs, wrote proof-of-concept
> attack, wrote proof-of-concept fix.
>
> I'm curious what is the time commitment of the RFC's authors in resolving
> the following deadlock:
> + Libraries code (ethereum/py ecc, supranational/blst,
> herumi/bls,sigp/milagro bls) are deployed in *production*. They're not
> academic nor experimental code.
> + Libraries' authors can't fix the code because they have to follow the
> standard.
> + BLS RFC v4's authors don't move an inch in fixing it nor have any time
> commitment.
>
> The standard authors are in an extremely powerful position where they
> dictate what every library should do. Does it go with responsibility for
> responding in a timely manner for security bugs deployed in *production*?
> Even if they don't want to fix the message binding bug, should they at
> least fix a very obvious bug? AggregateVerify((PK_1, PK_2), (msg, msg), 0)
> = True, FastAggregateVerify((PK_1, PK_2), msg, 0) = False.
>
> Note that I'm not saying my proposed fix is correct and RFC's authors
> should follow it. What I'm asking is the BLS RFC authors' time commitments
> in resolving the security issues deployed in production?
>
> Thanks,
> - Quan
>
>