Home / server / Questions / 577582
In Process
Lekensteyn
Asked: 2014-02-23 06:58:40 +0800 CST

Should DKIM selector names be unguessable?

  • 772

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?

dkim

3 Answers

  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.

    • 1

  2. 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.

    • 1

  3. 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.

    • 0