Simplify LSPS5/validator: drop time checks & custom signature storage

[martinsaposnic]

Remove timestamp validation, TimeProvider, SignatureStore trait and its InMemory implementation in favor of a fixed size signature cache. HTTPS already secures delivery, so a small cache is sufficient for basic replay protection.

pub const MAX_RECENT_SIGNATURES: usize = 5; -> I came up with the 5 number limit, not sure if we need more/less. Please comment your opinion on this

This is a planned follow up for the recently merged PR #3662, here is link with the discussion and motivation for this change #3662 (comment)

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[martinsaposnic]

pub const MAX_RECENT_SIGNATURES: usize = 5; -> I came up with the 5 number limit, not sure if we need more/less. Please comment your opinion on this

thoughts? @tnull @TheBlueMatt

[codecov]

Codecov Report

❌ Patch coverage is 88.88889% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.94%. Comparing base (55d8666) to head (dc97b9c).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-liquidity/src/lsps5/msgs.rs	0.00%	1 Missing ⚠️
lightning-liquidity/src/lsps5/validator.rs	94.11%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3961   +/-   ##
=======================================
  Coverage   88.93%   88.94%           
=======================================
  Files         174      174           
  Lines      123880   123835   -45     
  Branches   123880   123835   -45     
=======================================
- Hits       110176   110147   -29     
+ Misses      11251    11240   -11     
+ Partials     2453     2448    -5     

Flag	Coverage Δ
fuzzing	22.61% <0.00%> (-0.01%)	⬇️
tests	88.77% <88.88%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

I'm a fan of this, and the code seems Obviously Correct (tm), but I'll let @tnull chime in in case he thinks there is some attack the more full-featured replay protection fixes.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[tnull]

As discussed elsewhere, concept ACK from my side. I'll actually also see to update the bLIP-55 PR to drop the mention of the timestamp header there.

That said, I'm a bit confused why we have a signature cache at all now? If we think TLS sufficiently protects against replaying packets, what additional protection does the cache give us? Especially, since the cache is of course easily gamed, as any adversary able to intercept and replay messages could now simply intercept 6 different messages and replay them in batches, ensuring that the cache lookup always misses?

[martinsaposnic]

That said, I'm a bit confused why we have a signature cache at all now? If we think TLS sufficiently protects against replaying packets, what additional protection does the cache give us? Especially, since the cache is of course easily gamed, as any adversary able to intercept and replay messages could now simply intercept 6 different messages and replay them in batches, ensuring that the cache lookup always misses?

from what I remember from our convo a few weeks ago, the cache is mainly there to handle "accidental" replays from the LSP, e.g. the connection drops and the LSP doesn’t get the ACK, so it retries even though the notification actually landed. but yeah, I agree we could just drop those extra lines and keep things simpler. @TheBlueMatt what are your thoughts?

[tnull]

Independently from the discussion on whether we need to store signatures at all, this needs a rebase.

[martinsaposnic]

this needs a rebase

done ✅