ICANN отложила ротацию ключей KSK (Key Signed Key) для корневой зоны

ICANN отложила начало процедуры ротации ключей (KSK) для корневой зоны 27 сентября. Таким образом, событие, которое планировалось с 2010 года после подписания корня, откладывается на неопределенный срок. А должно было оно произойти 11 октября 2017.

Возникает резонный вопрос: что понудило ICANN изменить свои планы?

В своем сообщении ICANN указала, что «Изменение ключа подразумевает создание новой пары криптографических ключей и распространение нового открытого компонента ключа среди резолверов, осуществляющих валидацию DNSSEC (DNSSEC – расширения безопасности системы доменных имен). Если посмотреть на предполагаемое количество интернет-пользователей, которые используют резолверы, осуществляющие валидацию DNSSEC, изменение KSK может затронуть приблизительно четверть интернет-пользователей мира или 750 миллионов человек».
Мягкое «изменение KSK может затронуть» означает то, что эти сотни миллионов пользователей потеряют возможность доступа к информационным ресурсам Сети по доменному имени. Получить информацию, используя IP-адреса ресурсов, будет можно, но кто же знает, а если даже и знает, то помнит ли адреса yandex, google и facebook. Кроме того, для этих пользователей прекратится доступ не только в web, но они потеряют возможность переписываться со своими друзьями и коллегами посредством электронной почты.
Так что решение ICANN скорее всего оправданно. Тем не менее, следует обратить внимание на два момента: что заставило внедрить технологию DNSSEC в систему DNS, как ICANN обнаружила возможность возникновения проблемы и оценила возможный ущерб.

Для чего нужен DNSSEC

В 2008 году на конференции BlackHat 2008 Дэн Камински обратил внимание сетевой общественности на фундаментальную проблему реализации протокола DNS – возможность подмены содержания ответов авторитетных DNS-серверов и кэширование подменных ответов
резолверами.
Подменить адрес источника позволяет транспорт UDP – это фундаментальная уязвимость этого транспортного протокола. А вторая фундаментальная проблема – это кэширование, которое является неотъемлемой частью работы системы DNS. Кэширующие серверы обслуживают конечных пользователей. У крупного ISP (Internet Service Provider) один кэширующий сервер может обслуживать тысячи клиентов. «Отравление» кэша, таким образом, представляет серьезную проблему.
Подменить можно не только соответствие между, скажем, именем yandex.ru и адресом 77.88.55.55 (один из списков адресов, которые связаны с этим именем), но адрес сервера, который обслуживает корень системы DNS, скажем, a.root-servers.net (198.41.0.4). А вот это уже позволяет построить параллельный Интернет для клиентов кэширующего сервера.
Кэши «отравляли» и до сообщения Камински. На программное обеспечение ставили заплатки – и проблема на некоторое время «уходила» до повторения атаки в новых условиях. Но тут за дело, т.е. ликвидацию угрозы, взялись всерьез. Рандомизацией портов и других полей заголовка UDP и DNS-пакетов дело не ограничилось.
В 2005 году появились спецификации расширения безопасности DNS2 – DNSSEC. Идея состояла в том, чтобы обеспечить независимый способ проверки достоверности DNS-ответов, основанный на анализе информации самих ответов.
В заголовок DNS-пакета добавили несколько флагов, в список записей описания ресурсов добавили записи, которые позволяли передавать ключи и подписи. Главная идея состояла в эксплуатации административной процедуры делегирования права управления файлом зоны домена.
Все ответы в DNSSEC удостоверены цифровой подписью администратора зоны, которая, в свою очередь, удостоверена цифровой подписью администратора старшей зоны.
В иерархии DNS администратор старшей зоны делегирует администратору младшей зоны право вести файл зоны своего домена на свое усмотрение. Это означает, что между администраторами есть независимый канал взаимодействия, который позволяет обмениваться информацией.
Соответственно, администратор младшей зоны может передать администратору старшей зоны информацию для размещения в его файле зоны, которую потом можно будет сравнить непосредственно или путем вычислений с тем, что он разместил у себя в файле зоны.
Пакет RFC про DNSSEC определяет различные варианты удостоверения подписей данных из файла зоны домена. В том числе, например, и «острова» доверия. Однако в полной версии цепочка доверия всегда выстраивается до ключей корневой зоны. В данном случае пара ключей KSK корня фактически и являются тем якорем доверия, который необходим для удостоверения правильности ответов резолверов.
Учитывая тот факт, что при первичном рекурсивном поиске любого соответствия имени адресу мы должны обратиться к корню, неточности или шероховатости в получении KSK могут вылиться в большую проблему.

Новый ключ и валидирующие резолверы

Общий график ротации пары KSK выглядел следующим образом:
22 июня был опубликован план ротации ключа. Опубликован он был для широкого обсуждения.
27 октября 2016 года должна была начаться процедура ротации ключа. В этот день была сгенерирована новая пара ключей KSK (открытый и секретный).
В феврале 2017 года ключи были скопированы в резервное хранилище.
13 марта 2017 года появилась возможность протестировать программное обеспечение на предмет возможности получения нового ключа и работы с ним. Это можно было сделать либо вручную (скопировать ключ с www.iana.org/dnssec/fles), либо проверить возможность поддержки резолвером RFC-5011.3
11 июля 2017 новый публичный KSK был опубликован в DNS. С этого момента можно было проверить, копирует ли резолвер новый ключ согласно RFC-5011 или требуется ручное вмешательство.
19 сентября 2017 все корневые серверы увеличили размер ответа DNSKEY.
11 октября новый ключ должен был начать использоваться для удостоверения на равных со старым ключом.
В феврале 2018 года ожидался отзыв старого ключа.
Считалось, что с весны до осени 2017 года времени достаточно, чтобы провайдеры DNS-резолверов убедились в правильности работы с DNSSEC.
Интернет изнутри №7

Новый ключ и валидирующие резолверы

Здесь следует особо отметить, что ротация ключа корневой зоны касается только провайдеров кэширующих резолверов, т.к. именно они (резолверы) осуществляют валидацию DNS-ответов согласно стандартам DNSSEC. Теоретически такую валидацию можно осуществлять и на стороне конечного клиента. Но вероятность такого варианта исчезающе мала.
Операторам валидирующих резолверов необходимо было провести следующие мероприятия:
Определить, поддерживает ли их резолвер ротацию ключей согласно RFC 5011. Если такая поддержка есть, то убедиться в том, что она включена.
Проверить, что резолвер, поддерживающий RFC 5011, смог получить KSK-2017 (уже опубликован) и корректно включил этот ключ в список доверенных.
Для резолверов, не поддерживающих RFC 5011, заблаговременно получить достоверную копию KSK-2017 и включить его в список доверенных ключей.
Например, валидирующие рекурсивные резолверы АО «ЦВКС «МСК-IX», входящие в облака:
• dns.ix.ru (IPv4: 62.76.76.62 / IPv6: 2001:6d0:6d0::2001);
• dns2.ix.ru (IPv4: 62.76.62.76 / IPv6: 2001:6d0:6d::2001),
поддерживают стандарт RFC 5011.
Все необходимые опции программного обеспечения на валидирующих рекурсивных серверах АО «ЦВКС «МСК-IX» для возможности автоматической ротации KSK корневой зоны DNS были активированы. Соответственно, ключи были вовремя получены.
«ЦВКС «МСК-IX» в качестве оператора системы DNS национальных доменов ru/рф провел исследование статистики обращений резолверов к авторитетным серверам зон ru/рф. В результате этого исследования выяснилось, что 75,79% российских резолверов готовы принимать DNSSEC. А вот среди зарубежных резолверов таких оказалось больше – 86,01%. Если бы все они реально валидировали ответы и не поддерживали новый ключ, то проблема была бы серьезной.
Но всегда полезно руководствоваться принципом «доверяй, но проверяй». В апреле 2017 года в протокол DNS были внесены изменения, которые позволяли получать информацию о том, какой из KSK поддерживает резолвер. ISC в bind и NLnet Labs в unbound реализовали эту спецификацию. Это позволило VeriSign получить соответствующую статистику (рис. 1).
Рис. 1. Статистика получения данных о поддерживаемых KSK.

Согласно этим данным, от 6% до 8% резолверов продолжают поддерживать только старый KSK.
Результаты исследования были переданы в ICANN – и корпорация решила заморозить на неопределенное время процедуру ротации ключа. В конце концов, семь лет не меняли, можно еще несколько месяцев потерпеть, пока окончательно не определится тенденция с получением нового ключа, и пока не станет ясно, что администраторы этих серверов не намерены что-либо предпринимать.
Ссылки
1. www.icann.org/news/announcement-2017-09-27-ru
2. www.ietf.org/rfc/rfc4035.txt, www.ietf.org/rfc/rfc4034.txt, www.ietf.org/rfc/rfc4033.txt
3. tools.ietf.org/html/rfc5011
4. tools.ietf.org/html/rfc8145
5. blog.verisign.com/domain-names/root-zoneksk-rollover-postponed/