Re: [CFRG] RGLC on draft-irtf-cfrg-frost-11

[Tim Ruffing <[e-mail]>]

Dear chairs and authors,

I spent some time to go through the document, and I think this looks
pretty mature, and is ready for an RFC modulo some minor and editorial
comments below. (I did not look at every detail in every algorithm, and
I did not look at the appendices.)

----

It may make sense to mention that FROST can be used in the case
MIN_PARTICIPANTS == MAX_PARTICIPANTS but in this special case of
multisignatures, other schemes (MuSig2, SpeedyMuSig) with nicer
properties (e.g., much simpler key generation) are available but out of
scope of this document. I believe this could be a useful hint for
applications that purely need an "n-of-n" solution. Of course, even for
these application, one may still come to the conclusion that FROST is
the way to go given that it's a RFC (assuming it makes it). 

> The nonce values produced by this function MUST NOT be reused in more
than one invocation of FROST, and it MUST be generated from a source of
secure randomness.

It's not clear what an "invocation" is in a two-round protocol. Maybe
"more than one invocation of the second round algorithm" or something
along these lines? Below you say "and MUST use the nonce to generate at
most one signature share." -- this is very clear.

>  Applications which require that participants not process arbitrary
input messages are also required to also perform relevant application-
layer input validation checks; see Section 7.5 for more details.

(Duplicate "also"). And this could make it a bit more explicit that
these don't just include adherence to some formal checks (syntax etc)
but also could involve the actual content of the message / willingness
to sign the message: For example, a cryptocurrency transaction must not
only be syntactically valid, it must also be *intended* by the
participants. (The second example Section 7.5 is an example of that
kind but when reading 7.5 as a whole, I again had the feeling that this
aspect could be emphasized.)

> Each participant MUST delete the nonce and corresponding commitment
after this round completes

It's not entirely clear what "completes" means here. (One could for
example wrongly assume that the round does not "complete" before the
aggregator outputs a signature.)

> If any signature share fails to verify, i.e., if
verify_signature_share returns False for any participant share, the
Coordinator MUST abort the protocol for correctness reasons (this is
true regardless of the size or makeup of the signing set selected by
the Coordinator).

To be honest, I'm not entirely sure why you require verification if the
individual signature shares. I assume this is to identify misbehaving
participants because you also say "However, in order to identify any
participant which has misbehaved (resulting in the protocol aborting)
to take actions such as excluding them from future signing operations
verification." If this is the case, then this purpose should be
clarified here. And then, it could make sense to mention the
optimization that the coordinator can simply first build the final
signature and verify it. Only if it doesn't verify, the coordinator
must look at the shares.

By the way, it took me a while to convince myself that misbehaving
participants cannot force the group commitment to be the identity
element (which typically couldn't be part of a valid signature even
though signature share verification would pass for all shares). This
can happen in the scheme in our MuSig2 BIP draft due to the fact that
we use the same binding factor for everyone (because we want commitment
aggregation). And then we need to be careful when we deal with the
identity element, and need some special casing, see the paragraph
https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki#Dealing_with_Infinity_in_Nonce_Aggregation
if you're interested in the details. But this doesn't seem to be a
problem here in your draft now that you've switched to different
binding factors.

> This includes checking that [...] that the point is not the point at
infinity. Additionally, this function validates that the resulting
element is not the group identity element.

These two checks are in fact the same check.

> Honest-but-curious coordinator. We assume an honest-but-curious
Coordinator which, at the time of signing, does not perform a denial of
service attack. A denial of service would include any action which
either prevents the protocol from completing or causing the resulting
signature to be invalid. Such actions for the latter include sending
inconsistent values to participants, such as messages or the set of
individual commitments.

Towards what (security) property do you assume this? In the next
paragraph say "Under this threat model, FROST aims to achieve signature
unforgeability". But unforgeability holds even if the coordinator is
fully malicious. Or do you have this because it's required for
"Identifiable aborts", i.e., the ability to identify misbehaving
participants? (Here honest participants need to rely on what the
coordinators claimed were the messages of the other participants.)

The way I see it is that it's already true that any malicious
participant can perform a DoS attack on signing run by not responding,
so I think protection against DoS is anyway out of scope? (And as you
say further below, robustness is not a goal.) So I suggest to clarify
that the coordinator must be trusted to identify misbehaving
participants correctly but assuming honest-but-curious is not necessary
for unforgeability.

> the scheme remains secure against Existential Unforgeability Under
Chosen Message Attack (EUF-CMA) attacks, as defined in [BonehShoup],
Definition 13.2.

I think a reference to a "single-singer" EUF-CMA definition is plain
wrong for a threshold signature scheme. What would the definition even
mean in this setting?

> However, in the setting that a player attempts to split the view of
all other players by sending disjoint values to a subset of players,
the signing operation will output an invalid signature. To avoid this
denial of service, implementations may wish to define a mechanism where
messages are authenticated, so that cheating players can be identified
and excluded.

Identifying and excluding cheating players would require additional
measures, e.g., you'll need terminating reliable broadcast
(=consensus), and not just authentication, in order to agree who is
malicious and should be excluded. Or alternatively, you'd need
something like ROAST to get robustness. But I think that all of this is
too subtle to capture in one or two sentences. Since you anyway say
that robustness is not a goal, I suggest to drop this remark and leave
robustness out of scope.

> One possible example is to construct this pre-hash over message m as
H(contextString \|\| "pre-hash" \|\| m).

I don't think that the blackslashes are intended here.

Best,
Tim


On Mon, 2022-11-14 at 11:22 +0300, Stanislav V. Smyshlyaev wrote:
> Dear CFRG participants,
> 
> This message is starting 3 weeks RGLC on draft-irtf-cfrg-frost-
> 11 ("Two-Round Threshold Schnorr Signatures with FROST") that will
> end on December 6th 2022. If you've read the document and think that
> it is ready (or not ready) for publication as an RFC, please send a
> message in reply to this email or directly to CFRG chairs
> ([e-mail]) If you have detailed comments, these would
> also be very helpful at this point.
> 
> Thomas Pornin provided a review of the document on behalf of Crypto
> Review Panel,
> https://mailarchive.ietf.org/arch/msg/crypto-panel/bPyYzwtHlCj00g8YF1tjj-iYP2c/
> 
> Thank you,
> Stanislav, for CFRG chairs
> 
> 
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg