If we add a timestamp to the encrypted token I suggest there should be a pretty broad window allowed (i.e. several months).
I guess it would be a matter of keeping 2 tokens in the database.
In the case we sign/encrypt a tuple of (list, subscriber, timestamp) we don't need to store anything in the database. We just check timestamp against our validity period and remove the subscriber for the list. This is simple, but I agree as discussed later that just having a random opaque UUID that corresponds per subscription-instance in the database provides a lot more flexibility/safety overall.
Option 1: signed/encrypted tuple (list, subscriber, timestamp) Option 2: UUID referencing a unique subscription in the database
Sounds like you are favoring the 2nd option?
I agree with your analysis, but this would be a very specialized attack, especially if we don't provide direct feedback on if the request was successful (which we are not required to do).
I think we do need to provide feedback, at least when the request fails due to an expired token.
RFC 8058 doesn't specify response codes or really any behavior in response to the POST request. The user never sees this interaction.
On the other hand, in Postorius we probably want to support a GET interaction against the same URI which provides a page with a button that generates the equivalent POST. That means that the same URI can be used in a personalized footer as a (two-click) unsubscribe link. In that case, we will want the POST to generate a response that indicates success or failure.
Incidentally, I imagine 8058 defines this as a POST interaction to avoid the mail-scanner issue we talked about last message. Mail scanners may follow links with GET requests, but are unlikely to generate POSTs.
The real risk without a per-subscription random unique identifier would be a replay attack -- the user is unsubscribed multiple times? That feels outside of the threat model.
The identifier has to be unique to the subscription. If there are multiple valid unsubscriptions, the later ones won't have an existing subscription to unsubscribe. That does argue for the nonce -- that would stop the attack in the case where the user resubscribes.
Yes, exactly -- I didn't mean multiple valid subscriptions at the same time, but rather serial subscriptions by the same subscriber (if they are maliciously unsubscribed).
Regardless, not something we can do much about.
There's hope. When Yahoo! and AOL broke the Internet in 2014 by setting p=reject DMARC policies, the Ministry of Education issued "administrative guidance" that *yahoo.* addresses should not be used for school business, and my university sent them all to spam. ;-) Including yahoo.jp which did not have a p=reject policy.
Ah, to be outside the US, where the concept of consumer protections still exists...
--Jered