4

Referencing this: https://crypto.stackexchange.com/questions/72297/recommended-key-size-for-dkim

What I get from this is (at the time) DNS providers (usually) allow for up to 1024 bit keys but not 2048 bit. Now, my provider does let me use 2048 and confirmed DKIM signs. Of course, the post claims 1024 is perfectly safe, but if I have the option to use 2048 I'd like to.

Am I good to go, so long as my provider supports that big of a TXT record? Or could there still be issues?

Tyler Montney
  • 191
  • 8
  • 1
    A relevant RFC to consider is [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301#section-3.2). – glts Oct 15 '21 at 17:33
  • True; however, a quick Google search reveals many DNS providers that have a 255 character limit (requiring record chaining). My provider has the option to "add more data" (can't add a duplicate record). Unfortunately, mxtoolbox can no longer verify it. – Tyler Montney Oct 15 '21 at 18:00

1 Answers1

2

This depends on your use case. The stated purpose of DKIM is to verify the authenticity of the message. If this is the case, it is generally accepted to use 2048-bit RSA keys. The DNS server consideration is for your authoritative nameserver, so if that accepts entering records longer than 255 characters, the only consideration is receiving servers that can accept the mult-string record and support 2048-bit.

If, for some reason, there are receiving servers that cannot read the record or support larger than 1024-bit, then you could create new DKIM keys with associated new selector, as often as desired, say every day, making the probability of a key being compromised very low, since the message is usually authenticated within seconds of receipt.

There is also the option of Ed25519 keys, but this is not yet broadly supported by receiving servers.

If your use case is proof of work for passing various antispam tests, you probably could get away with 1024-bit if 2048-bit is causing problems. There are still large companies using 1024-bit, notably Substack and I know I've seen others.

Last but not least, the DKIM standard supports multiple signature headers, so depending on server overhead you could sign using multiple signatures and the receiving server can choose which signature to authenticate against.

Paul
  • 2,755
  • 6
  • 24
  • 35
  • Use case is to sign messages on my mail server and passing antispam tests. However, I'd rather use a more secure key. I assume by "the only consideration is receiving servers that can accept the mult-string record and support 2048-bit. If, for some reason, there are receiving servers that cannot read the record or support larger than 1024-bit..." that it's unlikely any mail server will run into this (especially since the record is not multi-string)? – Tyler Montney Nov 18 '21 at 00:54
  • I mean on the DNS side of things. The 2048-bit record has to be multi string due to the 255 octet ("character") limit built into DNS. If a mail server cannot read such a record, then the DKIM signature cannot be authenticated. – Paul Nov 18 '21 at 02:03
  • Ah, so my provider may just be hiding that from me and making it look like one record. Well, I think I'll go for 2048 and see how many messages bounce. – Tyler Montney Nov 18 '21 at 04:01
  • You can see what the record looks like when retrieved with `dig +short txt s1._domainkey.stackoverflow.com`. There aren't many servers these days that can't authenticate 2048-bit, but the ones you do find won't be able to read the DKIM signature, so it should not be an authentication failure. – Paul Nov 18 '21 at 12:53