8

The M³WAAG DKIM Key Rotation Best Practices document (pdf) recommends a "sufficiently" random DKIM selector name so that it cannot be guessed by browsing the DNS. A literal quotation:

4.3 Key Selector Naming Scheme

Define a naming scheme for the DKIM key selectors that is both meaningful for forensic analysis and is sufficiently random so the keys cannot be easily guessed by browsing the DNS.

NOTE: The selector naming scheme should also be designed to mitigate the risk that attackers can easily predict the names of future selectors and retrieve the associated keys. See Section 5 for a description of the process for publishing keys for future use

This may be relevant for short 512-bit RSA keys, but it does not seem to make sense to me for longer, say 2048-bit, RSA keys. The DNS holds public keys which are not secret and can be discovered by reading just a single signed mail. Security by obscurity with very little security?

Why would a random DKIM selector name be better, when would it make sense to follow their recommendation?

4 Answers 4

1

I reviewed the document and found the author(s) don't understand DNS propogation of new entries. When updating old entries there are configurable cache times that can be several days. However, new entries need to be fetched from the authoritative name servers before the can be cached.

If keys are being rotated by the suggested process of rotating keys behind three CNAMEs, the there may be significant delays while cached entries are updated. This can be mitigated by dropping the TTL on record to be updated in the period before it is updated. The CNAME rotations may also be problematic in the case an emergency key rotation is required.

Randomizing the key names does provide some small measure of protection against the public key being retrieved in advance of use. Once the key is in use, I would assume that it could have been harvested for the purpose of generating an alternate signing key.

4
  • 1
    Caching should not matter (even if it is weeks) given the rotation time. Initially, set key1 + key2 and use key1. When its time to rotate keys, use key2 and set a new key3. Selectors should not be re-used... You mention protection against the public key being retrieved in advance of use, what exact benefit does this bring to an attacker? Consider GPG, those public keys are also public and nobody made a complaint about it.
    – Lekensteyn
    Feb 22, 2014 at 23:51
  • @Lekensteyn When using CNAMES the cached CNAME may point to an old selector record. The CNAME needs to be updated early enough that the old value ages out of caches before the new key is used. If someone gets the public key before it is used, they would have more time to attempt to generate a signing key.
    – BillThor
    Feb 23, 2014 at 2:23
  • If the administrator(s) responsible for the DNS are the same responsible for the DKIM keys and mail infrastucture, no problem. At several large companies I know of this adjusting the TTL of an individual record would require suits in meetings (not a good thing). Feb 23, 2014 at 23:38
  • @quadruplebucky If the request is done right, it should take a meeting of the suites for the first update. This can be extremely difficult for many organizations who don't trust the people doing this kind of thing. If the TTL, can't be changed, the schedule may need to be extended accordingly.
    – BillThor
    Feb 25, 2014 at 0:33
1

The current version(march 2019) of the guidelines only mentions random names for selectors once, on an image. Quoting the changes overview:

The suggested key naming convention was reworked (section 5.1.3)

Section 4.2:

A naming convention using rotation dates can help keep selectors ordered.

An example may be: “sales-201309-1024”. This example indicates that it belongs to the “sales” email stream, is intended to be rotated into active duty in September 2013 and references a 1024-bit key.

The image in Section 5.1 states on a post-it note:

selector may contain key length, date, random string

Section 5.1.1 states:

...This selector should carry enough information to facilitate the key rotation process.

0

Two benefits:

  1. attacker would not be able to begin an attack without discovering selector name (posession of a signed message, typically)
  2. you can publish the key and ensure propagation into DNS before it's actually rotated into use with minimum risk of reducing the key's effective lifetime.

Just a (somewhat weak) extra layer of protection it seems.

4
  • 1
    (1) What kind of attack are you referring to? Finding the private key matching the public key? 2048-bit RSA is considered uncrackable with current technologies. (2) Cached DNS failures can be migitated by publishing keys some weeks in advance, this can still happen even if the selector names are known. I am not convinced.
    – Lekensteyn
    Feb 22, 2014 at 20:51
  • I think those suggestions are overly cautious, I'm not trying to convince you of anything. BTW 2048 bit keys exceed the max length of a txt field (RFC 1035) and have problems in some DKIM implementations. Feb 23, 2014 at 3:38
  • What are the known DKIM implementations having issues? Google uses 2048-bit keys everywhere, I consider it a good trade-off in favor of stronger keys.
    – Lekensteyn
    Feb 23, 2014 at 14:37
  • 1
    @Lekensteyn Some DNS services won't allow 2048 keys because containing the required text exceeds the maximum allowed DNS record length. Just few days ago (Dec 2015) I experienced this issue configuring a domain on a fairly large French VPS / DNS provider called OVH. Dec 23, 2015 at 9:45
0

That's bad advice in 2023. Might have been somewhat valid in 2014/2015, but not any more. It's possible to autodetect selector names now, so using obscurity on them is useless and will just make your life as an admin more difficult.

Besides that, when DKIM is implemented, we really don't care if someone has access to the key that is published in DNS. It's a public key in a key pair. The private key is used to encrypt a hash value for the email content, and the public key decrypts it. The recipient compares the received hash with one it calculates for the message. If the two match, DKIM validation succeeds.

The important part of DKIM validation is access to the private key used to encrypt the hash value, and that isn't publicly available. The only thing that is encrypted is a hash value, which anyone who has access to the email can duplicate. Since only the private key can successfully encrypt a message that can be decrypted with the public key, the encrypted signature package that contains the hash value can only come from someone who has access to the private key. If someone is able to decrypt and read that package, the only thing they can do with it is verify the source. So access to the key that decrypts the signature gives an attacker absolutely nothing useful.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .