On Sat, 2004-09-18 at 09:58 -0700, Jim Fenton wrote:
So if one _is_ harvested, it has to be a recent one for it to matter.
Sure; I glossed over that detail. You would keep a couple of
addresses that are valid for bounces, and then rotate them (maybe
every 4 days or so). I'm guessing that this is close to what you're
already doing.
Close enough. I use one address per day and don't actually bother with
rotation. I used to have more -- I used to have a more precise timestamp
in the domain part. But that interacted badly with some greylisting
implementations -- because I generated the SES reverse-path at
_delivery_ time, it was different each time. So it got greylisted anew
each time :)
So my question is: Beyond this technique, does the crypto piece add
enough additional value to be worth the trouble of key management,
etc.?
The trouble of key management? There's not really any trouble. The key
was generated when the configuration was rolled out, and it's been there
ever since. You can see that there's a way to temporarily accept bounces
with one of _two_ keys, but the need to _change_ keys has been purely
academic so far.
The only time it would be any _trouble_ is if you wanted to change keys.
And presumably you'd only ever want to change keys is if someone had got
your key somehow and was maliciously using it in forged messages. And in
that case presumably the crypto part _is_ worth it, because if they
wanted to do that _without_ the hash in the reverse-path, it would have
been trivial.
So either it's absolutely no hassle, or it's worth having. I don't see
much middle ground. Either way I'd say yes, the crypto _does_ add enough
additional value to be worth the trouble.
Others have talked about the possibility of rotating keys so that
they're not in use for long enough to be cracked. I think that's
overkill.
A trivial hash on the address costs almost nothing in terms of
management, and seems to foil the most obvious of forgeries by making
sure the attacker at least has to have something you sent in the first
place. But I suppose I'm not saying that from the point of view of a
cryptographic expert.
There was the idea of having BATV include the signature from some
other signature scheme (DK, IIM, etc.) in order to limit the replay
attack, and this warrants further thought.
I'm still ambivalent about it. It limits the replay attack only to those
recipients who _check_ it. And to a large extent those recipients will
be the same people who would be checking the RFC2822 scheme _anyway_ and
hence wouldn't actually get any extra benefit from it.
But using a signature present in a BATV reverse-path in lieu of public-
key crypto perhaps merits further investigation.
--
dwmw2