feat: add replay attack rfc

[stringhandler]

Description

Adds an RFC about a possible replay attack concerning signatures on the second layer

[CjS77]

Pretty much agree with the proposed solution. An additional safeguard is to add an expiry time to the signature, so that it expires after, say , 6 hours.

[CjS77]

I believe that in general there is a responsibility on developers to implement replay protection on "bundled" signatures. I'm not sure whether there is a general, automatic, solution.

Possibly the best approach would be to document some failsafe pattern/patterns.

e.g. A "redeem" package comprises:

• A signature
• A use-once token, linked to the signature, the resource to be claimed, and the resource destination (if applicable).

Redeeming entails burning the use-once token after it has been validated. Replays are voided because the signature no longer exists. A signature can be checked multiple times before (or after) redeeming, but the redemption can only be done once.

We could even produce an easy-to-use API for making use of this pattern, but of course, we could not force users to implement naiive signature solutions.

[AaronFeickert]

The only surefire solution I know of is ensuring correct context binding on the signatures, but this is tricky in general. Maybe the best way to encourage this, aside from providing safe APIs for common use cases, is to include careful documentation that explains the role of context binding.

One approach could be describing context binding in terms of malleability: for a signature whose verification is directly used to authorize an action, what aspects of that action must not be allowed to be changed? For a simple transaction model, this might (at a minimum) include things like fee amounts, destination addresses and amounts, and the like. Those things must be bound to the signature safely to avoid replay or other malleability-related attacks.