From nobody Fri Apr 23 15:41:58 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 5B74F3A128E for ; Fri, 23 Apr 2021 15:41:57 -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 49IEWmIilRYc for ; Fri, 23 Apr 2021 15:41:52 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 AC5BB3A1289 for ; Fri, 23 Apr 2021 15:41:52 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id j14-20020a17090a694eb0290152d92c205dso1988382pjm.0 for ; Fri, 23 Apr 2021 15:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aPrkw4TO1jpJ0ut8SVqNQpBDse8ipyWsZwe7ClDay5o=; b=g9f72qUlWI7kLCze/H0VbjcICqNx4NV1M512LzLjcQnwROY9j/37rCOVfpBN+VRPDi skspbLeugLzZ/l9ve0cHwN41niSQ9BO9BWnwyMc9QfQLLx8uvg9l5ui49ujnBafkmJqd xUYY6k6/hv+I+ZJAxsIfUBFjBSg8TcIOAmOYbNL0dHotyjNqjqjxnUMnUWykCqgH5jkW dvVKZH4PBNE+0IK10Fq3ODV9qW6LDAJgVsV6HZSKDUiAbEhSGmuVoEecEMul+jDNxZtd igIOSX+e75rBOG12oNKSughhMSffG0cocmTYC6NoPiXC+8asr+2NTVdvofWus0YfTKHr /EGA== 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=aPrkw4TO1jpJ0ut8SVqNQpBDse8ipyWsZwe7ClDay5o=; b=kp793QDbUb7Jb1OUlRTz1TXy5GQE0zjRwoCA78/0sccrle78WmP817c8/zmbcTGH9k LiTyR9UqtD+tk0zz0ybuWYiT69ijgDU41KPHy5SsXtmmTjBF5kEtDEkvEdwvcSCmj43Y XCvFF5BP8ab3QrMlGFmWCWTsYSZFdz+stej4VKX9VPtax2Tfx3jPctnT6ytsYlO6h1aN HmJwvBhBsulH3VVnurQRdLpeOWDJIuwX3tiEwrCPNQOgMe5FkruzMaRSBQ9LVStGKJjr aYglIj9Td6UgmknWfEfs9eb6j7bv6/UTeShubn2/IwNUQ18u6bORkPOmcFUx0EYxoF6/ tBIA== X-Gm-Message-State: AOAM531YCom6wMLGW78Tm2RmPGFc0G+A5Yk+tc8BmwTZljQ3VZ/ktCiu t/gacBykzCJGX+o/Deul4MjtgT26sEqIMXq3pFg= X-Google-Smtp-Source: ABdhPJyxPnmslT8LPQ91Mb54vAXq6mbno/JwrCQpgG8wx2yidvbK9tC72j99d/JRHZCViC/ZliEjmFxO3fOM6k5FXe0= X-Received: by 2002:a17:90a:d983:: with SMTP id d3mr6798909pjv.99.1619217711060; Fri, 23 Apr 2021 15:41:51 -0700 (PDT) MIME-Version: 1.0 References: <20210423195504.d6f74x4jsdrzagcc@muon> In-Reply-To: <20210423195504.d6f74x4jsdrzagcc@muon> From: Quan Thoi Minh Nguyen Date: Fri, 23 Apr 2021 15:41:15 -0700 Message-ID: To: "Riad S. Wahby" Cc: cfrg@irtf.org Content-Type: multipart/alternative; boundary="0000000000007b5a3205c0ab80a3" Archived-At: Subject: Re: [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 22:41:57 -0000 --0000000000007b5a3205c0ab80a3 Content-Type: text/plain; charset="UTF-8" Hi Riad, Thanks for your response. From github repository, you're the main contributor. However, I think it's *not* your sole responsibility to deal with it. There are *5* authors in the BLS RFC draft v4 https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-04. Should at least another author step up and make a concrete time commitment to fix it? These bugs have been existing for a few months in *production*. It's very unfortunate that the bottleneck for fixing security bugs is purely voluntary and has no commitment. This sounds pretty wrong from a vulnerability management point of view. I don't have any proposal to mitigate this deadlock. Thanks, - Quan On Fri, Apr 23, 2021 at 12:55 PM Riad S. Wahby wrote: > Hi Quan, > > (Reposting my message from GitHub.) > > I really appreciate your reporting the bug and all of the thought > you have clearly put into this. > > The short answer to your question, "what is the time commitment of the > authors?" is: we're doing this on a volunteer basis, and therefore real > life takes priority. For my part: I have not had a moment's spare time > in the last 6 months. I hope to have time in the next several weeks > to think more about this but I do not have more specific information > than that. I can't speak for any of the other authors. > > Regarding deployment in production: I really do understand the concern > here, and I share it. But this document is in draft status, which means > the risk of bugs or incomplete features is understood to be nonzero, > including by people who choose to deploy the draft specification. > I am not pointing this out to be legalistic or to justify inaction, > only to push back on the idea that somehow production deployment > changes the authors' volunteer status or time commitment. > > I very much plan to deal with this issue once real life lets up a bit, > but I do not know how soon that is. That is really the best commitment > I can give you. > > Thanks for understanding, > > -=rsw > --0000000000007b5a3205c0ab80a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Riad,=C2=A0

Thanks for your response= . From github repository, you're the main contributor. However, I think= it's not=C2=A0your sole responsibility to deal with it. There a= re 5=C2=A0authors in the BLS RFC draft v4=C2=A0https://tools.ietf.org/= html/draft-irtf-cfrg-bls-signature-04. Should at least another author s= tep up and make a concrete time commitment to fix it? These bugs have been = existing for a few months in production.

It= 's very unfortunate that the bottleneck for fixing security bugs is pur= ely voluntary and has no=C2=A0commitment. This sounds pretty wrong from a v= ulnerability management point of view. I don't have any proposal to mit= igate this deadlock.

Thanks,
- Quan


On Fri, Apr 23, 2021 at 12:55 PM Riad S. Wahby <rsw@jfet.org> wrote:
Hi Quan,

(Reposting my message from GitHub.)

I really appreciate your reporting the bug and all of the thought
you have clearly put into this.

The short answer to your question, "what is the time commitment of the=
authors?" is: we're doing this on a volunteer basis, and therefore= real
life takes priority. For my part: I have not had a moment's spare time<= br> in the last 6 months. I hope to have time in the next several weeks
to think more about this but I do not have more specific information
than that. I can't speak for any of the other authors.

Regarding deployment in production: I really do understand the concern
here, and I share it. But this document is in draft status, which means
the risk of bugs or incomplete features is understood to be nonzero,
including by people who choose to deploy the draft specification.
I am not pointing this out to be legalistic or to justify inaction,
only to push back on the idea that somehow production deployment
changes the authors' volunteer status or time commitment.

I very much plan to deal with this issue once real life lets up a bit,
but I do not know how soon that is. That is really the best commitment
I can give you.

Thanks for understanding,

-=3Drsw
--0000000000007b5a3205c0ab80a3--