thx! Shana Bagherian, MBA MCSE CISSP
Sent from my iPad Please excuse the brevity, typos (auto-correct is disabled because it never recognizes IT lingo!), and lack of capitalization (is it really necessary? unlike punctuation which is needed) Shana Bagherian CISSP, MBA, MCSE Senior Infrastructure/Security Architect, Triden Group "Where Security Protects Innovation" 9823 Pacific Heights Blvd Suite H, San Diego, CA 92121 [email protected] www.tridengroup.com On Aug 11, 2020, at 3:25 PM, Jon Callas <[email protected]> wrote: ** WARNING: This email originated outside of Triden Group. Do not click links or open attachments unless you recognize the sender and know the content is safe. ** On Aug 6, 2020, at 3:42 PM, Shana Bagherian <[email protected]> wrote: I was looking over rfc 4871 and emailed Eric who suggested I ask the question of you all on this DL. So, I was wondering if any of the RCSs related to DKIM list a best practice, or if some other authority has given a best practice, regarding how often the keys should be changed? It seems that best practice is every 6 months, but it would be nice for an authority to state so. Of course, an acceptable answer is ‘it depends’ upon the security needs to the organization, but is if that is the answer – it depends – is there a minimum time frame for generating new keys? I apologize for being late to this party. As another of the authors of 4871 -- and one who is known to have opinions on key lifetimes -- I feel I should chime in. DKIM protects an email in transit. Once it's been delivered, the key/signature's job is complete. Typically, this is a matter of seconds or minutes. If retries are needed, most servers stop after four or five days. If we wave our hands and say two weeks, that would cover nearly everything. Moreover, if a DKIM key vanishes, then the receiver is supposed to process it like it would without DKIM, and typically that is that the content-based spam filtering would kick in. Thus, there's no real need to keep one around for two weeks, and if you then made it be thirty days, it's utter overkill. If I were building an infrastructure for DKIM, my first approximation would be that there would be a key per day. I'd have a job make sure that there's a key for seven days in the future and delete keys older than 14 days ago. I'd see what my stakeholders said. I would object to keeping them around longer than fourteen days, but would only argue a little bit about thirty days. I'd be adamant it would not be longer than sixty. As Mark Delany pointed out, the Web PKI people are replacing keys for TLS every ninety days, and there's utterly no reason for longer than that. As Dave Crocker points out, DKIM is not data at rest and so it doesn't need anything fancy. Summarizing, some job should make sure there are keys for seven days in the future, N days in the past, with 14 being a really good value of N, 30 being meh, and anything longer than 60 utterly overkill. An alternate strategy would be a Key Of The Month, and do one month ahead and one behind. Lastly, I'm a huge fan of Michael Specter's paper, and would love it if someone implemented that -- it's a better solution to key retirement for DKIM than gonzo things I've suggested. It's also not germane to your issue. Jon NOTICE: This e-mail message including any attachments of any type are covered by the Electronic Communications Privacy Act, is confidential and may include legally protected information. If you are not the intended recipient or you have received this e-mail message by mistake. Please notify the sender you have received this e-mail by mistake and delete all information contained in and attached to this email.
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
