Re: [Cfrg] Adoption of threshold drafts by RG

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 22 September 2020 03:46 UTC

Return-Path: <hallam@gmail.com>
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 E10753A121E for <cfrg@ietfa.amsl.com>; Mon, 21 Sep 2020 20:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Level:
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 p9fXA1-DsGMx for <cfrg@ietfa.amsl.com>; Mon, 21 Sep 2020 20:46:05 -0700 (PDT)
Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (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 4D4613A121C for <cfrg@irtf.org>; Mon, 21 Sep 2020 20:46:05 -0700 (PDT)
Received: by mail-ot1-f44.google.com with SMTP id a2so14362514otr.11 for <cfrg@irtf.org>; Mon, 21 Sep 2020 20:46:05 -0700 (PDT)
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=1PEuVzGeALJzM+debTJQinaotSG2uULcBEJsMV0HY9E=; b=rH6wzmzS6cBS9FYUinaAr0A8pqDcDIGwfNAuxKovovBXBk5OQAwc6K8WMLN0SWV1gk +ky19puqBligyBjYAatg/SHJS+1epwuBvVvQcoaw0xM5B9Fh+7OSCXHjF6HsB78nIkWM IZtatAzJVyHFJMDxx01lGUm5Yjr5WED9EJTSfRhzb/aQuyHG12GY9avrCK73VbteHUUF JKVeGhejVWpZA+HISHU3WIrtoNSwXxRghGWpyJqD30dRz0T4YAqKP5wHJCibM6Oviwrv tMXJUuAnSBwGbWM1DAagnlD9AdchclVZefvg3k9LrafHBi8zYU/7KFPEISY1bArcswwr C9/w==
X-Gm-Message-State: AOAM533WAVzfYZ4Uuz1jBHMCmPDn352puJAwN3siVMBBts/wUU3mMVJ/ R/JTACnPQp0WD/9Lz6d3IzJcMUapgYElOmkJA4k=
X-Google-Smtp-Source: ABdhPJw7PB7AuEwJsRsce6Tu4QWK4Q6XJH96nFqw+D5NqkuLanAbi98im5IbTrsN0lSXuj1OfpNY/TxOQv1Ygou/DGY=
X-Received: by 2002:a9d:6654:: with SMTP id q20mr1053438otm.124.1600746364458; Mon, 21 Sep 2020 20:46:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+Lwj8z0i56G7iTh-z7fZM5z5=B7-x63rVJjuWT7mC1x6x3w@mail.gmail.com> <CACsn0c=9SwWsJ=D_gAStP+gnbfmZkTEokESa0wunpBxaJPvn3g@mail.gmail.com>
In-Reply-To: <CACsn0c=9SwWsJ=D_gAStP+gnbfmZkTEokESa0wunpBxaJPvn3g@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 21 Sep 2020 23:45:53 -0400
Message-ID: <CAMm+LwhYouVZtEGa54WgZ=VN_fpM+1XX8N5+o_yE2JZkiigzaQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: IRTF CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000006dda8605afdece55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/8ayqIbB6tHohPFHbVzw8ZUfpgv4>
Subject: Re: [Cfrg] Adoption of threshold drafts by RG
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2020 03:46:07 -0000

On Mon, Sep 21, 2020 at 7:01 PM Watson Ladd <watsonbladd@gmail.com> wrote:

> On Mon, Sep 21, 2020 at 12:25 PM Phillip Hallam-Baker
> <phill@hallambaker.com> wrote:
> >
> > Could the chairs please start the discussion of adoption of my threshold
> crypto drafts as was promised six months ago and on numerous occasions
> since?
> >
> >
> https://tools.ietf.org/id/draft-hallambaker-threshold-sigs-04.html#draft-hallambaker-threshold
> > https://tools.ietf.org/id/draft-hallambaker-threshold-sigs-04.html
>
> My understanding is NIST is carrying out a standardization activity
> https://csrc.nist.gov/projects/threshold-cryptography . While that's
> by no means a barrier to our adoption, I think alignment with the
> results of that activity are valuable.
>

I am aware of that work and provided feedback on their draft report.



> I would note the schemes described are insecure in the presence of
> concurrency, as well. https://eprint.iacr.org/2018/417.pdf explains
> some of the issues well, and it's really quite subtle and difficult.
> The design of FROST https://eprint.iacr.org/2020/852.pdf solves these
> issues, and I don't see any discussion in the draft of them.
>

Where do you see concurrency in the nested signature approach? The issue is
elided by enforcing a sequential order on the operations.

I have reviewed FROST. However the authors keep telling me they are not yet
ready to have it considered so I am not.

>From a practical point of view, the most common use I have found for
threshold signatures has t=2 with an application level share holder calling
an HSM (which may be local or remote) to perform a part of the signature
and then completing the process.