Your approach and goals don't seem to make sense to me. DKIM works (I'm summarizing a lot) by signing mail, and the public key to check that signature is placed in a "selector" record in DNS (selector1._ domainkeys.example.com). If you want to rotate DKIM keys, you can immediately start signing new mail with with another selector (selector2._...), keeping the selector1 around long enough for the old mail to be delivered and checked. Are you asking how long selector1 needs to stay around? For some sort of 95th percentile, probably less that an hour. But this seems excessive. The time time to brute force a 1024 key is in the years (someone correct me), so to get faster an adversary has to get inside your systems and steal your private keys directly, and this conversation is then a moot point.
But realistically, most folks in practice don't rotate selectors often. Anecdotally, I remember a certain John L. rotating them every month, and that's the most frequently I've heard personally. When I managed this for Amazon SES, I think the policy was 6 months or a year. On Fri, Jul 10, 2020 at 4:39 PM Matt Corallo via mailop <[email protected]> wrote: > For various reasons, DKIM's non-repudiation property has always prevented > us deploying DKIM signing on our mail. The > obvious fix for this is to roll DKIM keys aggressively (eg every few > minutes) and publish the private keys for revoked > keys as you go. Given relay times for mail through various hosts, how > aggressive could one theoretically get without > having keys time out before mail is verified (ie how long must DKIM keys > remain valid after mail has been signed by them?). > > Separately, is there any work towards making DKIM support non-RSA keys? > Sure, one could always just generate a fresh key > every minute and publish all old ones, but ECC would be nice as it would > allow simpler hash-based key revocation where > you can reveal every previous key with just one key. > > Thanks, > Matt > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- Brian Toresdahl Product Management [email protected] <[email protected]>
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
