Skip to main content

Новая информация по проекту обновления ключа для подписания ключей (KSK) корневой зоны

Корпорация ICANN объявила сегодня о том, что не будет обновлять ключ для подписания ключей (KSK) корневой зоны в первом квартале 2018 года.

Мы решили, что пока не располагаем достаточной информацией, что не позволяет нам назначить конкретную дату обновления ключа. При этом мы со всей определенностью заявляем, что корпорация ICANN привержена идее обновления ключа KSK корневой зоны и продолжит обсуждение этого важного процесса с сообществом и сбор мнений и предложений, а также заблаговременно (по меньшей мере за один календарный квартал) уведомит все заинтересованные стороны, когда будет определена дата такого обновления.

Кроме того, мы просим сообщество делиться с нами мнениями и предложениями, чтобы помочь нам определить, если это возможно, надлежащие объективные критерии измерения потенциальных отрицательных последствий обновления ключа KSK корневой зоны для пользователей Интернета, а также допустимые параметры таких критериев, прежде чем будет выполнено обновление ключа. Это соответствует модели работыс участием многих заинтересованных сторон на основе принципа «снизу-вверх», которая с таким успехом применяется в разработке политик ICANN.

27 сентября 2017 года корпорация ICANN объявила о переносе сроков обновления ключа KSK корневой зоны по меньшей мере на один квартал, оставив при этом открытой возможность обновления ключа KSK корневой зоны в первом квартале 2018 года. За прошедшее время мы пришли к пониманию того, что нам понадобится дополнительное время для анализа и подготовки.

В предыдущей публикации мы описали наш анализ информации о конфигурации якорей доверия рекурсивных распознавателей, собранной с использованием протоколов, определенных в стандарте RFC 8145Передача сигналов с информацией о якоре доверия в расширениях безопасности DNS (DNSSEC). Наш анализ выявил, что примерно 4% из приблизительно 12 000 распознавателей, обеспечивающих проверку подлинности DNSSECи включенных в отчетные данные за сентябрь 2017 года, были настроены на работу только с ключом KSK-2010 (сокращенное обозначение используемого сейчас ключа для подписания ключей корневой зоны) и не смогли бы выполнять разрешение запросов DNS после обновления ключа.

Решение корпорации ICANN о переносе сроков обновления ключа было принято исходя из опасений в отношении недостаточного понимания нами причин, по которым такие распознаватели не были настроены должным образом, и необходимости в дополнительном времени для выяснения таких причин.

С того времени мы предприняли попытки связаться с операторами 500 адресов, по которым распознаватели сообщали о конфигурации с поддержкой только ключа KSK-2010 вместо правильной конфигурации, подразумевающей использование как ключа KSK-2010, так и нового ключа для подписания ключей — KSK-2017. В идеале такие попытки выяснения обстоятельств должны были установить набор конкретных причин, по которым используется неправильная конфигурация, что позволило бы обеспечить в дальнейшем обмен информацией и принятие необходимых мер для устранения таких конкретных причин. Однако в конечном итоге такой анализ не позволил прийти к определенным выводам, на которые мы надеялись.

В результате нашей первой попытки связаться с операторами распознавателей мы получили ответы от приблизительно 20% из 500 адресатов. Из тех адресов, с операторами распознавателей по которым нам удалось связаться, 60% относились к диапазонам адресов, которые используются для размещения устройств с динамическими адресами, например, маршрутизаторов широкополосных подключений домашних пользователей и непостоянных виртуальных машин, что делает крайне затруднительным (или и вовсе невозможным) отслеживание таких распознавателей. Примерно 25% адресов соответствовали распознавателям, выполнявшим переадресацию для других распознавателей, сообщавших о конфигурации с поддержкой только ключа KSK-2010. Поскольку адреса таких устройств, сообщавших о неправильной конфигурации, указывали не на фактические исходные распознаватели, делает крайне затруднительным (или и вовсе невозможным) определение фактического исходного адреса распознавателя, сообщающего о поддержке только ключа KSK-2010.

Для выполнения обновления ключа KSK корневой зоны корпорация ICANN должна быть уверена в том, что такое обновление не будет иметь нежелательных отрицательных последствий для пользователей Интернета. Сложности, с которыми мы столкнулись, когда начали анализировать отчеты о конфигурации якорей доверия по RFC 8145, полученные от распознавателей, связаны с оценкой последствий для пользователей.

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

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

Корпорация ICANN будет следить за этим списком рассылки, а начиная с 15 января 2018 года мы подготовим проект плана дальнейших действий в отношении обновления ключа для подписания ключей на основе дискуссии и предложений, полученных в списке рассылки. Этот план будет опубликован не позднее 31 января 2018 года для сбора мнений и предложений в рамках официальной процедуры общественного обсуждения ICANN. На конференции ICANN61, которая пройдет в Сан-Хуане, Пуэрто-Рико, мы проведем специальное заседание, чтобы обсудить этот план и заслушать мнение присутствующих представителей сообщества. Мы намереваемся подготовить доработанный план к рассмотрению сообществом и общественному обсуждению на конференции ICANN62, которая пройдет в г. Панама, Панама, и опубликовать итоговый план вскоре после ее завершения.

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

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."