Subject: [Cfrg] Call for adoption: Threshold Signatures

From: Nick Sullivan <[email-masked]>
Date: Thu, 8 Oct 2020 09:33:53 -0700

Dear CFRG participants,

After some active conversations on the mailing list, there seems to be
support for taking on work related to threshold signatures at the CFRG.
This email commences a 3-week call for adoption for the topic of "Threshold
Signatures" that will end on October 28th, 2020:

There are two drafts that have been submitted for consideration on this
topic:
https://datatracker.ietf.org/doc/draft-komlo-frost/
https://datatracker.ietf.org/doc/draft-hallambaker-threshold-sigs/

Please give your views on the following questions:
a) should this topic be adopted by the CFRG as a work item, and if so
b) should one or both of these documents should be considered as a starting
point for this work
c) are you willing to help work on this item and/or review it

Please reply to this email (or in exceptional circumstances, you can email
CFRG chairs directly at [email-masked]).

Thank you,
Nick (for the chairs)

---

From: Deirdre Connolly <[email-masked]>
Date: Thu, 8 Oct 2020 12:52:55 -0400

Definitely support work on the FROST draft; we are planning to use it in
the context of Zcash, and I am willing to help.

On Thu, Oct 8, 2020, 12:34 PM Nick Sullivan <nick=
[email-masked]> wrote:

> b) should one or both of these documents should be considered as a
> starting point for this work
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 08 Oct 2020 09:55:36 -0700

Any work the CFRG does on describing threshold signatures should 
probably also incorporate work being done elsewhere. For example, US 
NIST has a major work item on standardizing such methods:
    https://csrc.nist.gov/publications/detail/nistir/8214a/final

---

From: isis agora lovecruft <[email-masked]>
Date: Thu, 8 Oct 2020 21:11:58 +0000

Hi all,

I would definitely like to see a standarisation of FROST move forward, since I
already have two clients interested in using it, and I have a Rust
implementation in progress here: https://github.com/isislovecruft/frost-dalek
(If you grep for "[CFRG]" there's a few comments on things that I suspect might
be useful to specify in a standard.)

To that end, I'm happy to help the authors with both working on the draft and
review.

Best regards,
-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt

---

From: Ian Goldberg <[email-masked]>
Date: Thu, 8 Oct 2020 17:20:00 -0400

> To that end, I'm happy to help the authors with both working on the draft and

Multiple implementations already!  That's great!

I suppose I should just say for the record that as one of the authors of
FROST, I of course am also interested in seeing it move forward, and
would be involved in working on it.
-- 
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton School of Computer Science
University of Waterloo

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 8 Oct 2020 20:04:22 -0400

a) As one of the authors, yes.
b) Both (see below)
c) yes

I agree that we should proceed on the basis of specifying FROST. However,
most of the work that went into my spec was setting up the text so it is a
logical extension of RFC8032 and producing test vectors. So I think it
would probably make sense to merge.

I would also like to ask why we are starting with the hard application
(signature) and ignoring threshold key generation and threshold key
exchange.

On the NIST topic, I am pretty sure they don't want us to be waiting on
them.

---

From: Chelsea Komlo <[email-masked]>
Date: Fri, 9 Oct 2020 03:23:36 +0000

As another of the FROST authors, I am interested in the FROST draft moving forward and of course would be involved in working on it.

We have an implementation of FROST in Rust; note that this implementation will have minor changes as we receive feedback from our presentation at SAC [1] and elsewhere.

https://git.uwaterloo.ca/ckomlo/frost/

We have also been in discussion with those at NIST who are organizing the threshold signatures standardization effort, and will be participating in the upcoming workshop.

Note that FROST can also be used when keys are generated via a central dealer as well as via a DKG (Distributed Key Generation) protocol. We have both variants in our implementation, even though we specify only the DKG variant.

https://git.uwaterloo.ca/ckomlo/frost/-/blob/master/src/keygen.rs

<https://git.uwaterloo.ca/ckomlo/frost/-/blob/master/src/keygen.rs>[1] https://sac2020.ca/papers.html

________________________________
From: Cfrg <[email-masked]> on behalf of Ian Goldberg <[email-masked]>
Sent: Thursday, October 8, 2020 9:20 AM
To: [email-masked]
Subject: Re: [Cfrg] Call for adoption: Threshold Signatures

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 Oct 2020 11:22:48 -0400

Just to clarify here. The group should only be working on one threshold
signatures draft for Ed25519 and Ed448. I think we need to decide whether
we are working on threshold first, then decide which bits of threshold and
only then go on to consider how the drafts are structured. We might have
one or three.

There are three separate work pieces that the group may consider:

Threshold Key Generation
Threshold Key Agreement
Threshold Signatures.

Threshold Key Generation can be used for key agreement or signature. How
you are going to use the shares doesn't change how you get them. The only
real difficulty in Threshold Key Agreement is the need to explain how to
obtain and represent the parity information in X25519 and X448.

The biggest leverage we can get from this work is if we can get CPU makers
to put an ECDH core on their CPUs with a key bound during manufacture. And
to do that we really need a story on all three. I strongly suspect that the
origin point for the NIST work was some work that has been going on in the
cyber supply chain area for a decade now.

Having a standard is more than just having a draft with the math. We also
need to specify a new private key format for the key shares, create test
vectors and the like.

On Thu, Oct 8, 2020 at 11:23 PM Chelsea Komlo <[email-masked]> wrote:

> As another of the FROST authors, I am interested in the FROST draft moving
> forward and of course would be involved in working on it.
>
>
> We have an implementation of FROST in Rust; note that this implementation
> will have minor changes as we receive feedback from our presentation at
> SAC [1] and elsewhere.
>
>
> We have also been in discussion with those at NIST who are organizing the
> threshold signatures standardization effort, and will be participating in
> the upcoming workshop.
>
>
> Note that FROST can also be used when keys are generated via a central
> dealer as well as via a DKG (Distributed Key Generation) protocol. We have
> both variants in our implementation, even though we specify only the DKG
> variant.
>
>
> ------------------------------
> *From:* Cfrg <[email-masked]> on behalf of Ian Goldberg <
> [email-masked]>
> *Sent:* Thursday, October 8, 2020 9:20 AM
> *To:* [email-masked]
> *Subject:* Re: [Cfrg] Call for adoption: Threshold Signatures
>
> > implementation in progress here:
> https://github.com/isislovecruft/frost-dalek

---

From: Chelsea Komlo <[email-masked]>
Date: Fri, 9 Oct 2020 22:25:44 +0000

We (the authors of FROST) are happy to make our draft compatible with some standard key representation. However, we prefer for our draft to be otherwise independent, as we don't want to be blocked on the completion of another draft.

Further, when operating in the distributed key generation setting, FROST has specific security requirements; namely that signers prove possession of their private key.

Here is what we propose. We can define at minimum a "plain" key-generation protocol in the FROST draft (such as a basic DKG and central dealer variant) so that we have some "shape" to work with and are not blocked/dependent on another draft. However, it should be easy for additional drafts to define alternative key generation protocols that will be compatible with FROST signing.

________________________________
From: Phillip Hallam-Baker <[email-masked]>
Sent: Friday, October 9, 2020 3:22:48 AM
To: Chelsea Komlo
Cc: Ian Goldberg; [email-masked]
Subject: Re: [Cfrg] Call for adoption: Threshold Signatures

Just to clarify here. The group should only be working on one threshold signatures draft for Ed25519 and Ed448. I think we need to decide whether we are working on threshold first, then decide which bits of threshold and only then go on to consider how the drafts are structured. We might have one or three.

Threshold Key Generation
Threshold Key Agreement
Threshold Signatures.

Threshold Key Generation can be used for key agreement or signature. How you are going to use the shares doesn't change how you get them. The only real difficulty in Threshold Key Agreement is the need to explain how to obtain and represent the parity information in X25519 and X448.

The biggest leverage we can get from this work is if we can get CPU makers to put an ECDH core on their CPUs with a key bound during manufacture. And to do that we really need a story on all three. I strongly suspect that the origin point for the NIST work was some work that has been going on in the cyber supply chain area for a decade now.

Having a standard is more than just having a draft with the math. We also need to specify a new private key format for the key shares, create test vectors and the like.

On Thu, Oct 8, 2020 at 11:23 PM Chelsea Komlo <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Cfrg <[email-masked]<mailto:[email-masked]>> on behalf of Ian Goldberg <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 8, 2020 9:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Cfrg] Call for adoption: Threshold Signatures

On Thu, Oct 08, 2020 at 09:11:58PM +0000, isis agora lovecruft wrote:
> > CFRG chairs directly at [email-masked]<mailto:[email-masked]>).
> >
> > Thank you,
> > Nick (for the chairs)
>
> > [email-masked]<mailto:[email-masked]>

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Jeff Burdges <[email-masked]>
Date: Mon, 12 Oct 2020 14:27:18 +0200

> On 8 Oct 2020, at 18:33, Nick Sullivan <nick=[email-masked]> wrote:

There are numerous crap multi-signature implementations so yes maybe a good time.  

> b) should one or both of these documents should be considered as a starting point for this work

I’ve not looked closely at either draft, so I’ll need to do so, but.. 

I do think a deliniarized witness approach works best, like what we deployed in January or what FROST switched to in July.  I’ll therefore only comment on two issues I see with the FROST paper.

1. Flexible rounds are a foot gun

These “flexible rounds” seem dangerous because they make witness freshness an implementation detail external to the cryptographic code.   I’m sure ZCash could deploy flexible rounds security for their use case because they work quite closely with their wallet developers.  It’s unlikely however that most organizations could deploy flexible rounds securely.  I’d therefore suggest that anything about flexible rounds be excluded from standards. 

Also, there are actually three choices here, (1) MuSig-DN requires agreements by the first round, (2) deliniarized witnesses permit agreement on message and signer by the second round, and (3) flexible rounds abuses deliniarized witnesses by allowing "pre-witnesses” to be saved to disk to combine many first rounds into one setup round. 

If you do want flexible rounds then you need quite patient and careful developers who do not mind inspecting the details of storage code, all application error handling, etc.  It’ll be very messy and expensive work.  I guess a TEE helps.

I’ve not even checked if the draft discusses flexible rounds.  If not, then no changes anyways.  

2. FROST has no security proof

FORST has a proof for an interactive protocol, which they follow with a heuristic resembling Fiat-Shamir but "cross session".  It’s exactly this sort of argument against which Drijvers, et al. warned!  There is a time and place for heuristic arguments, but not right after Drijvers, et al. broke so many related arguments in https://eprint.iacr.org/2018/417.pdf 

Also FROST also confuses this situation with their “one-shot VRF” terminology.  It’s true deliniarization produces PRF-like properties, but the resulting PRF is nothing like a VRF because the parameter acts differently.  If this miss-leading VRF terminology appears then it should be removed. 

All that said, we have in https://eprint.iacr.org/2020/1245/20201009:113646 what should be a correct security proof in AGM+ROM+KOSK+OMDL [0] for a related scheme, to which I gave the uninspired name 2-DWMS.  I’ll caution anyone who reads the proof that, although we never say forking or rewinding, our probabilistic method argument and H_0 tweak do use in full force that the Schnorr challenge oracle H is a random function (ROM).

2-DWMS-Sign:
Round 1.  Each candidate signer i proposes two pre-witnesses T_{i,j} = t_{i,j} G for j=1,2 (the 2-).
Round 2.  After agreement upon the message msg and signers [1] then everyone computes the aggregate public key X, a transcript of this data and the pre-witnesses
     trns = (msg, X, T_{1,1},T_{1,2},T_{2,1},…,T_{n,1},T_{n,2})
  and delinearization factors  \alpha_{i,j} = H_1(trns, i, j)  and a shared witness  S = \sum_{i,j} \alpha_{i,j} T_{i,j}.  Also compute and send a partial signature
     s_i = H(msg, X, S) sk_i + \alpha_{i,1} t_{i,1} + \alpha_{i,2} t_{i,2}
where sk_i is the ith signers secret key tweaked by Lagrange coefficients or whatever your scheme requires.

We broke 1-DWMS that delinearizes just one pre-witness.  FROST uses “1.5”-DWMS where signers supply two pre-witnesses (same first round), but alpha_{i,1} = 1 instead being a random oracle (one less scalar multiplication).  We broke the “1.5”-Entwined ROS property used internally by our security proof, so our security arguments depends upon alpha_{i,1} being a random oracle.  You therefore cannot deduce security for “1.5”-DWMS aka FROST using our current results. 

At first I thought “1.5”-DWMS might be breakable with 1024 parallel sessions, but..  We'll likely prove security for “1.5”-DWMS after some recent improvements elsewhere, although this requires convincing myself of one fishy step. 

Assuming we prove “1.5”-DWMS aka FROST to be secure, then there remains a sticky situation:  I suspect the “1.5”-entwined ROS break means alpha_{i,1} being a random oracle matters for some use cases like implicit certificates, and maybe even some “adaptor" signatures, meaning FROST becomes insecure under some Schnorr-like schemes with different verification rules. 

As a standard, I’d tentatively suggest we "take the high road” by recommending 2-DWMS over “1.5”-DWMS, so that alpha_{i,1} becomes a random oracle in this draft, and each signer does one extra scalar multiplication per signer.  Again I’ve nothing concrete here so I might change my mind!  We should anyways caution users about using altered verification like implicit certificates, etc. without adapting security proofs to their altered verification. 

> c) are you willing to help work on this item and/or review it

Yes in principle.  I suppose a draft normally cites external resources for formal arguments, yes?  If folk wish I could supply brief comments on correctly proving security for deliniarized witness schemes.  I’ll figure out if our improved proof applies to “1.5”-DWMS regardless. 

Best,
Jeff

[0]  AGM can mean several things, and the name sucks, but we need an AGM that lives closer to GGM than some extractor variants.  

[1]  As hinted above, agreeing upon the signer set and message by the second round is much weaker than “flexible rounds” like FROST proposes.  FROST proposes that the pre-witness secrets t_{i,j} be saved to disk, so then restoring from backups compromises users' secret keys (either if done twice or if done once and under a k-sum attack).

---

From: Nick Mathewson <[email-masked]>
Date: Mon, 12 Oct 2020 12:22:23 -0400

On Thu, Oct 8, 2020 at 12:34 PM Nick Sullivan
<nick=[email-masked]> wrote:
>
> Dear CFRG participants,
>
> After some active conversations on the mailing list, there seems to be support for taking on work related to threshold signatures at the CFRG. This email commences a 3-week call for adoption for the topic of "Threshold Signatures" that will end on October 28th, 2020:
>
> There are two drafts that have been submitted for consideration on this topic:

Hello!

Briefly:
  a) yes.
  b) slight preference for FROST, with a proviso that I'm more of a
cryptography consumer than a standards producer.
  c) I can comment on drafts from time to time from the perspective of
a downstream user of cryptography, but I am not a cryptographer and am
not competent to review cryptographic security.

In more detail:

Speaking as a Tor developer: we have a few use cases that would
benefit from a standardized threshold signature system, especially if
one were to be standardized some time in 2021.  For us the biggest
benefit to such a system would be in our network's directory authority
system, which currently authenticates large directory objects using
one signature from each authority.  Our plan is to move to a different
design [1] [2], however, in which many smaller objects need to be
authenticated individually.  A multisignature design would be a bit
too expensive for this use, so threshold signatures seem like a clear
win.

General preferences for any eventual standard:

  1)  We'd prefer a system that tolerates concurrent use.  For
distributed systems like ours, it's much more comfortable to have a
system that tolerates concurrent runs than it is to try to prove that
a concurrent run could never happen.

       IIUC, the mechanism that FROST uses to make concurrent use safe
(safer?) seems like it would be portable to other signature systems of
this kind, so I hope it will be included in whatever design is
produced.

  2) Compatibility with existing standardized signature formats
(ideally ed25519 or ed448) is indeed a big plus for us.

  3) Being able to operate without a trusted or centralized
coordinator is important for our application, so we'd want any
standard to at least include a way to work without one.

[1] https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/323-walking-onions-full.md
[2] https://www.usenix.org/conference/usenixsecurity20/presentation/komlo

yrs,
-- 
Nick Mathewson

---

From: Richard Barnes <[email-masked]>
Date: Mon, 12 Oct 2020 17:14:16 -0400

a) I think this could be a good item for CFRG to work on.  To Paul's point,
I think the discussion here can complement the NIST process.  One potential
point of difference / complementarity -- I would like it if whatever this
group produces could include concrete instantiations for the CFRG signature
schemes Ed25519 and Ed448.  Not sure if NIST is looking at things at that
level of granularity.

b) I have reviewed both documents, and FROST seems like the clearly better
option here.  Like Nick, I am more of a consumer than a cryptographer, but
FROST seems to have considered a much broader collection of risks (e.g.,
the attack by Drijvers et al.) and operational considerations than PHB's
scheme.  And as an implementer, I found FROST very clearly specified and
easy to understand.  I was able to adapt it for use with Ed25519 and
implement it in Go without much trouble.

c) I am willing to contribute and provide reviews on updated documents.  In
particular, as noted above, I've thought a bit about specializating FROST
to Ed25519, and would be glad to contribute that as a starting point.

--Richard

---

From: Chelsea Komlo <[email-masked]>
Date: Tue, 20 Oct 2020 14:25:05 +0000

Hi Jeff,

Optimization to a single-round signing scheme. The ability to perform single-round (or async) signing is desirable for many implementers (and publishing public ephemeral values is a common technique in other cryptographic protocols). While misuse is possible, rollback issues are also possible in a two-round scheme as checkpoints can occur between rounds.

However, we believe discussion and the decision on this point should be made in the working group, so we won't elaborate further.

Proof of Security for FROST. We have carefully reviewed your points in this email and eprint. As you said, your proof technique cannot be extended to prove the security of FROST. However, this result does not entail that FROST is insecure. We also want to highlight the MuSig2 paper [1] that also independently discovered the "binding" (or "delinearization") technique that FROST uses. Their proof is in the AGM+ROM, and proves security for two nonces when the binding factor for the first nonce is 1 (exactly the pattern that we use in FROST). We can certainly provide more explanation of our proof and how it compares to proving security in the AGM.

Happy to answer other questions, but we would prefer more in-depth discussion in the working group.

Chelsea and Ian

[1] https://eprint.iacr.org/2020/1261

________________________________
From: Cfrg <[email-masked]> on behalf of Jeff Burdges <[email-masked]>
Sent: Monday, October 12, 2020 12:27 AM
To: Nick Sullivan; IRTF CFRG
Subject: Re: [Cfrg] Call for adoption: Threshold Signatures

2-DWMS-Sign:

Best,
Jeff

---

From: Jeff Burdges <[email-masked]>
Date: Wed, 21 Oct 2020 15:33:45 +0200

I’d meant to send a follow up email, but I already moderated my position on both those points.  :)

> On 20 Oct 2020, at 16:25, Chelsea Komlo <[email-masked]> wrote:

We need “hardware” security for the two pre-witnesses between the rounds, which software artifacts should enforce.  It’s easy if the hardware is simply RAM and if libraries enforce this by not providing callers with access to pre-witnesses in an easy to serialize form.  It’s also perfectly valid for a signer that runs inside a TEE to export pre-witnesses encrypted to its TEE.  It’s realistic for hardware signers for crypto-currencies to enforce this of course.

Yet, if you merely expose pre-witnesses directly in pure software, or write the draft s if that’s okay, then developers will reuse them.  This is a certainty, and will happen repeatedly, not some abstract risk.  

> Proof of Security for FROST. We have carefully reviewed your points in this email and eprint. As you said, your proof technique cannot be extended to prove the security of FROST. However, this result does not entail that FROST is insecure.

It turned out easy to tweak our entwined ROS result to cover "1.5 pre-witnesses" once I looked into the matter.  We’ll post another version with this update soon-ish once we’ve tweaked it to capture more generality, maybe minimize the KOSK assumption.  Of course KOSK is fine for threshold.

I worried more about whether “1.5 pre-witnesses" breaks altered verification schemes, but now some look okay and some like implicit certs require way more work anyways.  I’m thus now happy with “1.5” like in FROST so we just need warnings about using altered verification.  

It needs warnings about less than 256 bit to delinearization oracles too since I’ve witnessed people suggesting 128 bits with one oracle set to 1 for public keys before.

> We also want to highlight the MuSig2 paper [1] that also independently discovered the "binding" (or "delinearization") technique that FROST uses. Their proof is in the AGM+ROM, and proves security for two nonces when the binding factor for the first nonce is 1 (exactly the pattern that we use in FROST).

I’ve not yet looked beyond the MuSig2 paper’s intro, but..  It’s super cool that they also prove the result with four pre-witnesses under only ROM!  I would never have had courage to even attempt that.  :)  I think a draft need not discuss the four witness option, but we should discuss that with the MuSig2 guys since others may have other opinions. 

> We can certainly provide more explanation of our proof and how it compares to proving security in the AGM.

I read FROST v2 as claiming the two pre-wtinesses protocol is secure under ROM alone.  We’d could ask the MuSig2 guys if they believe that’s possible, or at least read how they use the extra witnesses ourselves, like maybe possible with a larger runtime sacrifice than merely two forkings, or maybe not possible. 

At first blush, I suspect if one actually formalizes your "cross session” Fiat-Shamir then you’ll wind up arguing security for outright broken stuff.  I never actually tried though, so I really donno, maybe something useful there. 

Anyways..

I’d love some guidance from the rest of the group about to what extent provable security issues should even appear inside the draft.

Best,
Jeff

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Oct 2020 14:11:37 -0400

On Wed, Oct 21, 2020 at 9:37 AM Jeff Burdges <[email-masked]> wrote:

> > Optimization to a single-round signing scheme. The ability to perform
> single-round (or async) signing is desirable for many implementers (and
> publishing public ephemeral values is a common technique in other
> cryptographic protocols). While misuse is possible, rollback issues are
> also possible in a two-round scheme as checkpoints can occur between rounds.
>
> We need “hardware” security for the two pre-witnesses between the rounds,
> which software artifacts should enforce.  It’s easy if the hardware is
> simply RAM and if libraries enforce this by not providing callers with
> access to pre-witnesses in an easy to serialize form.  It’s also perfectly
> valid for a signer that runs inside a TEE to export pre-witnesses encrypted
> to its TEE.  It’s realistic for hardware signers for crypto-currencies to
> enforce this of course.
>

What are we defining as a 'round' here? Calling something a pre-witness
does not mean it disappears.

At the protocol engineering level we are always looking for ways to
piggyback one message on another. But if I need to generate and register
anything that looks like a commitment whether it is called a round or a
pre-witness is looking like a round to me.

> Yet, if you merely expose pre-witnesses directly in pure software, or
> write the draft s if that’s okay, then developers will reuse them.  This is
> a certainty, and will happen repeatedly, not some abstract risk.
>

It is not clear to me where the controls to prevent this should go. At the
application protocol level, there are precautions that can be taken. But
they tend to get very context specific. I can't see a good generic
construct at this point. But that doesn't mean one can't exist.

Also, this is getting into design, not discussing whether we should be
doing the work.

> I’d love some guidance from the rest of the group about to what extent
> provable security issues should even appear inside the draft.
>

That is a good question as the answer might well be changing. We have not
provided proofs in the past. Analysis has been left to separate papers. And
one reason for that is the document format was not up to the task of
describing a proof. We now have a document format that makes providing a
proof more practical but it is still less than satisfactory in that respect.

The point of this process is to provide cryptographic capabilities in a
form that can be employed as modules in a network protocol. And that raises
a rather different set of concerns to those considered in academic papers.
We expect modules to be re-usable. There is an active academic interest in
threshold signature schemes because those are genuinely difficult, the ECDH
type signature schemes having the property that if you mess up, you leak
the private key, oops. As a protocol designer, threshold encryption is far
more interesting but as far as I can tell, the issues were addressed over
20 years ago. Nobody is going to be getting tenure out of a Threshold key
agreement algorithm. But Data At Rest breaches are costing billions of
dollars and threshold is almost certainly part of the answer.

So ultimately, it is up for the RG chairs to decide what they want to do.

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 28 Oct 2020 12:55:49 -0700

> a) should this topic be adopted by the CFRG as a work item, and if so

Yes. There are many emerging use cases for threshold signatures, as evidenced by the NIST effort, and I think it'd be useful for CFRG to complement RFC8032 with this functionality. 

> b) should one or both of these documents should be considered as a starting point for this work

Probably only one. The structure of draft-hallambaker-threshold-sigs as an extension to RFC8032 is attractive, though I think draft-komlo-frost (and the related paper) is generally a better starting point, especially given its assessment of attacks on related schemes such as 2020/945. It also seems to have plenty of backing implementations and reviews. If we can specialize it to RFC8032, perhaps with Richard's work as the basis for that change, then I prefer FROST.

> c) are you willing to help work on this item and/or review it

Yes to both.

Best,
Chris

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Oct 2020 21:49:10 -0400

On Wed, Oct 28, 2020 at 3:57 PM Christopher Wood <[email-masked]>
wrote:

> Yes. There are many emerging use cases for threshold signatures, as
> evidenced by the NIST effort, and I think it'd be useful for CFRG to
> complement RFC8032 with this functionality.
>
> Probably only one. The structure of draft-hallambaker-threshold-sigs as an
> extension to RFC8032 is attractive, though I think draft-komlo-frost (and
> the related paper) is generally a better starting point, especially given
> its assessment of attacks on related schemes such as 2020/945. It also
> seems to have plenty of backing implementations and reviews. If we can
> specialize it to RFC8032, perhaps with Richard's work as the basis for that
> change, then I prefer FROST.
>

As I keep pointing out, I just want algorithms I can use in my Threshold
Key Infrastructure.

Ian and Chelsea have convinced me that the attack is an issue so I think we
should plan on using the FROST algorithm. But I think the draft is quite a
way from being a standards specification. It is also clear that there is
going to be quite a lot of discussion to get any signature spec agreed. It
is a hard problem. We are going to need to discuss various proofs etc.

The point of CFRG process is to produce useful tools that the IETF and
related communities can use.

Why is it that we are insisting on doing the hardest threshold problem and
only the hardest problem?