Технология в деталях №4, октябрь 2016

Замена в корневой зоне

Фото аватара
Джефф Хьюстон
Джефф Хьюстон

В октябре 2017 года в корневой зоне DNS произойдет важнейшее событие со времени ее подписания в июле 2010 года. Ключ KSK, который служит для удостоверения всех остальных ключей, будет обновлен. Периодическое обновление ключей - нормальная практика, но KSK - ключ особенный и процесс обновления нетривиален. Каков процесс замены ключа, как подготовиться к этому событию и в чем заключаются риски - рассказывает эта статья.

В мире шифрования с открытым ключом часто отмечается, что соответствующий секретный ключ не может навсегда оставаться в секрете. Это не означает, что секретный ключ может держаться в секрете только в течение ограниченного периода времени, а затем лежащая в основе криптография самопроизвольно разрушится и ключ неизбежно раскроет себя! Однако существуют эволюционные факторы, которые стремятся подорвать целостность личного ключа по прошествии длительного времени. Чем больше ключ используется для шифрования продуктов, тем больше информации, указывающей на его секретное значение, становится доступной. Конечно, эти улики являются бесконечно малыми по значению и большинство видов использования секретного ключа, даже сравнительно интенсивного, не дают злоумышленнику преимуществ при его взломе, однако в абсолютном выражении риск остается. В то же самое время, продолжающийся рост вычислительной мощности позволяет легче решать вычислительные проблемы, ранее считавшиеся чрезмерно трудными, поэтому старые ключи, которые несколько лет назад, возможно, соответствовали последнему слову криптографической науки, могут оказаться более уязвимыми для современных компьютерных возможностей. И конечно, всегда существует риск несчастного случая, когда секретный ключ непреднамеренно раскрывается, либо – что до некоторой степени так же плохо, – когда секретный ключ становится недоступным. Последний случай не означает взлом секретного ключа, однако конечный результат аналогичен – ключ становится фактически невозможно использовать.
DNSSEC и заявление о практике администрирования ключами
Таким образом, ни один криптографический секрет не может считаться «абсолютным». Все это является относительным, и применение ключа связано с некоторым риском того, что он не является строгим секретом. Если дело обстоит именно так, и если мы не можем реально понять точные уровни риска, связанные с использованием ключа, то почему мы должны доверять любому виду шифрования с открытым ключом?
Для того, чтобы позволить нам принять более обдуманное решение о степени доверия к открытому ключу, общепринятым выбором для администратора ключей является публикация «Заявления о практике» (Practice Statement), которое подробно описывает процедуры, которые держатель ключа применяет для его обслуживания.
Это публичное обязательство администратора ключей в отношении методов, которые используются для поддержания целостности личного ключа.
Обычно в таком документе ожидают увидеть изложение требований, описание оборудования и средств управления, которые применяются в работе с секретными ключами, технических средств контроля, операционных действий и намерений в отношении аудитов соответствия. Таким образом, до тех пор, пока администраторы ключей соблюдают обязательства, изложенные в опубликованном ими заявлении о практике, пользователи, которые полагаются на целостность секретного ключа как на основу их доверия к подписанным объектам в связанной с этим инфраструктуре открытого ключа (PKI, Public Key Infrastructure), имеют в запасе нечто, что может быть более основательным, чем неподтвержденная слепая вера!

Инфраструктура ключа DNSSEC для DNS не использует обычные сертификаты открытого ключа X.509, а задействует иерархическую структуру открытого ключа, в рамках которой цепочки подписания ключа содержатся внутри модели иерархического делегирования структур имен. На вершине структуры имен DNS находится корневая зона, а на вершине соответствующей структуры открытого ключа располагается ключ подписания ключа (KSK, Key Signing Key) корневой зоны.
Если мы хотим доверять целостности KSK в качестве базиса для доверия к DNSSEC, то необходимо взглянуть на заявление о практике оператора KSK корневой зоны. Этот документ был опубликован проектной группой DNSSEC в корневой зоне в октябре 2010 года, его можно найти по ссылке: www.iana.org/dnssec/icann-dps.
В разделе 6.5 этого документа написано следующее:
Запланировано, что каждый ключ KSK корневой зоны пройдет через церемонию обмена ключами в соответствии с установленными требованиями, либо через пять лет эксплуатации.
При этом некоторую дискуссию вызвало значение фразы «через пять лет эксплуатации»: подразумевала ли эта фраза обязательство изменить значение KSK на пятую годовщину эксплуатации, либо буквально в любое время после пятой годовщины, что может включать последующий промежуток времени, возможно, длящийся целые десятилетия! Разумная интерпретация этого обязательства представляет собой приблизительную оценку предыдущего, а именно, обязательства, которое включало намерение изменить KSK по истечении пяти лет эксплуатации или через некоторое время после этого срока. Учитывая тот факт, что ключ KSK был введен в действие в июле 2010 года, это означает, что изменение KSK было запланировано примерно на середину 2015 года или около этого срока.
Где мы находимся с этой задачей? Будет ли изменен ключ KSK?
Каким образом это будет сделано?
Отчет проектной группы KSK
В марте 2016 года организация ICANN опубликовала отчет проектной группы, которая анализировала эту задачу в течение предыдущих 15 месяцев. Отчет опубликован по адресу: www.iana.org. Этот отчет последовал за состоявшимся в 2012 году общественным обсуждением, проводившимися в 2013 году технологическими исследованиями и исследованием (также проводившимся в 2013 году) Комитета по стабильности и безопасности при ICANN (www.icann.org/en/system/files/files/sac-063-en.pdf). Это означает, что работы по подготовке изменения KSK начались задолго до пятилетней годовщины и продолжаются по сей день.
Первый вопрос заключается в том, почему прилагается столько усилий по изменению ключа KSK корневой зоны? Ключи DNSSEC, как ключи подписания зоны (ZSK, Zone Signing Key), так и ключи KSK, меняются все время, и обычно они не требуют такого же уровня внимания и заботы на протяжении целого ряда лет. Почему этому конкретному ключу KSK уделяется столь особое внимание?

Ключ KSK корневой зоны является «особым», поскольку для него отсутствует вышестоящий ключ, который может «закрепить» изменение ключа. Каждый резолвер, осуществляющий DNSSEC-валидацию, имеет локально кэшированную копию этого значения KSK в качестве доверительного ключа, однако проблема заключается в том, чтобы выполнить набор изменений, которые могут сигнализировать этим резолверам о необходимости загрузки нового ключа в локальный кэш в качестве доверительного, и кроме того, выполнить это безопасным способом. Именно здесь вступают в игру процедуры, описанные в RFC 5011. Поскольку не существует вышестоящего ключа для фиксации изменяющего ключа, RFC 5011 определяет процесс, в рамках которого старый ключ KSK фактически является точкой привязки изменения ключа, позволяя резолверам доверять входящему ключу KSK на базе их доверия к применявшемуся ранее ключу. Этот процесс влечет за собой подписание уходящим ключом KSK входящего ключа KSK и затем поддержание этого состояния в течение расширенного периода (30-дневный период «добавления удержания»; Add Hold-Down) как средства противодействия определенным видам атак с помощью взломанного набора ключей.
Почему ключ подписания ключа корневой зоны DNS является особенным? Каким образом этот конкретный ключ отличается от всех остальных ключей в рамках DNSSEC?
Простой ответ заключается в том, что это единственный ключ в рамках всей структуры DNSSEC, для которого не существует «вышестоящего ключа». 
В случае ключа ZSK вышестоящим ключом является ключ KSK зоны. Изменение ключа ZSK обычно сопровождается введением нового ключа ZSK при помощи его публикации в наборе DNSKEY зоны (он, как обычно, подписывается ключом KSK). После того, как пройдет определенный период времени, позволяющий распространить старую, кэшированную версию записи DNSKEY по всем авторитетным серверам, плюс значение времени жизни (TTL, Time To Live) для набора ключей, новый ключ ZSK будет готов для использования. К этому моменту все подписи в зоне могут быть «переподписаны» с использованием нового ключа ZSK. Старый ключ ZSK хранится в наборе DNSKEY для того, чтобы обеспечить валидацию ранее кэшированных копий записей подписи (подписанных старым ключом) с помощью старого ключа ZSK. И опять, после распространения и периода TTL может быть выполнен финальный этап, который подразумевает удаление старого ключа ZSK из зоны. До тех пор, пока существует ключ KSK, которым можно подписывать записи, относящиеся к разным ZSK, изменение ключа ZSK является простым и понятным (Рис. 1). 

Рис. 1. Изменение ключа ZSK

Эти шаги в процессе изменения ключа KSK, предложенные в RFC 5011, показаны на Рис. 3. Изменения в корневой зоне, необходимые для смены KSK, касаются только изменений в наборе записей ресурсов (RRset, Resource Record Set) DNSKEY корневой зоны. Никакая другая часть корневой зоны не меняется из-за этого изменения ключа.
При изучении шагов на Рис. 3, можно заметить, что на начальной стадии RRset DNSKEY содержит действующие ключи KSK и ZSK, а вся запись DNSKEY подписана действующим ключом KSK.
Первый шаг заключается в том, чтобы ввести новый ключ KSK в корневую зону. Это достигается за счет добавления дополнительной записи ресурсов (RR) DNSKEY в корневую зону, что фактически публикует новое значение ключа. Набор RRset DNSKEY по-прежнему подписан действующим ключом KSK. Это состояние сохраняется неизменным в течение не менее 30 дней (период «дополнительного удержания», Hold-Down, определенный в RFC 5011), что помогает смягчить некоторые риски, появившиеся из-за ослабленного ключа.
Резолверы, осуществляющие проверки DNSSEC, должны обеспечить валидацию этого набора RRset DNSKEY, а если этот набор является действительным и новый ключ KSK был стабилен в течение периода «дополнительного удержания», то они в состоянии добавить новый ключ KSK в локальный набор достоверных ключей.
Второй шаг заключается в удалении старого ключа KSK из корневой зоны. Это влечет за собой удаление старого ключа из набора RRset DNSKEY и подписание этого набора с помощью нового ключа KSK.
Остается один финальный шаг, и он заключается в выдаче указания резолверам на удаление старого значения ключа из своего локального набора достоверных ключей. Это требует того, чтобы старый ключ KSK был добавлен обратно в набор RRset DNSKEY, но на этот раз с набором битов REVOKE, а также требует подписания набора RRset DNSKEY с использованием старого и нового ключей KSK. После этого старый ключ KSK может быть удален и уничтожен.
Существует целый ряд наблюдений в отношении этого процесса.
Аналогичным образом, изменение ключа KSK может быть простым и понятным делом. Первый шаг заключается во введении нового ключа KSK в состав набора DNSKEY. На этот момент может быть также добавлена вторая запись RRSIG записи DNSKEY, сгенерированная с использованием нового ключа KSK. В то время, как запись DS родительской зоны ссылается на старый ключ KSK, новая запись RRSIG не будет использоваться для валидациии поэтому фактически ничего не меняется. После того, как родительская зона «подберет» новую запись DS (соответствующую новому ключу KSK), она может ее немедленно опубликовать. Текущая зона должна продолжать публикацию старого ключа KSK и значения его подписи по крайней мере в течение периода TTL старой записи DS для того, чтобы обеспечить правильное обслуживание валидации для любых кэшированных значений DS. После истечения периода TTL записи DS старый ключ KSK и соответствующая ему запись подписи могут быть удалены из зоны (Рис. 2). Эти шаги и различные альтернативы подробно рассматриваются в RFC 6781. Ключ KSK корневой зоны немного отличается, поскольку для него не существует вышестоящего ключа, который можно использовать для «закрепления» меняющегося ключа. Отсутствует ключ для передачи ключа KSK и какой-либо обычный способ, чтобы гарантировать непрерывность цепочки доверия.

Рис. 2. Изменение ключа KSK
Рис. 3. Изменение ключа KSK корневой зоны – согласно RFC 5011

Первое наблюдение заключается в том, что второй и третий шаги можно поменять местами. Другими словами, после того, как новый ключ был введен в зону на Шаге 1, старый ключ можно отменить, а набор RRset DNSKEY можно подписать как уходящим, так и входящим ключом. После истечения соответствующего периода времени (более длительного, чем время жизни (TTL) для зоны) старый ключ KSK и его подпись могут быть удалены из корневой зоны. Однако, если это сделать, то не будет существовать пути обратно в случае, если процесс сгенерирует неприемлемый уровень ошибок, видимых для пользователя. При помощи разделения операций по изъятию старого ключа и его последующего аннулирования на дискретные события сохраняется возможность восстановления старого (и по-прежнему достоверного) ключа на случай, если введение нового ключа KSK приведет к непредусмотренному уровню отказа DNS.
Второе наблюдение заключается в том, что не существует периода, когда происходит «наложение» старого и нового ключей KSK. Переход между вторым и третьим шагами предусматривает полное удаление старого ключа KSK. На этом этапе не существует наложения, когда оба – старый и новый – ключа KSK одновременно подписывают набор RRset DNSKEY. Причиной этого пропуска является то, что двойное подписание набора RRset DNSKEY не несет никаких выгод в плане помощи при изменении ключа KSK, а, возможно, приводит к незначительному ухудшению положения. В конце Шага 1 все резолверы будут по-прежнему использовать уходящий ключ KSK для валидации подписи DNSKEY. Что касается Шага 2, то те резолверы, которые добавили входящий ключ KSK в свой доверительный набор, будут использовать этот входящий ключ, тогда как другие резолверы окажутся в затруднительном положении без точки доверия.
Добавление этапа двойного подписания ничем не отличается от продолжения ситуации Шага 1. Те резолверы, которые не научились доверять новому ключу KSK, и те резолверы, которые подобрали новый ключ KSK как точку доверия, не способны сигнализировать о своем состоянии доверия ни одной третьей стороне, поэтому внешняя среда не становится «мудрее». Недостаток заключается в том, что двойные подписи увеличивают размер ответа на запрос DNSKEY без какой-либо помощи или простого информирования для процесса изменения ключа.
Весь процесс изменения ключа KSK не такой простой, как это описано выше, а кроме того, необходимо учитывать ключ ZSK. Ключ ZSK меняется каждый квартал. В течение 10 дней, предшествующих началу квартала, новый ключ ZSK добавляется в набор RRset DNSKEY вместе с действующим ключом ZSK, фактически передавая резолверам новое значение ключа ZSK. В первый день каждого квартала происходит смена ключа ZSK, при этом корневая зона подписывается новым ключом ZSK. Старый ключ ZSK остается в составе набора RRset DNSKEY в течение последующих 10 дней, что позволяет резолверам с кэшированным материалом, подписанным уходящим ключом ZSK, по-прежнему осуществлять валидацию этой кэшированной информации с помощью набора DNSKEY RRset корневой зоны. После истечения 10 дней старый ключ ZSK удаляется из корневой зоны, и процесс смены ZSK завершается. Если мы будем использовать период перехода к новому ключу ZSK для выполнения шагов по смене ключа KSK, то предполагаемый процесс будет больше походить на то, что изображено на Рис. 4.

Расписание изменения ключа KSK
Еще не утвержденное, предварительное расписание для изменения ключа KSK было предложено в отчете проектной группы (рекомендация 17 отчета проектной группы).
Рекомендованный график имеет следующий вид:
1 апреля 2016 г.
Подготовка нового набора ключей KSK, распространение его на средства хранения вторичных ключей и генерирование материала корневой зоны для использования в будущих шагах по изменению ключа.
11 января 2017 г.
Введение нового значения ключа KSK в корневую зону (Рис. 4, Шаг 1).
1 апреля 2017 г.
Смена ключа KSK и подписание набора RRset DNSKEY корневой зоны с использованием нового значения ключа KSK (Рис. 4, Шаг 3).
11 июля 2017 г.
Повторная публикация старого ключа KSK с набором битов REVOKE и подписание набора RRset DNSKEY с использованием обоих ключей KSK – старого и нового (Рис. 4, Шаг 7).
19 сентября 2017 г.
Завершение: удаление старого ключа KSK из корневой зоны (Рис. 4, Шаг 8).
Примечание редакции:
Окончательный план включает следующие шаги:
• Октябрь 2016: начало процесса замены KSK: генерация нового ключа KSK.
• Июль 2017: публикация нового KSK в DNS.
• Октябрь 2017: новый KSK используется для подписания пакета ключей корневой зоны. Это собственно и означает замену ключа.
• Январь 2018: отзыв старого KSK.
• Март 2018: завершение процесса замены KSK.
Длительное время ожидания – продолжительностью девять месяцев в 2016 году – отражает периодический график церемоний доступа по ключу. Последующие девять месяцев 2017 года «переплетены» относительно плановых изменений ключа ZSK корневой зоны, при этом изменения ключей KSK планируется вставить между изменениями ключей ZSK (там, где это возможно) для того, чтобы гарантировать, что размеры DNS-ответов не стали чрезмерно большими.

Рис. 4. Изменение ключа ZSK и ключа KSK корневой зоны  

Что меняется, а что нет
Ключ KSK представляет собой асимметричный 2048-битовый RSA-ключ. На данный момент не предлагается менять ни размер ключа, ни криптографический алгоритм, используемый для его генерации.
Целый ряд экспертных организаций считает, что 2048-битовый ключ обеспечивает адекватную стойкость на предстоящие 10-15 лет.
Для подтверждения этой точки зрения проектная группа приводит выдержки из отчетов ECRYPT, NIST и ANSSI. Учитывая вышеизложенное, не существует убедительных аргументов, оправдывающих увеличение размера RSA-ключа.
Эти отчеты агентств включают:
www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf
csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf
Альтернативой использованию таких больших RSA-ключей является переход на другой криптоалгоритм. Одна из потенциальных альтернатив RSA – это один из алгоритмов, входящих в набор Алгоритмов цифровых подписей на основе эллиптических кривых (ECDSA, Elliptical Curve Digital Signature Algorithm), которые используют гораздо меньшие по размеру ключи, обеспечивающие аналогичную криптографическую стойкость. Например, ECDSA-ключ, использующий кривую P-256, имеет стойкость, эквивалентную по крайней мере асимметричному 3072-битовому RSA-ключу. Однако, хотя это и может уменьшить размер DNS-ответов при изменении ключа, недостатком такого решения становится то, что поддержка ECDSA в резолверах никоим образом не является всеобщей. Недавно проведенные измерения указывают на то, что один из каждых шести пользователей использует резолвер, обеспечивающий валидацию ответа, подписанного с помощью алгоритма RSA, но не может выполнить проверку ответа, подписанного с помощью ECDSA.
Изменение протокола несет риск фактического выключения DNSSEC-валидации для одного из классов резолверов DNS, а также для пользователей, находящихся «позади» этих резолверов DNS.
Вывод из всех этих рассуждений заключается в том, что в данном случае, а именно при первом изменении ключа KSK, изменение, вводимое при смене ключа, намеренно ограничивается значением ключа, при этом не предусматривается изменение протокола или размера ключа. Это отражает консервативный принцип работы: если вы собрались изменить что-то, что никогда не менялось в прошлом, то ограничившись изменением лишь одного атрибута можно ограничить риск отрицательного результата. Это не означает, что задача не сопряжена с риском. Существуют серьезные риски, связанные с этой сменой ключа.

Риски

Имеется целый ряд аспектов риска, связанных с этой сменой ключа.
Перед тем как подробно рассказывать о рисках, необходимо выполнить первый шаг – количественно оценить величину риска.
Сколько пользователей может быть потенциально затронуто сменой ключа KSK? В настоящее время примерно 87% всех уникальных запросов, проходящих через полномочные серверы доменных имен, включают как опцию EDNS0, так и набор битов DNSSEC OK. Другими словами, 9 из 10 пользователей направляют свои запросы резолверам, которые запрашивают цифровую подпись DNSSEC у полномочных серверов доменных имен. Однако запрос данных и их использование, судя по всему, являются двумя разными концепциями. Лишь одна треть из этих запросов сгенерирует последующий набор запросов, необходимых для валидации результата с помощью DNSSEC. Эта цифра, соответствующая 30% от общего количества пользователей, ближе к оценке общего пула риска для смены ключа KSK.
Однако риск сбоя в работе, возможно, не столь велик. Если результат попытки валидации будет неудачным, то половина этого потока запросов переключится на использование резолверов без валидации, тогда как только оставшаяся половина, или 15% всех пользователей, примут ошибку валидации.
Основываясь на этих данных, можно отметить, что изменение материала точки доверия может иметь негативные последствия для примерно 30% пользователей Интернета. Учитывая то, что одна половина этих пользователей в случае отказа переключится на пути без валидации, это подразумевает, что в худшем случае приблизительно 15% от общего числа пользователей может до такой степени почувствовать негативное влияние этой смены ключа, что, если их резолверы потеряют точку доверия KSK, то они не смогут определить все имена DNS, подписанные с помощью DNSSEC.
Последняя часть этого предложения также важна для оценки риска. Это не значит, что в худшем случае 15% пользователей останутся совершенно без услуг DNS. Это означает, что 15% пользователей не смогут транслировать имена, подписанные DNSSEC. Точные цифры недоступны, но известно, что в то время как значительное число резолверов готово осуществить валидацию ответов, гораздо меньшее число DNS-имен подписаны. Таким образом, теоретический максимум 15% пользователей ослабляется наблюдением, что только незначительная часть всех имен подписана.
Я оставлю здесь оригинальный текст, перечеркнув его, в качестве иллюстрации того, что в тех случаях, когда дело касается DNS, следует всегда проявлять чрезвычайную осторожность в наших предположениях. Мое предположение о том, что это затронет только определение имен, подписанных с использованием DNSSEC, фактически не является правильным. Поскольку корневая зона подписана, валидирующий резолвер попытается удостовериться в том, что предположительно неподписанный ответ DNS действительно не подписан, и что это не является результатом попытки некоей третьей стороны подменить ответ. Поэтому резолвер попытается найти точку в пути преобразования имени, в которой состояние подписания DNSSEC переключается с подписанного на неподписанное, и удостоверить это состояние, тем самым убеждая себя, что ответ действительно не подписан. Это означает, что любой из этих валидирующих резолверов не сможет предоставить никакого ответа, поскольку его состояние точки доверия не соответствует корневому.
Если клиент выключит все проверки DNSSEC (задаст бит Checking Disabled (проверка деактивирована) в EDNS0), то резолвер ответит на все запросы, однако во всех других случаях – как для подписанных, так и для неподписанных имен – он возвратит ответ SERVFAIL.
Это значительно повышает риск сбоя.
Что может пойти не так?
Главный риск – это невозможность загрузить новый ключ KSK как доверительный ключ из-за неспособности выполнить процедуру согласно RFC 5011. Один класс уязвимых резолверов DNS имеет активированную валидацию DNSSEC, но не поддержку RFC 5011. Это может быть относительно редкой комбинацией, однако Интернет поддерживает самое разнообразное программное обеспечение, и было бы опрометчиво утверждать, что такая комбинация просто не существует. Вероятно, она все-таки существует, однако очень трудно оценить, какое количество резолверов относится к этой категории.
Возможно, более частым случаем являются те резолверы DNS, локальная конфигурация которых выключает «автоуправляемые» доверительные ключи. Такая настройка фактически не дает резолверу загрузить новое значение ключа KSK при его публикации в корневой зоне. И опять, изначально просто невозможно определить, сколько резолверов работают с вручную сконфигурированными ключами, и сколько пользователей находятся «позади» таких резолверов, а также окажутся ли готовыми системные администраторы к ручной загрузке новых ключей KSK при их объявлении в корневой зоне.

Существуют резолверы, которые используют текущий достоверный ключ KSK через локальный конфигурационный файл, но которые активируются в закрывающемся 30-дневном окне перед сменой ключа KSK. Эти резолверы не увидят новый ключ KSK в течение периода «дополнительного удержания», продолжающегося полные 30 дней, но, тем не менее, ожидается, что они будут следовать процедуре смены ключа KSK. И наконец, существуют резолверы, использующие устаревшую среду конфигурирования, которые активируются после смены ключа KSK. Эти резолверы будут отброшены в сторону и не смогут действовать как валидирующие резолверы DNSSEC до тех пор, пока новое значение ключа KSK не будет загружено в их локальную конфигурацию.
Вторым основным риском является неспособность загрузить новый ключ KSK из-за проблем, связанных с большими по размеру DNS-ответами. Размер подписанного ответа на запрос о получении набора RRset DNSKEY корневой зоны обычно колеблется между 736 и 883 октетами (байтами). Этот размер увеличивается в ходе смены ключа ZSK, когда в набор RRset DNSKEY загружены два значения ключа ZSK. Ожидается, что могут возникнуть проблемы с протоколом UDP, если размер ответа начнет приближаться к лимиту полезной нагрузки в 1.232 октета для нефрагментированного протокола пакета UDP в IPv6. Кроме того, существует общий лимит в 1.500 октетов для максимального размера IP-пакетов в большей части Интернета, который (лимит) соответствует полезной нагрузке UDP в IPv6, равной 1.452 октета, и полезной нагрузке UDP в IPv4, равной 1.472 октета. При введении нового ключа KSK в набор RRset DNSKEY размер подписанного ответа будет равен 1.011 октетам, а в последние 10 дней непосредственно перед сменой ключа KSK будут существовать два значения ключа KSK и два значения ключа ZSK, что в сумме составляет 1.158 октетов полезной нагрузки DNS. Аннулирование старого ключа KSK предусматривает добавление значения старого ключа KSK в набор RRset DNSKEY и подписание с использованием обоих ключей KSK – старого и прибывающего. Это сгенерирует самый большой размер ответа, равный 1.297 октетам.
Конечно, это предполагает, что ключ ZSK корневой зоны представляет собой постоянное 1024-битовое значение. Если ключ ZSK увеличится в размере, то соответствующий размер пакета также должен вырасти. Хотя в настоящее время 2048-битовый ключ KSK, по-видимому, не представляет собой проблему, то же самое нельзя сказать о 1024-битовом ключе ZSK. Несмотря на то, что никто не утверждает, что выполнил факторизацию ключа такого размера в течение любого полезного промежутка времени прямо сейчас, многие государственные агентства больше не считают 1024-битовые ключи достаточно стойкими. Переход на 2048-битовый ключ RSA для ZSK добавит еще 128 октетов к размеру этих ответов.
Например, см. публикацию NIST 800-57, Часть 1, версия 4, в которой отмечается, что «комбинации размера ключа/алгоритма, которые имеют оценочную стойкость защиты менее 112 битов [2014-битовые ключи RSA обладают этой стойкостью защиты], больше не утверждаются для обеспечения криптографической защиты Информации федерального правительства [США]».
Возможно, существуют сетевые тракты, которые не обеспечивают передачу пакетов UDP с полезной нагрузкой размером 1.297 октетов. Безусловно, существует вероятность, что имеются сетевые тракты, создающие проблемы для пакетов UDP с полезной нагрузкой размером 1.158 октетов. В этом случае резолвер может попытаться уменьшить размер буфера EDNS0, намекая полномочному серверу доменных имен на уменьшение количества данных, загруженных в дополнительный раздел, и стараясь уменьшить размер ответа. Если на данном этапе сервер не способен выполнить такое уменьшение, то он отправит обратно усеченный ответ UDP и тем самым просигнализирует резолверу о том, что тот должен повторить попытку отправить запрос с использованием транспорта TCP. В этом случае мы можем опять ожидать появления некоторых проблем. DNS через TCP поддерживается не повсюду, и поэтому может также закончиться неудачей.

План Б
Таким образом, мы можем с уверенностью ожидать некоторого «урона» при этой смене ключа KSK. Какой уровень урона будет чрезмерно большим и что можно сделать для смягчения последствий?
Мы ожидаем, что некоторые резолверы не смогут странсировать имена DNS при переключении ключа KSK (Шаг 3 на Рис. 4).
В этом случае урон будет нанесен практически немедленно, и некоторое подмножество резолверов DNS, обеспечивающих валидацию DNSSEC, не сможет определять имена, подписанные с помощью модулей DNSSEC. Вероятно, что многие из этих затронутых резолверов могут быть очень быстро исправлены при помощи ручной загрузки нового ключа KSK в качестве доверительного либо посредством их переконфигурирования с полным запретом на выполнение валидации DNSSEC.
Однако существует второй период уязвимости, в течение которого мы ожидаем, что некоторые резолверы DNS не смогут определять имена после аннулирования старого ключа KSK (Шаг 7 на Рис. 4).
Причиной станет то, что в течение этого периода размер ответа DNSKEY вырастет до 1.297 октетов, и это вызовет проблемы у части резолверов, особенно в случае использования UDP через IPv6, поскольку размер такого ответа превысит гарантированный размер нефрагментированного пакета IPv6, равный 1.280 октетам, после того, как заголовки UDP и IPv6 (48 октетов) будут добавлены к полезной нагрузке DNS. Экспериментальные исследования (см. раздел 6.1.2 отчета проектной группы) показывают, что «этот 1% резолверов, которые стабильно сталкиваются с отказами два или большее число раз, используются менее чем тремя тысячами оконечных систем или 0,04% оконечных систем в рамках выборки».
Как часть потенциального «Плана Б», который может быть задействован при смене ключа KSK, отчет проектной группы содержит следующие рекомендации:
Рекомендация 14: Для того, чтобы обеспечить поддержку ряда потенциальных вариантов операционной обстановки, которые могут потребовать отката изменений, внесенных в корневую зону в ходе каждого этапа смены ключа KSK, необходимо генерировать Подписанные запросы на получение ключа [SKR, Signed Key Request] с использованием применявшегося ранее ключа KSK, запросы SKR с использованием как применявшегося ранее, так и поступившего ключей KSK и запросы SKR с использованием поступившего ключа KSK. Кроме того, проектная группа рекомендует двойное подписание в качестве предпочтительного механизма для ответа на требование по выполнению отката в Квартале 2 процедуры смены ключа.
[Эта рекомендация заключается в том, чтобы заранее подготовить набор ключей, чтобы, если возникнет необходимость в откате смены KSK ключа, то этот набор был бы уже доступен администраторам корневой зоны.]
Рекомендация 15: Партнеры по управлению корневой зоной должны выполнить или поручить выполнение программы измерений, которая способна определить влияние изменений на поведение валидирующих резолверов DNSSEC, а также способна оценить группу оконечных узлов, на которые негативно повлияли изменения в поведении валидирующих резолверов.
[Эта рекомендация заключается в том, что менеджеры корневой зоны должны организовать непрерывное измерение в рамках всего процесса смены ключа KSK.]
Рекомендация 16: Откат шага в рамках процесса смены ключа необходимо инициировать в том случае, если программа измерений показала, что как минимум 0,5% оценочного количества конечных пользователей Интернета было негативно затронуто изменением через 72 часа после того, как каждое изменение было развернуто в корневой зоне.
[Эта финальная рекомендация заключается в определении «порогового» ущерба в данном контексте.]
Почему 0,5%? Методы измерения носят относительно грубый характер, и поэтому только проведение измерений в течение расширенного периода времени позволяет их уточнить до возрастающих уровней детализации. Если требуется измерить показатели валидации DNSSEC на уровне дней, то экспериментальная погрешность составляет +/-0,1%, поэтому пороговое значение 0,4% или более низкое не поддается измерению с разумным уровнем достоверности (доверительной вероятности). В связи с этим 0,5% предложено как значение, немного превышающее минимальный измеримый порог при использовании каждодневного метода измерения.
Почему 72 часа? Мы ожидаем, что в первый день или два те операторы резолверов DNS, которые были негативно затронуты, самостоятельно примут меры по исправлению ситуации и восстановят обслуживание своих пользователей. Любой долговременный ущерб, который не был исправлен локальными действиями, будет, по всей вероятности, очевиден через 72 часа.

Следующие шаги
Однако это никоим образом не означает конец истории. Еще предстоит выполнить много работы.
Нам, по всей видимости, нужно подумать о проблеме резолверов и точек доверия. Здесь частью фактора неизвестности является неспособность резолверов сообщить о своих точках доверия. Если бы резолверы были способны сообщать о своих точках доверия, предположительно через опцию EDNS0, встроенную в запросы к корневым серверам, то стало бы возможным отследить, в каком масштабе публикация нового ключа KSK была «подхвачена» резолверами в качестве нового доверительного ключа. Конечно, это не приведет к отмене допущений, на которых основана оценка риска, поскольку мы перейдем от двухвидовой классификации резолверов (те, которые выбрали новый ключ KSK в качестве доверительного ключа, против тех, которые это не сделали) к четырехвидовой классификации (добавляем к предыдущей классификации резолверы, которые способны сообщать о своих доверительных ключах, против тех, которые не
способны это сделать).
Мы не можем продолжать увеличивать размер ключа RSA, учитывая ограничения, налагаемые размером пакета UDP, и превратности фрагментации пакетов UDP. Возможно, следующий ключ KSK должен быть заменен на ключ с использованием алгоритма ECDSA, и, возможно, мы должны подумать об одновременном переходе от ZSK к ECDSA.
Кроме того, в текущей среде не существует никаких условий по любому виду чрезвычайной смены ключа KSK. Если используемый ключ KSK больше не доступен, либо если он был раскрыт, то модель транзитивности доверия, в рамках которой старый ключ подписывает новый, больше нельзя использовать для распространения нового ключа KSK. Возможно, настало время подумать о предварительной подготовке ключей KSK и о поддержании некоего набора ключей KSK, объявленных для периода «дополнительного удержания». В результате, если текущий ключ KSK больше не будет доступен, либо если он будет раскрыт иным образом, появится возможность в очень короткие сроки перейти к предварительно подготовленному ключу KSK.
Источник: Rolling the Root, www.potaroo.net/ispcol/2016-03/rolling.html