idnits 2.17.1 draft-irtf-cfrg-frost-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 214 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (8 February 2021) is 1172 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CFRG C. Komlo 3 Internet-Draft University of Waterloo, Zcash Foundation 4 Intended status: Informational I. Goldberg 5 Expires: 12 August 2021 University of Waterloo 6 8 February 2021 8 FROST: Flexible Round-Optimized Schnorr Threshold Signatures 9 draft-irtf-cfrg-frost-00 11 Abstract 13 In this draft, we present FROST, a Flexible Round-Optimized Schnorr 14 Threshold signature scheme that reduces network overhead during 15 signing operations while protecting against forgery attacks 16 applicable to prior similar threshold and multisignature 17 constructions. 19 FROST can be safely used without limiting concurrency of signing 20 operations yet allows for true threshold signing, as only a threshold 21 number of participants are required for signing operations. Here, we 22 define FROST as a two-round protocol, but it can be optimized to a 23 single-round single-round signing protocol as the first round can be 24 performed as a batched pre-processing stage. 26 Discussion Venues 28 This note is to be removed before publishing as an RFC. 30 Discussion of this document takes place on the FROST Working Group 31 mailing list (frost@ietf.org), which is archived at 32 https://mailarchive.ietf.org/arch/browse/frost/. 34 Source for this draft and an issue tracker can be found at 35 https://github.com/chelseakomlo/frost-spec. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 12 August 2021. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction 71 2. Change Log 72 3. Terminology 73 4. Security Considerations 74 5. Basic Assumptions 75 5.1. Selection of participants 76 5.2. Communication channels 77 5.3. Protocol Failures 78 6. Notation 79 7. Cryptographic Dependencies 80 8. Protocol Overview 81 9. FROST Key Generation 82 10. FROST Signing 83 11. References 84 11.1. Normative References 85 11.2. Informative References 86 Acknowledgments 87 Authors' Addresses 89 1. Introduction 91 DISCLAIMER: This is a work-in-progress draft of FROST. 93 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 94 draft is maintained in GitHub. Suggested changes should be submitted 95 as pull requests at https://github.com/chelseakomlo/frost-spec. 96 Instructions are on that page as well. 98 In this draft, we present FROST, a Flexible Round-Optimized Schnorr 99 Threshold signature scheme. FROST reduces network overhead during 100 signing operations by optimizing for efficiency over robustness. 101 FROST uses a novel technique to allow for fully parallelized use 102 while protecting against forgery attacks that are applicable to prior 103 similar threshold and multisignature constructions. 105 FROST achieves its efficiency improvements in part by allowing the 106 signing protocol to abort in the presence of a misbehaving 107 participant (who can be identified and excluded from future signing 108 operations). 110 2. Change Log 112 draft-00 114 * Submitted a basic draft after adoption of draft-komlo-frost as a 115 working group item. 117 3. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 4. Security Considerations 127 In this draft, we specify key generation using a trusted dealer. 129 5. Basic Assumptions 131 We maintain assumptions about how participants are selected as well 132 as responsibilities of the underlying network channel. Further, we 133 do not specify how implementations should handle failures that occur 134 during the execution of FROST key generation or signing operations. 136 5.1. Selection of participants 138 We assume that at the time of key generation, participants have a 139 mechanism to select other participants. 141 5.2. Communication channels 143 We assume that participants communicate over an authenticated and 144 trustworthy channel. Note that during signing, participants can 145 communicate over any channel. We assume that communication failures 146 (dropped messages, etc) are handled externally to the protocol. 148 5.3. Protocol Failures 150 FROST is not robust; in the case of failures, participants must abort 151 the protocol and try again. However, failures may occur due to 152 participant misbehavior. As such, we do not specify what 153 implementations should do in the case of failure after aborting the 154 protocol. 156 6. Notation 158 To be completed 160 7. Cryptographic Dependencies 162 To be completed 164 8. Protocol Overview 166 To be completed 168 9. FROST Key Generation 170 To be completed 172 10. FROST Signing 174 To be completed 176 11. References 178 11.1. Normative References 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, 182 DOI 10.17487/RFC2119, March 1997, 183 . 185 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 186 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 187 May 2017, . 189 11.2. Informative References 191 [frost] Komlo, C. and I. Goldberg, "FROST: Flexible Round- 192 Optimized Schnorr Threshold Signatures", 8 July 2020, 193 . 195 Acknowledgments 197 TODO acknowledge. 199 Authors' Addresses 201 Chelsea Komlo 202 University of Waterloo, Zcash Foundation 204 Email: ckomlo@uwaterloo.ca 206 Ian Goldberg 207 University of Waterloo 209 Email: iang@uwaterloo.ca