On Sun 17/Mar/2019 02:24:06 +0100 David L Neil wrote:
>
>> 4 deploy at appropriate times-of-day
>> Check what is the highest TTL among your servers, and schedule a longer
>> interval between key publication and private key deployment. There is
>> nothing wrong in having new public keys collecting mold on the DNS for as
>> long as needed, before private keys are deployed.
>
> I was wondering how long to hold Postfix's outbound queue/SMTP, to allow for
> transmissions using 'the old', before posting 'the new'.
>
> This advice seems to suggest leaving 'the old' up, for 'however-long' *after*
> installing 'the new'. Do I take it that you always change the DKIM selector
> along with the new keys? (common advice is to include a date-component) That
> such practice is only possible if one also changes the selector?
I never automated new key generation for DKIM. Every now and then, when I come
to think about it, I do one of the two things: I either generate a new key and
publish the public part, or enable the selector of the private key I generated
the previous time. That happens months apart.
As of now, I never deleted an old key from the DNS.
The reason I'm so relaxed is that I never heard about DKIM crypto attacks,
except for Google short keys in 2012[*], which wasn't malicious. Attacks can
be detected by DMARC aggregate record inspection.
[*]
https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Short_key_vulnerability
Best
Ale
--
Received on Mon Mar 18 2019 - 17:48:38 PST