From msuntmquan@gmail.com Fri Apr 23 09:14:18 2021 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2743A1480 for ; Fri, 23 Apr 2021 09:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 C1WEVO2CK977 for ; Fri, 23 Apr 2021 09:14:17 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 16ED23A147F for ; Fri, 23 Apr 2021 09:14:16 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id m6-20020a17090a8586b02901507e1acf0fso1528352pjn.3 for ; Fri, 23 Apr 2021 09:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IkD+yzSJdVhPhSujEe1jHy4BFH0LS0X18eFyId/9Vz8=; b=ByyWawkmzNM03d07zzyWBtRlrhPfdLXJ045mYzharXLS1BslIeKfKx5SJexYN7ClPy JBc/qgBSp1pJpgW9gtFCyCt4Jt4oH4jHHAp4E3rl6IgDSDitMKc0yvi0GBXtfIUuGOsu I+95QI0wVBQoflCAD5hySWFHioqBa/Xh8dWZGbAbF0ICiLNR7d+HrLAwGbPYxXJkqffw T8ifY2l86oQbq9PKZF2+vInEpKQ0Dl26x8bhvIyrpWaisBb3h8v64mNuxXaBWMFOZ9+A 6ljN4TeCBWG17Gf05RFrYtLXjKrn60bU3ElbiUKzbKIUGYbq13+//RtYReTa14DLyQl7 aE4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IkD+yzSJdVhPhSujEe1jHy4BFH0LS0X18eFyId/9Vz8=; b=IUsIE4pSXghw2bTf26mYR0gAR6xKfiSUnOVhBa9i7icSHThL3MnICWxy3KAY1xZziF 9cGDARAO8mtYAM5B4WSHaoiXVYB+qvk2hz2gNfbE7+eLBf4jUir1ml1AcKgeHaWe5Cem 5RiK8GqcmmE13H4fUGNvXp7zGKDTAOj0ZPYmBRNz6BCSn0BhPD1HMapNAs2J5XBL4vLi lr0NDJze9PoRJpdFMXHW7D7ntuNFRQCJ7HIrWrdO//An+WWnCQ+pvSc9zRZ28BMiyuL+ fmHRkyWffpDSFsOtYxEnUKu0585CpDUtLfeCC38GuJMuz7y85cLeVXVFkewTRrs96RqM CyHw== X-Gm-Message-State: AOAM532+utiOXXUVhdsLATY07tVFpEwwKO/6QyUZcvDMKxoC56vBOYcm QQI2+LKmrZ47a1x7/KU3dK+a8m+kLMgVSoU8upG/Y+4PEmoNjw== X-Google-Smtp-Source: ABdhPJwqTIHGIZUW1LEO5FcJfMhGYS23nyoJxk2HrndgS0N41XHDIdYUYoY3D3wfERT6Jo7iK9u0aMBKeiWhEEFoI4U= X-Received: by 2002:a17:90a:94ca:: with SMTP id j10mr5300049pjw.126.1619194455255; Fri, 23 Apr 2021 09:14:15 -0700 (PDT) MIME-Version: 1.0 From: Quan Thoi Minh Nguyen Date: Fri, 23 Apr 2021 09:13:39 -0700 Message-ID: To: cfrg@irtf.org Content-Type: multipart/alternative; boundary="00000000000053ed1205c0a6160b" Archived-At: Subject: [CFRG] Escalation: time commitment to fix *production* security bugs for BLS RFC v4? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 19:37:46 -0000 --00000000000053ed1205c0a6160b Content-Type: text/plain; charset="UTF-8" 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 --00000000000053ed1205c0a6160b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'd like t= o escalate this issue to the CFRG chairs as a last=C2=A0resort. By responsi= bility disclosure mechanism, I reported the bugs privately far before I=C2=A0posted it publicly at=C2=A0https://github.com/cfrg/draft-irtf-cfr= g-bls-signature/issues/38. I did everything in my capability: reported = the bugs, wrote proof-of-concept attack, wrote proof-of-concept fix.
<= div>
I'm curious what is the time commitment of the RFC&#= 39;s authors in=C2=A0resolving the following deadlock:
+ Libraries code = (ethereum/py ecc, supranational/blst, herumi/bls,sigp/milagro bls) are depl= oyed in production. They're not academic nor experimental code.<= br>+ Libraries' authors can't fix the code because they have to fol= low the standard.
+ BLS RFC v4's authors don't move an inch in f= ixing it nor have any time commitment.

The=C2=A0st= andard authors=C2=A0are in an extremely powerful position where they dictat= e what every library should do. Does it go with responsibility for respondi= ng in a timely manner for security bugs deployed in production?
E= ven if they don't want to fix the message binding bug, should they at l= east fix a very obvious bug? AggregateVerify((PK_1, PK_2), (msg, msg), 0) = =3D True, FastAggregateVerify((PK_1, PK_2), msg, 0) =3D False.

Note that I'm not saying my proposed fix i= s correct and RFC's authors should follow it. What I'm asking is th= e BLS RFC authors' time commitments in resolving the security issues de= ployed in production?

Thanks,
- Quan

--00000000000053ed1205c0a6160b--