On 3/18/19 10:48 AM, Alessandro Vesely wrote:
> 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
>
I generate new DKIM once a year. That's why if you look at the DKIM key
I use it always has the year as part of the record owner.
DKIM isn't intended to authenticate old mail, there is no reason to keep
the old keys in DNS for more than week when you generate a new one.
Crypto that doesn't exppire seems to encourage laziness in admins, I
wish that wasn't the case but it seems to be.
Received on Mon Mar 18 2019 - 18:34:47 PST