Add replay protection for invocations

[danfinlay]

For any non-idempotent function, the number of invocations is important to proper behavior of the system.

Currently it seems the ocap-ld proposal does not distinguish one invocation from another, leaving it vulnerable to replay attacks.

Two possible solutions to this are as follows:

Invocation counter

Each host of a function could keep track of an invocation counter for each invoker, and each invocation would be required to include an incremented invocation count.

Chained invocations

In a method more like Bitcoin-UTXOs, each invocation could include a hash of the previous invocation, and would only be valid if the invoker either had no previous invocations, or if the previous transaction had already been processed, and none beyond it, ensuring transaction ordering.

Thoughts?

[dlongley]

I agree it's important to protect against replay attacks. There's more than one way to invoke an ocap-ld capability ... and those ways may include their own mitigations. For example, Linked Data Proofs allow nonces and timestamps and so do HTTP signatures. I think the main problem is that the spec hasn't been updated to talk about this issue nor does it provide example invocations using these methods that include these solutions.

An invocation counter could also be implemented using the above invocation methods and should be mentioned as another possibility.

[mikelodder7]

Why not just include a timestamp as a field then check for a limited window like a TTL? Since the data are signed, then the timestamp has tamper protection. The TTL can vary based on the application requirements and doesn't invalidate the proof. For example, messaging could say as long as the time clocks are in-sync then you could say the TTL is 30 seconds. For others, it could be 5 minutes or 1 hour. This means that no counter is needed. You can invalidate the proof based on the TTL which also provides replay protection. If the proof is not recent enough, the proof is invalid. No incrementing counter to track and no need to record previously sent nonces.

So as Dave Longely says, the mitigation can depend on the application but possible solutions should be added to the spec.

On Thu, Aug 8, 2019 at 9:45 AM Dave Longley notifications@github.com wrote:

I agree it's important to protect against replay attacks. There's more than one way to invoke an ocap-ld capability ... and those ways may include their own mitigations. For example, Linked Data Proofs allow nonces and timestamps and so do HTTP signatures. I think the main problem is that the spec hasn't been updated to talk about this issue nor does it provide example invocations using these methods that include these solutions.

An invocation counter could also be implemented using the above invocation methods and should be mentioned as another possibility.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/ocap-ld/issues/26?email_source=notifications&email_token=AAFPINZOIPAQWSPRPXQPIQLQDQ5QPA5CNFSM4IKERUGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD34BIYA#issuecomment-519574624, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFPIN5HSFMNID72MKBALSTQDQ5QPANCNFSM4IKERUGA .

[danfinlay]

Why not just include a timestamp as a field then check for a limited window like a TTL?

Because then replays would still be possible within the TTL window. Imagine a vending machine: Once I've paid, could I withdraw unlimited candy bars for the full 30 second TTL.

I see the ld-signature spec does include options like a nonce in the proof field, which would be incorporated into the signature, so I guess that counts as a consideration, but some concrete examples and ideally tests would be necessary to build a compatible implementation.

[mikelodder7]

That’s easy to mitigate with a nonce but requires you to cache it but can be removed after the TTL. The other option is the application can have a short timeout of 10 seconds and only accepts 1 request/10 seconds.

The point is there are solutions in place to do this without an incremental nonce

---

From: Dan Finlay notifications@github.com Sent: Thursday, August 8, 2019 11:59 AM To: w3c-ccg/ocap-ld Cc: Michael Lodder; Comment Subject: Re: [w3c-ccg/ocap-ld] Add replay protection for invocations (#26)

Why not just include a timestamp as a field then check for a limited window like a TTL?

Because then replays would still be possible within the TTL window. Imagine a vending machine: Once I've paid, could I withdraw unlimited candy bars for the full 30 second TTL.

I see the ld-signaturehttps://w3c-dvcg.github.io/ld-signatures/#linked-data-signature-overview spec does include options like a nonce in the proof field, which would be incorporated into the signature, so I guess that counts as a consideration, but some concrete examples and ideally tests would be necessary to build a compatible implementation.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/w3c-ccg/ocap-ld/issues/26?email_source=notifications&email_token=AAFPIN5R2XVBKJGPENNOGS3QDRNG7A5CNFSM4IKERUGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD34NRIY#issuecomment-519624867, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAFPIN5BJYRXMZGBDNMKI6TQDRNG7ANCNFSM4IKERUGA.