В Документ о передовых методах ротации ключей M³WAAG DKIM (pdf) рекомендует «достаточно» случайное имя селектора DKIM, чтобы его нельзя было угадать при просмотре DNS. Буквальная цитата:
4.3 Схема именования селектора клавиш
Определите схему именования для селекторов ключей DKIM, которая имеет значение для судебного анализа и является достаточно случайной, чтобы ключи нельзя было легко угадать, просматривая DNS.
ПРИМЕЧАНИЕ. Схема именования селекторов также должна быть разработана таким образом, чтобы снизить риск того, что злоумышленники могут легко предсказать имена будущих селекторов и получить связанные ключи. См. Раздел 5 для описания процесса публикации ключей для будущего использования.
Это может быть актуально для коротких 512-битных ключей RSA, но для меня не имеет смысла использовать более длинные, скажем, 2048-битные ключи RSA. DNS хранит открытые ключи, которые не являются секретными, и их можно обнаружить, прочитав только одно подписанное письмо. Безопасность неизвестностью с очень небольшой защитой?
Почему случайное имя селектора DKIM было бы лучше, когда имело бы смысл следовать их рекомендациям?
Я просмотрел документ и обнаружил, что автор (ы) не понимает распространения новых записей DNS. При обновлении старых записей можно настроить время кеширования, которое может составлять несколько дней. Однако новые записи должны быть получены с официальных серверов имен, прежде чем их можно будет кэшировать.
Если ключи меняются с помощью предлагаемого процесса смены ключей за тремя CNAME, могут возникнуть значительные задержки при обновлении кэшированных записей. Это можно смягчить, отказавшись от записи TTL для обновления в период, предшествующий обновлению. Вращение CNAME также может быть проблематичным в случае необходимости экстренной смены ключа.
Рандомизация имен ключей обеспечивает некоторую небольшую степень защиты от открытого ключа, извлекаемого перед использованием. Как только ключ используется, я предполагаю, что он мог быть собран с целью генерации альтернативного ключа подписи.
Два преимущества:
Кажется, это всего лишь (несколько слабый) дополнительный уровень защиты.
Текущая версия (март 2019) руководящих принципов только один раз упоминает случайные имена для селекторов на изображении. Цитата из обзора изменений:
Предлагаемое соглашение об именах ключей было переработано (раздел 5.1.3).
Раздел 4.2:
Соглашение об именах с использованием дат ротации может помочь упорядочить селекторы.
Примером может быть: «sales-201309-1024». Этот пример указывает на то, что он принадлежит к потоку электронной почты «продажи», предназначен для перехода на действительную службу в сентябре 2013 года и ссылается на 1024-битный ключ.
Изображение в Разделе 5.1 гласит на стикере:
селектор может содержать длину ключа, дату, случайную строку
В разделе 5.1.1 говорится:
... Этот селектор должен содержать достаточно информации, чтобы облегчить процесс ротации ключей.