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

[Quan Thoi Minh Nguyen <[e-mail]>]

Hi,

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.

Thanks,
- Quan

On Sat, Apr 24, 2021 at 10:53 AM Paul Hoffman <[e-mail]> 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 https://github.com/cfrg/draft-irtf-cfrg-bls-signature
> incorrectly uses the word "standard" at the top of the repo. Maybe the
> CFRG chairs could review all of the repos in https://github.com/cfrg to
> make sure that their wording is accurate.)
>
> --Paul Hoffman
>