search

WebOfTrust / keria

KERI Agent in the cloud
https://keria.readthedocs.io/en/latest/
Apache License 2.0
18 stars 28 forks source link

Encryption in the KERIA Signify API (and lack of signatures in places currently) #287

Open iFergal opened 2 weeks ago

iFergal commented 2 weeks ago

Right now our usage of RFC-9421 has some problems:

Generally the body from Signify to KERIA is something that's already signed like an inception event, but I don't think there's anything signing response bodies from KERIA for the likes of e.g. notification arrays etc.

Another general issue is none of this is encrypted, except for if we use TLS. Ideally, we could use something like ESSR here.

Phil has mentioned to me that 1Password uses JWE tokens (so encrypted) in request bodies. We could do something similar except I would argue for full confidentiality and privacy (without relying on TLS) that all the information must be contained in the body. (so one single path for all requests, more like kapi routing)

--

I haven't fully thought about this but would like to kick off a general discussion. At minimum those extra items need to be signed and rely on TLS for encryption but long term I think we should do better than TLS.

dhh1128 commented 2 weeks ago

tagging @da-tychinin, who has worked on this and has some opinions; also @rodolfomiranda

rodolfomiranda commented 2 weeks ago

Additionally, on the verification side I think that we need to validate the timestamp to prevent replay attacks.

iFergal commented 1 week ago

Need to do some investigation but some cases may already be protected from replay attacks if KERIA does nothing with a request containing the same SAID. Might be wrong.

May be also better in general to work towards something like that, as a timestamp only protects against replay attacks outside of the accepted timestamp window and not within. Good to have both though as a timestamp check is fast so would help with DDoS protection too.

rodolfomiranda commented 1 week ago

Ideally, we should check that the timestamp is within a window, but also that is greater than the previous timestamp received for the same call.

iFergal commented 1 week ago

Right but that would require storing or caching the timestamps of previous calls, where it might be cleaner if our endpoints were designed to just be idempotent based on the SAID of the Signify request.

And the timestamp window could help as a quick sanity check for DoS reasons

iFergal commented 4 days ago

From today's call: discussed how we could completely migrate to just having ESSR payloads in the body (with the unencrypted ESSR payload in the headers for load balancers). KERIA and Signify would effectively just use 1 endpoint then and do routing (like agent to agent messages) instead of REST. Phil suggested you could even completely remove HTTP and only have a tcp handler for the messages.

This would be a complete overhaul of the API but would be needed when we want to stop using TLS as a crutch. I'd be happy to drive this when I've more time, but for now it's lower on my priority list. I just wanted to open the discussion now so I'd have an idea going forward, especially if there are more implementations of Signify (we're interested in Java down the line as many of our services are in Java).