Once that key is known, it can be impersonated. Regular rotation is a practical mitigation strategy and I like that Sendgrid took it on ahead of the game.
Since they are sending, they can create a new key on the second domain, tell new emails to use it without impacting anything in transit by leaving the old one active until it is changed for rotation.
Yes, if someone steals your private key, you're screwed. Keeping the private key private is, well, a fundamental component of how PKI works.
> Once that key is known ...
You say that like it happens every day. Use long enough keys and you don't have to worry about it.
The general consensus is that (some) 1024-bit keys can be brute-forced -- though the number of attackers capable of this is extremely limited. If your threat model includes the NSA (or anyone, for that matter) cracking your key, the solution is to increase the length of your key.
I agree that rotating your keys is a good idea but it's not like it's something you have to do every day.
That makes it harder to figure out the private key, but once the private key is known you're still open to impersonation. Longer key + rotation mitigates both.
Isn't the likelihood of brute forcing the private key the same as it would be for an SSL certificate? At 2048 bits, brute forcing the private key is effectively impossible. Which leaves the avenues of attack the same for any private key: information breach through various other means.
I'm just spit balling here so hopefully someone will correct me if I'm wrong but...
With SSL the key exchange happens because you are trying to connect to a specific IP address with an encrypted connection. The cert is issued for the domain you say you're trying to access, vouched for down the certificate chain by certificate authorities that your client can check and warn you about. You get to the IP by connecting to a DNS server to get the address. So even if somebody had the key, they've got to get you to visit their IP with it and the second it's discovered that they key has been stolen the CA can revoke it.
With DKIM you have a key without that entire chain of authentication and all it does it give a receiving email server a place to look to see if the message has been changed in transit, with the key. Anybody with that key can send messages claiming to be from your domain and instead of you having to seek them out, they get to send directly to you so the risk is much higher and the only equivalent of having a CA to void the key is key rotation.
That's why DKIM and SPF (with DMARC) work well together because SPF will at least let you specify authorized origin servers...with the downside being that it breaks forwarders when strictly enforced so a lot of people don't like it and opt to rely on DKIM only.
why do you need CA when you control the domain. if somebody can take over your domain you or the reciever has a bigger problem. im not sure what do you get with key rotation that you would not get with using proper length keys.
Once that key is known, it can be impersonated. Regular rotation is a practical mitigation strategy and I like that Sendgrid took it on ahead of the game.
Since they are sending, they can create a new key on the second domain, tell new emails to use it without impacting anything in transit by leaving the old one active until it is changed for rotation.