spring-83
spring-83 copied to clipboard
robinsloan
DELETE key handling
So I started hacking on an Elixir implementation and discovered that the demo implementation at bogbody.biz is slightly out of conformance with the current spec.
curl -X OPTIONS https://bogbody.biz -i | grep access-control-allow-methods
produces
access-control-allow-methods: DELETE, GET, PUT, OPTIONS
Whereas the current spec lists just GET, PUT, and OPTIONS.
I think the spec here is probably wrong! And servers can/should handle a DELETE method for boards. I remember reading something somewhere about this behavior but now I can't find it in either the RFC itself or the narrative description of the protocol so maybe I'm hallucinating.
Anyway would be happy to draft something about DELETE behavior as a PR later this weekend.
Good catch! I'm remembering now that I got stuck because I couldn't decide how a publisher ought to authenticate a DELETE request, since there's no body to sign. That endpoint on bogbody.biz was, therefore, unauthenticated 😱 -- so, thank you for the alert!
I think the answer is probably to have a publisher sign the string DELETE with their secret key, submitting that as the signature. That works fine, but feels… slightly cruddy/arbitrary? Is cruddy/arbitrary okay?
Update: I did a bit more thinking about this & arrived at a solution that I think will work. I'll wrap it into the next version of the specification.
Just saw this and was thinking about it a bit, @robinsloan you may have already realized this but there needs to be a changing element in the data signed for DELETE, as otherwise the resulting signature is always the same. Meaning an attacker who manages to capture the DELETE signature once for a given keypair has the ability to delete it in perpetuity. Simply appending a time string (with high precision, so at least milliseconds) to the string DELETE should do the trick (I think).
@rpj Yes! I realized the same thing. Thanks for mentioning this. The version I have in my new draft spec is very similar to a PUT request, with the same <time> element requirement, except with a very narrow window of acceptable timestamps, so the request can't be cached and replayed.
@robinsloan Oh excellent, I hadn't even thought of the replay attack vector! Fantastic, this is enough to start hacking the implementation together too, thanks a ton for the preview 🙇
I'm totally cool with cruddy/arbitrary, for the record. 😅 I'll need to work on this a little bit more to fully grok the implications of the current proposal but it seems reasonable so far.
Is the intent for this to be a mechanism for keyholders and only keyholders to delete their own boards?
Is the intent for this to be a mechanism for keyholders and only keyholders to delete their own boards?
Yes, I think that's correct. The best a publisher can do to "close their account", without DELETE, is PUT a blank board and wait for it to expire. I think this extra endpoint is simple enough -- and, I take deletion seriously enough -- that it's worth adding to the specification.