IETF Logo Mail Archive

Re: [Cfrg] Adoption of threshold drafts by RG

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 22 September 2020 03:55 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 5AB853A1212 for <cfrg@ietfa.amsl.com>; Mon, 21 Sep 2020 20:55:05 -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 Gc8w-prmyCKM for <cfrg@ietfa.amsl.com>; Mon, 21 Sep 2020 20:55:03 -0700 (PDT)
Received: from mail-oo1-f51.google.com (mail-oo1-f51.google.com [209.85.161.51]) (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 B80F93A0D77 for <cfrg@irtf.org>; Mon, 21 Sep 2020 20:55:03 -0700 (PDT)
Received: by mail-oo1-f51.google.com with SMTP id g26so3810592ooa.9 for <cfrg@irtf.org>; Mon, 21 Sep 2020 20:55:03 -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=FOfqoyPuDI+dT5LAey+PbfViIKtSwex5udfxwSp0kuo=; b=OFw9F4OKvCbZVoLvI04cWMc5ufeuCD52Kud438LcH4BCfZHHPJMoGxpKSJUW8K+gdv O3LZYUuDJddzwbusjermTAp/+KblJFM6p48ga6BjgImfoiVqbo7NYoLzQtYJYH6neino 6I8g6mINIiXvg6AHdxhMtl1IZH8SeaVrvEhDzAdP7QedGB/yO4rwsXwJdfupPFu/hK+M 38lqxMkxKf6CFBRk2NOHbsO8h0bjIDIjmhmZiAliBi92bT8uint0sXFw/qxQ8B5D752G wAXRB3b/K3tDTuETWT2vPaicArPpZKrCKEnJ5JpnxF32eTMwxUtmzgjpVMPMhv+dGRc4 pIrg==
X-Gm-Message-State: AOAM530DclKl/zf4C5ZrLarbJ9e/+khuztBngOfMwuIIkxdBZQ3FvAxq gB1yFag9izQlGEf1ayJzY6f7vpbuPD+9e+fPMBU=
X-Google-Smtp-Source: ABdhPJy7R1cdxb+2ZumWS6ZOgyUhRcbmKmiOYowH/YrMls6wzhh5i5uSUn6XeFabqgrYlcpjs//lI7w3kALd9J1RwW8=
X-Received: by 2002:a4a:bc90:: with SMTP id m16mr1749001oop.12.1600746903028; Mon, 21 Sep 2020 20:55:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+Lwj8z0i56G7iTh-z7fZM5z5=B7-x63rVJjuWT7mC1x6x3w@mail.gmail.com> <CACsn0c=9SwWsJ=D_gAStP+gnbfmZkTEokESa0wunpBxaJPvn3g@mail.gmail.com> <CAMm+LwhYouVZtEGa54WgZ=VN_fpM+1XX8N5+o_yE2JZkiigzaQ@mail.gmail.com>
In-Reply-To: <CAMm+LwhYouVZtEGa54WgZ=VN_fpM+1XX8N5+o_yE2JZkiigzaQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 21 Sep 2020 23:54:51 -0400
Message-ID: <CAMm+LwhXskmJgrUeH6mJEnkVnAwnaQA1S4oQjRRKn_hjH_YgKA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: IRTF CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000087ca5005afdeeee9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/XFSh-6wwsYoQAgcLmskgCJf_y4c>
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:55:05 -0000

Forgot to add. Yes we need to synchronize. But my understanding is that at
some point NIST will be endorsing the CFRG curves as alternatives to their
curves.

As a practical matter, SSH and TLS use the NIST curves and are likely to be
remaining with them for some time. So it is important and useful to specify
threshold modes for those curves. Thought where that gets published...


On Mon, Sep 21, 2020 at 11:45 PM Phillip Hallam-Baker <phill@hallambaker.com>
wrote:

>
>
> 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.
>

v2.23.0 | Report a Bug | By Email