Replies inline. On 7/10/20 7:50 PM, Brian Toresdahl wrote: > Your approach and goals don't seem to make sense to me.
TL;DR: The customer is always right, and the customer sees DKIM being used regularly to authenticate leaked emails - if old not-in-use keys are public, anyone can sign anything they want, and suddenly you can't authenticate mail with them, at least after-delivery, that is. > 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 > <http://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. Yes, that was my question, thanks :). Sadly, I don't think and hour would work - plenty of time to timestamp the emails in question and suddenly the email is non-reputably signed again. Back to the drawing board, I suppose. > 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. The goal is to actually publish the private key, no need to wait for someone to brute-force it :) > 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] > <mailto:[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] <mailto:[email protected]> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > -- > > Brian Toresdahl > > Product Management > > [email protected] <mailto:[email protected]> > > > _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
