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@xxxxxxxxx> wrote:
---------- Forwarded message ---------
From: Quan Thoi Minh Nguyen <msuntmquan@xxxxxxxxx>
Date: Fri, Apr 23, 2021 at 9:13 AM
Subject: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
To: <cfrg@xxxxxxxx>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
