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

Hi chairs and FROST authors,

I am new to FROST and threshold signatures in general. I read the draft to
assess whether I understand the construction and its security goals and
whether sufficient detail is given to make it implementable. The current
draft checks all of these boxes and I think it's ready for publication.
Detailed comments follow.

Thank you for the hard work, this looks to me to be a great product of the
CFRG!
Chris P.

Section 1: "For select ciphersuites, the signatures produced by this draft
are compatible with [RFC8032]." Compatible in what sense? Can a signature
be validated by a plain EdDSA verifier? Or do you mean the signatures look
the same on the wire? I'd clarify this in the introduction.

Section 3.2: nit: "FROST requires the use of a cryptographically secure
hash function, generically written as H, which functions effectively as a
random oracle." I would reword this as "... secure hash function, ...,
which is modeled as a random oracle in current security proofs."

Section 5:

   -  "Two-Round FROST Signing Protocol": Throughout the draft you refer to
   the protocol as a variant of FROST. As an implementer, I think I would find
   it helpful if the protocol had a distinguished name. Something like
   "FROST2"? Alternatively, you could call your protocol "FROST" and say that
   it is a variant  of the protocol proposed in [FROST20].
   - editorial: "FROST assumes that the Coordinator and the set of signer
   participants, are chosen externally to the protocol." Omit the comma.
   - commit() in Section 5.1: I might have called the output "nonce" the
   "ephmeral_secret" or something, to emphasize that it is secret (nonces
   generally aren't) and that it is used only once.
   - Section 5.2: "... and MUST use the nonce to generate at most one
   signature share": I think a MUST NOT would better emphasize the
   requirement: "... MUST NOT use the nonce for more than once".

Section 6:

   - Context strings encode the draft version, e.g.,
   ""FROST-ED25519-SHA512-v11". Do you intend to revise these for RFC?

Section 7:

   - You call out that the coordinator needs to be honest-but-curious.
   Something that's not made clear here --- this might be obvious to those who
   are deeper into threshold signatures than I am --- is whether the
   non-coordinator signers are allowed to act maliciously towards forging a
   signature.
   - Section 7.4: Just, :thumbs_up:. I'm very glad FROST doesn't pre-hash,
   but it's helpful to provide some guidance for those who want to do this.
   One minor nit here: "One possible example is to construct this pre-hash
   over message m as H(contextString \|\| "pre-hash" \|\| m)": Instead of
   "pre-hash", I think we ought to recommend adding context here that
   identifies the higher-level application, e.g., "my protocol" instead of
   "pre-hash".

Editorial: Many of the algorithm specs seem to be too long to fit into the
column limit. Consider wrapping lines so that the reader doesn't have to
scroll.

On Mon, Nov 14, 2022 at 12:22 AM Stanislav V. Smyshlyaev <smyshsv@gmail.com>
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 (
> cfrg-chairs@ietf.org) 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
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>