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

From: Quan Thoi Minh Nguyen <[email-masked]>
Date: Fri, 23 Apr 2021 09:16:20 -0700

---------- Forwarded message ---------
From: Quan Thoi Minh Nguyen <[email-masked]>
Date: Fri, Apr 23, 2021 at 9:13 AM
Subject: Escalation: time commitment to fix *production* security bugs for
BLS RFC v4?
To: <[email-masked]>

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Apr 2021 14:28:51 +0000

You have been told several times, by CFRG participants and others, that if someone implements a draft.  For example, see https://www.ietf.org/standards/ids/ .  In particular: “Internet-drafts have no formal status, and are subject to change or removal at any time.”

You cannot pressure authors to update a draft because some people have deployed it in production and there is a bug.

In particular, your note refers to the draft several times as a “standard” and you call them “RFC authors.”  Both of those are incorrect.  It is a draft, not an RFC, and not a standard.

---

From: Quan Thoi Minh Nguyen <[email-masked]>
Date: Mon, 26 Apr 2021 07:59:57 -0700

On Mon, Apr 26, 2021 at 7:28 AM Salz, Rich <[email-masked]> wrote:

> You have been told several times, by CFRG participants and others, that if
> someone implements a draft.  For example, see
> https://www.ietf.org/standards/ids/ .  In particular: “Internet-drafts
> have no formal status, and are subject to change or removal at any time.”
>
>
>
> You cannot pressure authors to update a draft because some people have
> deployed it in production and there is a bug.
>
>
>
> In particular, your note refers to the draft several times as a “standard”
> and you call them “RFC authors.”  Both of those are incorrect.  It is a
> draft, not an RFC, and not a standard.
>

I appreciate your clarification on the terminology but if you search
https://mailarchive.ietf.org/arch/browse/cfrg/?q=standard or
https://mailarchive.ietf.org/arch/browse/cfrg/?q=rfc, thousands of results
show up.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Apr 2021 15:08:24 +0000

*   I appreciate your clarification on the terminology but if you search https://mailarchive.ietf.org/arch/browse/cfrg/?q=standard<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/browse/cfrg/?q=standard__;!!GjvTz_vk!E6xjtvvy1OXYy0pOqqYwHelJmVfKLyxuhxijwbMY0JhN1D8TGyK8p8VPIfqi$> or https://mailarchive.ietf.org/arch/browse/cfrg/?q=rfc<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/browse/cfrg/?q=rfc__;!!GjvTz_vk!E6xjtvvy1OXYy0pOqqYwHelJmVfKLyxuhxijwbMY0JhN1D8TGyK8px-e6ChD$>, thousands of results show up.
 That doesn’t matter.  What matters is what the document *is*

I can post a message saying “I have a standard way to remove fleas from dogs using software”  But that doesn’t make it an Internet-Draft, let alone a standards-track RFC.

---

From: Quan Thoi Minh Nguyen <[email-masked]>
Date: Mon, 26 Apr 2021 08:19:58 -0700

On Mon, Apr 26, 2021 at 8:08 AM Salz, Rich <[email-masked]> wrote:

>
>    - I appreciate your clarification on the terminology but if you search
>    https://mailarchive.ietf.org/arch/browse/cfrg/?q=standard
>    <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/browse/cfrg/?q=standard__;!!GjvTz_vk!E6xjtvvy1OXYy0pOqqYwHelJmVfKLyxuhxijwbMY0JhN1D8TGyK8p8VPIfqi$>
>    or https://mailarchive.ietf.org/arch/browse/cfrg/?q=rfc
>    <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/browse/cfrg/?q=rfc__;!!GjvTz_vk!E6xjtvvy1OXYy0pOqqYwHelJmVfKLyxuhxijwbMY0JhN1D8TGyK8px-e6ChD$>,
>    thousands of results show up.
>
>  That doesn’t matter.  What matters is what the document **is**
>
>
>
> I can post a message saying “I have a standard way to remove fleas from
> dogs using software”  But that doesn’t make it an Internet-Draft, let alone
> a standards-track RFC.
>

It doesn't matter to you, but it does matter to other people like me. I
only subscribed to this cfrg mailing list a few days ago and there, the
word standard and rfc are used quite often (the search result definitely
has false positives, but has true positives as well). The github
https://github.com/cfrg/draft-irtf-cfrg-bls-signature from the authors says
"BLS *Standard* Draft" and it also says "The repo is maintained by a
working group aiming to* standardize BLS signature scheme*".

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Apr 2021 15:24:19 +0000

*   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. There is a reason, after all, why the document is called a *draft*

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Apr 2021 11:23:46 -0400

> dogs using software”  But that doesn’t make it an Internet-Draft, let alone

Obligatory: https://tools.ietf.org/html/draft-wkumari-not-a-draft-11

W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Quan Thoi Minh Nguyen <[email-masked]>
Date: Mon, 26 Apr 2021 08:46:46 -0700

On Mon, Apr 26, 2021 at 8:24 AM Salz, Rich <[email-masked]> 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
https://github.com/google/wycheproof/blob/master/doc/bugs.md), 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**
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Apr 2021 15:10:01 -0400

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Apr 2021 09:15:13 +1200

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 https://www.ietf.org/about/participate/get-started/ 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.

Regards
   Brian Carpenter

On 27-Apr-21 03:46, Quan Thoi Minh Nguyen wrote:
> 
> 
> On Mon, Apr 26, 2021 at 8:24 AM Salz, Rich <[email-masked] <mailto:[email-masked]>> 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 https://github.com/google/wycheproof/blob/master/doc/bugs.md), 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**____
> 
>     __ __
>