Ротация ключей DNSSEC – как это делать при карантине, опыт и обсуждение в ICANN

Большинство из наших читателей знакомо с термином «DNSSEC» и технологией, которая обозначается этим термином. Главная задача DNSSEC – обеспечить надежный обмен достоверной информацией в рамках Системы доменных имен Интернета, проще говоря, DNS.

Для обеспечения этой достоверности используются криптографические ключи, которые нужно время от времени менять.

Для корня системы DNS используется два ключа: ключ подписи ключей (Key Signing Key) и ключ подписи ресурсных записей зоны DNS (Zone Signing Key).

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

ZSK меняют гораздо чаще – четыре раза в год на протяжении последних десяти лет (ознакомиться с процессом ротации ключей можно в прямом смысле слова «воочию» на сайте PTI (IANA).

Но вот в 2020 году что-то с этой рутинной процедурой не задалось. Сначала 11 февраля 2020 года при подготовке к церемонии ротации ZSK во время проверки доступности пакетов с разделяемыми секретами сломался сейф. Сломался не виртуально, а натурально. Его не смогли физически открыть. Церемонию пришлось переносить с 12 февраля на более поздний срок. Ее провели 16 февраля 2020.

Но как оказалось, это были цветочки. Грянула эпидемия. Самолеты не летают, люди не перемещаются. Следовательно, необходимое для проведения церемонии ротации ключей количество криптоофицеров в американскую Вирджинию может просто (по разным объективным причинам) не приехать.

Церемония назначена на 23 апреля 2020 года. Но есть большие сомнения, что губернатор штата Вирджиния Ральф Нортэм (Ralph Northam) отменит свои распоряжения от 24 марта 2020 и 30 марта 2020, которые вводят существенные ограничения на перемещения и собрания до 10 июня 2020. Ограничения введены практически такие же, как в Москве и Московской области, с тем отличием, что бегать и ловить рыбу не запрещается (ознакомиться с этими распоряжениями можно на сайте губернатора). Правда, ситуация в Вирджинии, похоже, налаживается, согласно статистике Департамента здравоохранения штата.

В общем, не очень понятно, что теперь со всем этим — я имею в виду ротацию ключей — делать.

Директор PTI Ким Дейвис (Kim Davis) обратился к сообществу с письмом, в котором предлагает три варианта решения:

  • Провести церемонию, как и было запланировано.
  • Перенести церемонию на другую дату и провести ее только с участием американских криптоофицеров.
  • Провести церемонию по специальной процедуре (disaster recovery procedure), которая не требует физического присутствия криптоофицеров и проводится силами персонала PTI.

Сообщество высказалось в том духе, что любой из способов, отличающийся от первого, может вызвать сомнения в «прозрачности» процедуры ротации ключей.

Церемония была придумана для того, чтобы показать независимость ICANN от каких-либо государственных влияний. А тут, «понимаешь», «красная кнопка» в чистом виде!

Решение еще не принято, но PTI активно работает над приемлемой реализацией варианта №3.

На этом фоне сразу становятся актуальными рассуждения о децентрализованном корне — и на горизонте появляется Blockchain.

В общем, поживем – увидим. Ждать осталось не так и долго. Характерно, что на вебинаре, который прошел 9 апреля и был посвящен техническим вопросам работы DNS во время кризиса, о процедуре ротации не было сказано ни слова.

Инструменты удаленной работы и учебы (Zoom, Skype и все-все-все)

Рассуждая по поводу надежности инфраструктуры открытых ключей, Джефф Хьюстон (Geoff Huston) написал: «Нам нужна безопасная и вызывающая доверие инфраструктура. Мы должны быть уверены, что сервис, с которым мы контактируем, подлинный, что транзакция защищена от соглядатаев, и что мы не оставляем следов». Это высказывание верно и в более широком контексте. Особенно сейчас, когда удаленная работа стала нормой, а физическое присутствие в офисах, учебных аудиториях и на конференциях если и возможно, то только по острой необходимости.

Существует много разновидностей инструментов организации работы в удаленном режиме. Мы коснемся только одного из них – видео-конференц-связи, или сокращенно ВКС.

ВКС – это не изобретение сегодняшнего дня. Инструменты для ее проведения существовали задолго до Эпидемии. Это и Skype, и TrueConf, и Zadarma, и, конечно, Google Hangouts. Однако самой популярной платформой стал в эпоху пандемии Zoom.us.

Раньше речь в контексте инструментов удаленной работы шла об Экономии: экономии на офисах, экономии на перелетах, экономии времени и о прочих других экономиях, т.е. о повышении эффективности работы.

Сейчас же акценты сместились. В настоящее время подчас просто нет другой формы производственного общения. Нет ВКС – нет работы, нет бизнеса, нет образования, да и много чего другого нет.

В этой связи надежность и безопасность ВКС в контексте, о котором говорил Хьюстон, как никогда важны.

Самый простой и быстрый способ реализовать ВКС – это обратиться к онлайн-сервису. Не нужно собственное оборудование, не нужен специально обученный персонал. Завел корпоративный аккаунт — и Voi la! Тем более, во время кризиса это все еще и бесплатно!

Но, как и следовало ожидать, простых решений, которые удовлетворяли бы современным требованиям информационной безопасности, не бывает. Это лишний раз показала история с zoom.us.

По уверениям главы и основателя Zoom Эрика Юна (Eric Yuan), сервис, рассчитанный на десять миллионов пользователей, во время пандемии обслуживает 200 миллионов. Это привело к проблемам с безопасностью – в Сеть утекли записи телеконференций, а кроме того, стало понятно, что несмотря на все уверения, Zoom не использует сквозное шифрование.

Любопытно, что в России никаких официальных запретов на Zoom не введено. И им продолжают пользоваться в различных сферах, хотя отечественные разработки, подобные Zoom, есть.

Насколько чувствительная информация попадает в эту систему и кто и как ей воспользуется, покажет время. А пока системные администраторы активно продвигают zoom.us, а ответственные за информационную безопасность с ним борются.

Вавилонская башня Universal Acceptance

В 2010 году был принят документ RFC-5891, который определил правила использования доменных имен сети Интернет на национальных языках в приложениях. Идея применения имен доменов на национальных языках проистекает из того факта, что на английском языке читает и пишет далеко не все население Земли.

Рис. 1. Популярность языков мира.

Согласно некоторым источникам, например, сайту ethnologue.com, самым популярным языком в мире считается английский (см. рис. 1.)

На нем разговаривают почти 1,3 миллиарда человек. Но, например, на китайском разговаривает примерно столько же, сколько и на английском.

Всего в мире 7,7 миллиарда жителей, т.е. английский язык понимают только 17% жителей планеты. Считалось и считается до сих пор, что это тормозит проникновение новых технологий вообще и Интернета в частности в жизнь и быт населения Земли. Внедрение же идентификаторов на национальных языках эту проблему должно решить.

Сам по себе тезис достаточно спорный, но, тем не менее, в конце концов, ведь придумали Unicode и смогли его внедрить в современных операционных системах, что существенно, как считается, облегчило внедрение цифровых технологий в делопроизводство на национальных языках.

Именно этим посылом и руководствовались инициаторы программы внедрения международных доменных имен (Internationalized Domain Names, IDNs) в корпорации ICANN.

Важной вехой внедрения IDN стала программа ICANN по созданию доменов верхнего уровня на национальных языках (IDN ccTLD Fast Track Process). Что любопытно, эту программу в свое время выделили из общего процесса внедрения IDN, т.к. складывалось впечатление, что IDN глобально и в целом не внедрят никогда. Именно поэтому
в названии программы для национальных доменов появилось словосочетание «Fast Track Process».

Совет директоров ICANN принял эту программу в 2009 году, а в 2010 году были запущены первые национальные домены. Российский IDN (.рф) стартовал одним из первых и долгое время был самым успешным доменом верхнего уровня на национальном языке. В свои наилучшие времена, в декабре 2011 года, количество зарегистрированных доменов второго уровня в .рф достигало 937 211 штук. Все ждали одного миллиона доменов, но увы!

Впоследствии количество регистраций и продлений доменов стало падать. В настоящее время в .рф зарегистрировано 735 214 имен. В итоге домен .рф отдал пальму первенства среди IDN-доменов китайскому национальному домену , в котором зарегистрировано 1,7 миллиона доменных имен.

Многие считают, что главную роль в падении регистраций сыграло повышение стоимости регистрации в июле 2017 года с 70 рублей до 120 рублей за домен. Однако следует отметить, что снижение количества регистраций и продления регистраций началось гораздо раньше, и произошло это по совершенно другим причинам.

Падение интереса к кириллическому .рф в первую очередь объясняется невозможностью идентификации всего множества интернет-сервисов.

Внедрение IDN решает только часть задачи перевода адреса информационного интернет-ресурса (не путать с IP-адресом) на национальный язык, а именно доменного имени. Другие компоненты этого адреса остаются в рамках прежней кодировки. Чаще всего это Latin1.

Наиболее выпукло проблема обозначилась в адресах электронной почты. Невозможность реализации электронной почты в домене .рф с самого начала ограничило возможности его применения.

Такая ситуация была не только с доменом .рф, но и с другими IDN-доменами. Китайцы решали ее своими сугубо «китайскими» методами – строили соответствия между «обычными» адресами и адресами с использованием IDN, например.

В 2007 году появился первый информационный документ, который рассматривал возможность интернационализации электронной почты. Вопрос заключался не только в том, чтобы «понимать» адреса, но и в том, чтобы эти адреса правильно обрабатывались в рамках почтовых протоколов.

К 2012 году был стандартизован протокол SMTP для поддержки обмена почтовыми сообщениями Интернационализированной электронной почты, в 2013 году появился стандарт заголовков такой почты и в том же году были стандартизированы дополнения к протоколам IMAP и POP3. Фактически, в 2013 году было завершено формирование корпуса технических документов, которые были необходимы для появления технического решения. Само решение получило название Email Address Internationalization (EAI).

Однако реального внедрения в массовый сервис пришлось ждать до 5 августа 2014 года, когда Google объявил о внедрении стандартов EAI в свой сервис Gmail.

Несмотря на это, EAI до сих пор не получило широкого распространения ни в корпоративных решениях, ни в публичных сервисах.

Для продвижения идеи использования полностью интернационализованных адресов, как имен доменов, так и адресов электронной почты, в 2015 году была образована UASG — Universal Acceptance Steering Group. В нее вошли 120 компаний, включая Afilias, Apple, CNNIC, Eco, i2 Coalition, ICANN, Google, Microsoft, NIXI, THNIC и Yandex, государственные и инициативные группы.

Группа дала определение понятию «Универсального признания» (Universal Acceptance):

«Universal Acceptance (UA) — это состояние, в котором все действительные доменные имена и адреса электронной почты принимаются, проверяются, хранятся, обрабатываются и отображаются правильно и последовательно.

Программное обеспечение и онлайн-сервисы поддерживают Universal Acceptance, когда они соответствуют требованиям RFC, перечисленным в таблице 1, для всех доменов и имен электронной почты.»

Таблица 1. RFCs для UA

Если с интернационализацией доменных имен, в общем, проблем нет (браузеры и прочие приложения — как на десктопах, так и на мобильных устройствах — сейчас в целом поддерживают «правильное» отображение IDN), то с почтой все не так радужно.

Поэтому UASG выпустила техническое описание EAI в качестве введения для разработчиков. Такое описание существует и для русскоязычной аудитории.

В этом документе достаточно понятно разбирается архитектура электронной почты, роль каждого из компонентов этой архитектуры в почтовом обмене и особенности реализации этих компонентов с учетом стандартов EAI. Завершается документ обширным перечнем литературы по теме EAI.

Следует заметить, что UA – это не только о национальных скриптах. Это и о допустимой длине имен, и о конвертации Unicode в октеты, и о фишинге при использовании различных, схожих до степени смешения разных скриптов, и еще о многих проблемах, которые неизбежно появляются при усложнении технологий.

Вообще говоря, и сама проблема со скрещиванием доменных имен с именами почтовых аккаунтов во многом связана с подходом по интернационализации доменных имен, в которых был применен «костыль» Punycode. Такое решение (Punycode) понятно с точки зрения «перелопачивания» всей системы стандартов DNS, но оно же породило сложности при реализации EAI.

В общем, внедрение UA – это процесс долгий. Не зря, обозначая роль Координационного Центра доменов RU/РФ в работе UASG, директор КЦ Андрей Воробьев назвал эту группу «действующей на постоянной основе». Видимо, в обозримом будущем окончательно свои задачи это
сообщество не выполнит.

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •