Incorporate feedback from Sophie Schmieg

Author: emlun

draft-lundberg-cose-two-party-signing-algs.md

@@ -67,6 +67,21 @@ normative:
     title: "SEC 1: Elliptic Curve Cryptography"
 
 informative:
+  FALCON:
+    target: https://falcon-sign.info/
+    title: 'FALCON: Fast-Fourier Lattice-based Compact Signatures over NTRU'
+    author:
+    - fullname: Pierre-Alain Fouque
+    - fullname: Jeffrey Hoffstein
+    - fullname: Paul Kirchner
+    - fullname: Vadim Lyubashevsky
+    - fullname: Thomas Pornin
+    - fullname: Thomas Prest
+    - fullname: Thomas Ricosset
+    - fullname: Gregor Seiler
+    - fullname: William Whyte
+    - fullname: Zhenfei Zhang
+    date: 2017
   FIPS-201:
     target: https://doi.org/10.6028/NIST.SP.800-73pt2-5
     title: 'Interfaces for Personal Identity Verification: Part 2 – PIV Card Application Card Command Interface'
@@ -170,7 +185,8 @@ PKCS #11 [PKCS11-Spec-v3.1], and PIV [FIPS-201].
 Since different signature algorithms digest the message in different ways
 and at different stages of the algorithm,
 it is not possible for a cryptographic API to specify that, for example, "the hash digest is computed by the caller"
-generically for all algorithms. Moreover, different algorithms can have different security considerations when split in this way.
+generically for all algorithms.
+Security considerations for this split may also differ between algorithms.
 Instead, the algorithm identifiers defined in this specification
 enable the parties of that cryptographic API to signal precisely, for each signature algorithm individually,
 which steps of the algorithm are performed by which party.
@@ -188,10 +204,13 @@ Some signature algorithms,
 such as PureEdDSA [RFC8032],
 by their design, cannot be split in this way, and therefore cannot be assigned split signing algorithm identifiers.
 However, if such a signature algorithm defines a "pre-hashed" variant,
-such as Ed25519ph [RFC8032],
 that "pre-hashed" algorithm can be assigned a split signing algorithm identifier,
 enabling the pre-hashing step to be performed by the _digester_
-and the remaining steps by the _signer_. Note however that Ed25519ph is not compatible with PureEd25519 for the verifier, so requires a different algorithm identifier.
+and the remaining steps by the _signer_.
+For example, this specification defines Ed25519ph-split ({{eddsa-split}}) as a split variant of Ed25519ph [RFC8032].
+Note that Ed25519 and Ed25519ph have distinct verification algorithms,
+but Ed25519ph and Ed25519ph-split use the same verification algorithm.
+
 
 ## Requirements Notation and Conventions
 
@@ -298,7 +317,6 @@ COSE_Sign_Args = {
 }
 ~~~
 
-COMMENT(sschmieg): For ML-DSA, we have external-µ, which is again a different API in the sense that the digester needs to be aware of the public key. We also have a context argument, but the signer does not need to learn it. 
 
 ## COSE Signing Arguments Common Parameters {#cose-sign-args-common}
 
@@ -343,14 +361,25 @@ and a key derived using `ARKG-P256` [I-D.bradleylundberg-ARKG]:
 
 This specification assumes that both the _digester_ and _signer_ roles
 described in {{split-algs}} are trusted and cooperate honestly.
-This is because these split signing procedures concern details
-that are considered implementation details from a verifier's perspective.
+This is because a similar division between "application" and "secure element"
+typically exists already:
+even if all steps of the signing algorithm are executed in a trusted secure element,
+the inputs to the secure element are provided by some outside component such as a software application.
+If the application can provide any input to be signed,
+then for all practical purposes it is trusted with possession of any private keys
+for as long as it is authorized to exercise the secure element.
+The application can in practice obtain a signature over any chosen message
+without needing to perform a forgery attack.
+The same relationship exists between _digester_ and _signer_.
+Applications that cannot trust an external _digester_ -
+for example a hardware security device with an integrated secure display of what data is about to be signed -
+by definition have no use for split signing algorithm identifiers.
+
+Similarly from a verifier's perspective,
+these split signing procedures are implementation details.
 When a signature is generated by a single party,
 that single party takes on both the _digester_ and the _signer_ roles,
 and obviously trusts itself to perform the _digester_ role honestly.
-This assumption is carried forward for the split signing use case:
-the _digester_ is assumed trusted,
-since it is part of the overall procedure of generating a signature over some input data.
 From the verifier's perspective,
 a malicious _digester_ in the split signing model would have the same powers
 as a malicious signature generator in a single-party signing model.
@@ -364,26 +393,26 @@ The reasoning in {{sec-cons-trusted-roles-protocol}} does not hold on the compon
 A _signer_ implementation MUST NOT assume that the _digester_ implementation
 it interoperates with is necessarily honest.
 Split signing algorithms MUST NOT be defined in a way
-that enables a malicious _digester_ with access to an honest _signer_
-to produce forgeries or extract secrets from the _signer_.
+that enables a malicious _digester_ with access to an honest _signer_ to produce forgeries -
+any that could not be produced by simply requesting a signature over the desired message -
+or extract secrets from the _signer_.
 
 For example, for ECDSA ({{ecdsa-split}}), a malicious _digester_ can choose _H_
 in such a way that the _signer_ will derive any _digester_-chosen value of _e_,
 including zero or other potentially problematic values.
 Fortunately, in this case, this does not enable the _digester_ to extract the signature nonce or private key.
-It also does not enable forgeries,
+It also does not make forgeries easier,
 since the _digester_ still needs to find a preimage of _e_ for the relevant hash function.
 Definitions of other algorithms need to ensure that similar chosen-input attacks
 do not enable extracting secrets or forging protocol-level messages.
 
-COMMENT(sschmieg): Forgeries are *probably* okay: There is a relatively trivial forgery attack against prehashed RSA and we all seem to be fine with it.
-                   In particular, if the digester wants to forge a signature for m, they compute h(m) (including padding), find to integers a, b such that a * b = h(m) mod n, and have the signer sign both a and b, i.e.
-                   compute a^d and b^d. Since exponentiation is multiplicative, the digester can now compute h(m)^d, a valid signature of m, without ever having asked the signer to sign h(m).
-                   The reason we are usually okay with that issue is that the digester already can ask the signer for any signature they want.
-                   Key compromise attacks on the other hand have to be avoided. A naively prehashed version of Falcon would allow such a key compromise: A Falcon signature is a value s such that both s and s * h - hash(r || m) are short.
-                   (h is the public key and r a randomizer). If the digester gets to query the signer for signatures of arbitrary stand-ins for hash(r || m), they can extract the private key by for example asking for repeated signatures of 0.
-                   The basic construction of Falcon and RSA is the same (they are both hash-then-sign algorithms), but where leaving the hash to an external party only gives forgery attacks in RSA, it can give key compromise attacks.
-                   Essentially, a split algorithm needs to be reviewed and potentially have its security proofs adjusted.
+For example, a naively prehashed version of FALCON [FALCON] would allow such a key compromise:
+A FALCON signature is a value `s` such that both `s` and `s * h - hash(r || m)` are short,
+where `h` is the public key and `r` a randomizer.
+If the digester gets to query the signer for signatures of arbitrary stand-ins for `hash(r || m)`,
+they can extract the private key by for example asking for repeated signatures of 0.
+Therefore, definitions of split signing algorithms need to be reviewed and potentially have security proofs adjusted.
+
 
 # IANA Considerations {#IANA}
 
@@ -517,9 +546,27 @@ the Internet-Draft of ARKG [I-D.bradleylundberg-ARKG] extends this specification
 
 --- back
 
+# Acknowledgements
+{: numbered="false"}
+
+We would like to thank
+Ilari Liusvaara,
+Sophie Schmieg
+and
+Falko Strenzke
+for their reviews of and contributions to this specification.
+
+
 # Document History
 {: numbered="false"}
 
+-05
+
+* Clarified in introduction that Ed25519 and Ed25519ph(-split) have distinct verification algorithms.
+* Clarified in section "Protocol-Level Trusted Roles" why digester is necessarily trusted.
+* Clarified in section "Component-Level Trusted Roles" that redundant forgeries are acceptable,
+  and added example of key compromise concern for naively hashed FALCON.
+
 -04
 
 * Added Implementation Status section.