RFC 7858 · май 2016
Спецификация DNS поверх Transport Layer Security (TLS)
Авторы: Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels и P. Hoffman. Категория: процесс стандартизации; ISSN 2070-1721; май 2016.
Аннотация
Настоящий документ описывает использование Transport Layer Security (TLS) для обеспечения конфиденциальности DNS. Шифрование TLS исключает возможность прослушивания DNS-запросов в сети и их подмены на пути передачи, как, например, описано в RFC 7626. Кроме того, документ определяет два профиля использования DNS поверх TLS и содержит рекомендации по производительности, позволяющие уменьшить накладные расходы при использовании TCP и TLS для DNS.
В соответствии с задачами рабочей группы DPRIVE документ сосредоточен на защите трафика между конечным DNS-клиентом и рекурсивным резолвером. Это не исключает применения протокола в будущем для трафика между рекурсивным и авторитетным серверами.
Статус документа
Это документ процесса стандартизации Интернета.
Документ подготовлен Инженерной группой Интернета (IETF). Он отражает консенсус сообщества IETF, прошёл публичное обсуждение и одобрен к публикации Руководящей группой инженерных работ Интернета (IESG). Дополнительные сведения о стандартах Интернета приведены в разделе 2 RFC 5741.
Информация о текущем статусе документа, исправлениях и порядке отправки отзывов доступна по адресу http://www.rfc-editor.org/info/rfc7858.
Уведомление об авторских правах
Copyright (c) 2016 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
На документ распространяются BCP 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действовавшие на дату публикации. Внимательно ознакомьтесь с ними: они описывают ваши права и ограничения в отношении документа. Компоненты кода, извлечённые из документа, должны включать текст Упрощённой лицензии BSD, как описано в разделе 4.e Правовых положений Trust, и предоставляются без гарантий согласно Упрощённой лицензии BSD.
1. Введение
В настоящее время почти все DNS-запросы [RFC1034] [RFC1035] передаются без шифрования. Это позволяет злоумышленнику, имеющему доступ к сетевому каналу, прослушивать их и снижает конфиденциальность отправителя. Недавние сообщения в прессе усилили эти опасения; в последних работах IETF рассмотрены вопросы конфиденциальности DNS [RFC7626].
Предыдущие работы затрагивали отдельные аспекты безопасности DNS, но до недавнего времени конфиденциальности между DNS-клиентом и сервером уделялось мало внимания. Расширения безопасности DNS (DNSSEC) [RFC4033] обеспечивают целостность ответов: определяют механизмы криптографической подписи зон, позволяющие конечным пользователям или их ближайшему резолверу проверять правильность ответов. По замыслу DNSSEC не защищает конфиденциальность запросов и ответов. Традиционно конфиденциальность либо не считалась требованием к DNS-трафику, либо предполагалось, что сетевой трафик достаточно защищён от наблюдения. Однако недавние события меняют эти представления [RFC7258].
Другие работы, предлагающие возможность шифрования между DNS-клиентами и серверами, включают DNSCurve [DNSCurve], DNSCrypt [DNSCRYPT-WEBSITE], Confidential DNS [CONFIDENTIAL-DNS] и IPSECA [IPSECA]. Помимо настоящей спецификации рабочая группа DPRIVE приняла предложение DNS поверх Datagram Transport Layer Security (DTLS) [DNSoD].
Документ описывает использование DNS поверх TLS на общеизвестном порту и рекомендации по производительности, уменьшающие накладные расходы при применении TCP и TLS для DNS.
Установление DNS поверх TLS устроено просто. Устанавливая соединение на общеизвестном порту, клиент и сервер ожидают и согласуют TLS-сеанс для защиты канала. Внедрение будет постепенным: не все серверы поддерживают DNS поверх TLS, а некоторые межсетевые экраны могут блокировать общеизвестный порт. Предполагается, что клиенты будут запоминать, какие серверы поддерживают TLS, а какие нет. Клиенты и серверы будут следовать рекомендациям по реализации TLS и положениям о безопасности [BCP195].
Описанный протокол работает для запросов и ответов между конечными клиентами и рекурсивными серверами. Он может работать и между рекурсивными клиентами и авторитетными серверами, но такое применение выходит за рамки текущего устава рабочей группы DNS PRIVate Exchange (DPRIVE).
В разделе 4 описаны два профиля, обеспечивающие разные уровни уверенности в конфиденциальности: оппортунистический профиль и профиль с закреплением ключа, полученного по внешнему каналу. Ожидается, что будущий документ на основе [TLS-DTLS-PROFILES] подробнее опишет дополнительные профили конфиденциальности DNS как поверх TLS, так и поверх DTLS.
В более раннем проекте документа описывался способ повышения DNS-соединения поверх TCP до сеанса DNS поверх TLS — по существу, «STARTTLS для DNS». Для упрощения протокола в этой редакции использование TLS определяется только общеизвестным портом; подход с повышением уровня соединения исключён. Документ сосредоточен исключительно на использовании общеизвестного порта для DNS поверх TLS.
2. Ключевые слова
Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL в документе следует толковать согласно RFC 2119 [RFC2119].
3. Установление сеансов DNS поверх TLS и управление ими
3.1. Инициация сеанса
По умолчанию DNS-сервер с поддержкой DNS поверх TLS ОБЯЗАН (MUST) прослушивать порт 853 и принимать TCP-соединения на нём, если только у него нет взаимной договорённости с клиентами об использовании другого порта для DNS поверх TLS. Для использования другого порта клиентскому и серверному программному обеспечению необходима возможность соответствующей настройки.
По умолчанию DNS-клиент, которому требуется конфиденциальность DNS поверх TLS при работе с определённым сервером, ОБЯЗАН (MUST) устанавливать TCP-соединение с портом 853 этого сервера, если только они взаимно не договорились об использовании другого порта. Такой другой порт НЕ ДОЛЖЕН (MUST NOT) быть портом 53, но МОЖЕТ (MAY) принадлежать диапазону портов, выделяемых в порядке поступления заявок. Рекомендация не использовать порт 53 для DNS поверх TLS призвана избежать сложностей с выбором использования TLS и снизить риск атак с понижением уровня защиты. Первым обменом данными в этом TCP-соединении ОБЯЗАТЕЛЬНО (MUST) должно быть начало TLS-рукопожатия клиентом и сервером согласно процедуре [RFC5246].
DNS-клиенты и серверы НЕ ДОЛЖНЫ (MUST NOT) использовать порт 853 для передачи открытых DNS-сообщений. DNS-клиенты НЕ ДОЛЖНЫ (MUST NOT) отправлять, а DNS-серверы НЕ ДОЛЖНЫ (MUST NOT) отвечать на открытые DNS-сообщения на любом порту, используемом для DNS поверх TLS, в том числе после неудачного TLS-рукопожатия. Смешение защищённых и незащищённых данных создаёт серьёзные проблемы безопасности; поэтому TCP-соединения на порту, который сервер выделил для DNS поверх TLS, предназначены исключительно для зашифрованной связи.
DNS-клиентам СЛЕДУЕТ (SHOULD) запоминать IP-адреса серверов, не поддерживающих DNS поверх TLS, включая случаи тайм-аута, отказа в соединении и неудачного TLS-рукопожатия, и не запрашивать у них DNS поверх TLS в течение разумного периода, например часа для каждого сервера. DNS-клиенты, использующие профиль с закреплением ключа, полученного по внешнему каналу (раздел 4.2), МОГУТ (MAY) чаще повторять попытки после ошибок соединения DNS поверх TLS.
3.2. TLS-рукопожатие и аутентификация
После успешного TCP-подключения к общеизвестному порту DNS поверх TLS клиент переходит к TLS-рукопожатию [RFC5246], следуя лучшим практикам [BCP195].
Затем клиент при необходимости аутентифицирует сервер. Документ не предлагает новых методов аутентификации. В зависимости от используемого профиля конфиденциальности (раздел 4) DNS-клиент может не требовать аутентификации сервера или использовать доверенный набор закреплённых отпечатков Subject Public Key Info (SPKI).
После согласования TLS соединение шифруется и защищено от прослушивания.
3.3. Отправка и получение сообщений
Все сообщения — запросы и ответы — в установленном сеансе TLS ОБЯЗАНЫ (MUST) использовать двухбайтовое поле длины, описанное в разделе 4.2.2 [RFC1035]. Для эффективности DNS-клиентам и серверам СЛЕДУЕТ (SHOULD) передавать двухбайтовое поле длины и описываемое им сообщение уровню TCP одновременно, например одним системным вызовом write. Это повышает вероятность передачи всех данных одним TCP-сегментом ([RFC7766], раздел 8).
Чтобы уменьшить задержку, клиентам СЛЕДУЕТ (SHOULD) конвейерно отправлять несколько запросов в одном TLS-сеансе. Отправляя серверу несколько запросов, DNS-клиенту не следует ждать ответа на предыдущий запрос перед отправкой следующего ([RFC7766], раздел 6.2.1.1).
Поскольку ответы на конвейерные запросы могут приходить не по порядку, клиенты ОБЯЗАНЫ (MUST) сопоставлять ответы с ожидающими запросами в том же TLS-соединении по идентификатору сообщения Message ID. Если ответ содержит раздел Question, клиент ОБЯЗАН (MUST) сопоставить поля QNAME, QCLASS и QTYPE. Неправильное сопоставление ответов с ожидающими запросами может иметь серьёзные последствия для совместимости ([RFC7766], раздел 7).
3.4. Повторное использование, закрытие и восстановление соединения
Известно, что существующие реализации DNS-клиентов, использующих библиотечные функции вроде getaddrinfo() и gethostbyname(), открывают и закрывают TCP-соединение для каждого DNS-запроса. Чтобы избежать избыточного числа TCP-соединений с одним запросом в каждом, клиентам СЛЕДУЕТ (SHOULD) повторно использовать одно TCP-соединение с рекурсивным резолвером. Альтернативно они могут использовать UDP для обращения к поддерживающему DNS поверх TLS кэширующему резолверу на той же машине, который затем использует общее системное TCP-соединение с рекурсивным резолвером.
Чтобы распределить затраты на установление TCP- и TLS-соединений, клиентам и серверам НЕ СЛЕДУЕТ (SHOULD NOT) закрывать соединение сразу после каждого ответа. Вместо этого им СЛЕДУЕТ (SHOULD) использовать существующие соединения для последующих запросов, пока достаточно ресурсов. В некоторых случаях для этого придётся некоторое время держать неактивные соединения открытыми.
Правильное управление установленными и простаивающими соединениями важно для нормальной работы DNS-сервера. Разработчику DNS поверх TLS СЛЕДУЕТ (SHOULD) соблюдать лучшие практики DNS поверх TCP, описанные в [RFC7766]. Несоблюдение может привести к исчерпанию ресурсов и отказу в обслуживании.
Хотя реализации клиентов и серверов времён [RFC1035], как известно, плохо управляют TCP-соединениями, этот документ устанавливает: успешное согласование TLS свидетельствует о готовности обеих сторон держать неактивные DNS-соединения открытыми независимо от тайм-аутов и других рекомендаций для DNS поверх TCP без TLS. Иными словами, предполагается, что программное обеспечение, реализующее протокол, поддерживает постоянные простаивающие соединения и готово управлять несколькими потенциально долгоживущими TCP-соединениями.
Документ не рекомендует конкретных тайм-аутов неактивных соединений. Клиентам и серверам следует повторно использовать и/или закрывать соединения в зависимости от доступных ресурсов. Тайм-ауты могут быть длиннее в периоды низкой активности и короче в периоды высокой. Текущие работы в этой области также могут помочь клиентам и серверам DNS поверх TLS выбрать подходящие значения [RFC7828] [TDNS].
Клиенты и серверы, оставляющие неактивные соединения открытыми, ОБЯЗАНЫ (MUST) устойчиво обрабатывать закрытие такого соединения любой стороной. Как и в существующем DNS поверх TCP, DNS-серверы МОГУТ (MAY) закрыть соединение в любое время, например из-за ограниченных ресурсов. Клиенты ОБЯЗАНЫ (MUST) обрабатывать внезапные закрытия и быть готовыми восстановить соединение и/или повторить запросы.
При восстановлении закрытого соединения DNS поверх TCP, как описано в [RFC7766], полезен TCP Fast Open [RFC7413]. Подчёркивая требование передавать на порту DNS поверх TLS только зашифрованные DNS-данные (раздел 3.2): при использовании TCP Fast Open клиент и сервер ОБЯЗАНЫ (MUST) немедленно начать или возобновить TLS-рукопожатие; обмен открытыми DNS-данными ЗАПРЕЩЁН (MUST NOT). DNS-серверам СЛЕДУЕТ (SHOULD) включить быстрое возобновление TLS-сеанса [RFC5077], и его СЛЕДУЕТ (SHOULD) использовать при восстановлении соединений.
При закрытии соединения DNS-серверам СЛЕДУЕТ (SHOULD) использовать TLS-запрос close-notify, чтобы перенести состояние TCP TIME-WAIT на клиентов. Дополнительные требования и рекомендации по оптимизации DNS поверх TCP приведены в [RFC7766].
4. Профили использования
Протокол достаточно гибок для нескольких сценариев. Документ определяет два профиля: (1) оппортунистическую конфиденциальность и (2) аутентификацию с закреплением ключа, полученного по внешнему каналу. Второй профиль обеспечивает более строгие гарантии конфиденциальности, если клиент состоит в доверительных отношениях с поддерживающим TLS DNS-сервером. Дополнительные методы аутентификации будут определены в будущем документе [TLS-DTLS-PROFILES].
4.1. Профиль оппортунистической конфиденциальности
При оппортунистической конфиденциальности, аналогичной оппортунистической безопасности SMTP [RFC7435], конфиденциальность желательна там, где она возможна, но не является обязательной.
При таком подходе клиент может узнать о поддерживающем TLS рекурсивном DNS-резолвере из недоверенного источника. Например, клиент может получить IP-адрес поддерживающего TLS рекурсивного резолвера через параметр DNS-сервера DHCP [RFC3646], а затем попытаться использовать DNS поверх TLS на порту 853. При работе с таким обнаруженным сервером клиент может проверять подлинность резолвера или не делать этого. Эти варианты повышают доступность и производительность, но оставляют клиента уязвимым для атак на пути передачи, устраняющих конфиденциальность.
Оппортунистическую конфиденциальность может использовать любой существующий клиент, но она обеспечивает конфиденциальность только при отсутствии активных злоумышленников на пути передачи.
4.2. Профиль с закреплением ключа, полученного по внешнему каналу
Профиль применим там, где между DNS-клиентами и серверами уже существуют доверительные отношения, например между конечными клиентами и рекурсивными серверами корпоративной сети, в рамках действующего договора на обслуживание или при использовании клиентом публичного DNS-резолвера. Подключаясь только к серверам, подлинность которых клиент способен подтвердить, он получает строгие гарантии конфиденциальности DNS-данных. Предполагается, что операторы DNS поверх TLS предоставляют закрепляемые значения, относящиеся именно к данному сервису: публичные ключи самого конечного узла либо частного удостоверяющего центра конкретного сервиса, а не ключи общего публичного удостоверяющего центра.
В этом профиле клиенты аутентифицируют серверы путём сопоставления набора отпечатков SPKI способом, аналогичным описанному в [RFC7469]. Администраторам клиентов СЛЕДУЕТ (SHOULD) развёртывать резервное закреплённое значение вместе с основным по причинам, изложенным в [RFC7469]. Резервное значение особенно полезно при смене ключа: оператору сервера не придётся одновременно согласовывать переход со всеми клиентами. После смены серверных ключей обновлённый набор закреплённых значений СЛЕДУЕТ (SHOULD) безопасным способом распространить всем клиентам в подготовку к будущей смене ключей. Механизм обновления этого набора по внешнему каналу выходит за рамки документа.
Такой клиент использует только DNS-серверы, для которых предоставлен набор закреплённых отпечатков SPKI. Наличие заранее установленного доверенного набора позволяет обнаруживать и предотвращать атаки посредника и атаки с понижением уровня защиты.
Однако настроенный DNS-сервер может быть временно недоступен при настройке сети. Например, в сетях с обязательной аутентификацией через веб-страницу такая аутентификация может зависеть от перехвата и подмены DNS. При настройке сети МОГУТ (MAY) применяться методы, подобные используемым DNSSEC-trigger [DNSSEC-TRIGGER], с последующим переходом к назначенному DNS-провайдеру после аутентификации. Когда это возможно, пользователя ОБЯЗАТЕЛЬНО (MUST) следует предупреждать, что DNS на этапе первоначальной настройки не является конфиденциальным.
После успешного TLS-соединения и рукопожатия клиент вычисляет отпечатки SPKI для публичных ключей из проверенной цепочки сертификатов сервера или из открытого ключа, если сервер предоставляет его вместо цепочки. Если вычисленный отпечаток в точности совпадает с одним из настроенных закреплённых значений, клиент продолжает соединение обычным образом. В противном случае он ОБЯЗАН (MUST) считать неудачную проверку SPKI неисправимой ошибкой. Подробный пример такой аутентификации приведён в приложении A.
Реализации этого профиля ОБЯЗАНЫ (MUST) поддерживать вычисление отпечатка как хеша SHA-256 [RFC6234] от DER-кодированного представления ASN.1 поля SPKI сертификата X.509. Реализации ОБЯЗАНЫ (MUST) поддерживать представление отпечатка SHA-256 в виде строки, закодированной base64 [RFC4648]. Они также МОГУТ (MAY) поддерживать другие типы отпечатков.
5. Вопросы производительности
DNS поверх TLS добавляет задержку при установлении сеанса, требует дополнительного состояния в памяти и увеличивает нагрузку на процессор.
Задержка. По сравнению с UDP, DNS поверх TCP требует дополнительного времени кругового обмена (RTT) для установления TCP-соединения. При наличии информации от предыдущих соединений TCP Fast Open [RFC7413] позволяет устранить этот RTT. TLS-рукопожатие добавляет ещё два RTT задержки. Клиентам и серверам следует поддерживать сохранение и повторное использование соединений и обработку не по порядку, чтобы распределить затраты на установление соединения. Быстрое возобновление TLS-соединения [RFC5077] дополнительно уменьшает задержку установления и избавляет DNS-сервер от необходимости хранить состояние сеанса отдельно для каждого клиента.
TLS False Start [TLS-FALSESTART] также может уменьшить задержку в некоторых ситуациях. Реализации с поддержкой TLS False Start должны учитывать дополнительные ограничения использования TLS сверх указанных в [BCP195]. Использовать False Start небезопасно, если реализация и развёртывание не соблюдают эти конкретные требования. Подробности дополнительных ограничений приведены в [TLS-FALSESTART].
Состояние. TCP с установлением соединения требует хранить дополнительное состояние на сервере как в ядре, так и в приложении. Требования к состоянию особенно значимы для серверов с большим количеством клиентов, хотя реализация TLS с оптимизацией памяти может добавить к TCP лишь умеренный объём состояния. Меньшие тайм-ауты сокращают число одновременных соединений; серверы могут упреждающе закрывать соединения при превышении пределов ресурсов.
Обработка. Использование алгоритмов шифрования TLS несколько повышает нагрузку на процессор. Серверы могут отказывать новым клиентам DNS поверх TLS при превышении ограничений вычислительной мощности.
Число соединений. Чтобы уменьшить объём состояния на DNS-серверах и время установления соединения, клиентам СЛЕДУЕТ (SHOULD) минимизировать создание новых TCP-соединений. Использование локального агрегатора DNS-запросов — определённого типа пересылателя — позволяет иметь одно активное соединение DNS поверх TLS от каждого клиентского компьютера к его серверу. Дополнительные рекомендации приведены в [RFC7766].
Полная оценка производительности выходит за рамки спецификации. Более подробный анализ влияния DNS поверх TLS и DNS поверх TCP на производительность приведён в [TDNS] и [RFC7766].
6. Вопросы IANA
IANA добавила следующее значение в системный диапазон «Реестра имён служб и номеров портов транспортных протоколов». Для этого диапазона реестр требует проверки IETF или одобрения IESG [RFC6335]; такая проверка была запрошена через процедуру предварительного выделения [RFC7120] для указанного в документе общеизвестного порта TCP.
IANA зарезервировала тот же номер порта UDP для предложенного протокола DNS поверх DTLS [DNSoD].
Имя службы: domain-s Номер порта: 853 Транспортные протоколы: TCP/UDP Ответственный: IESG Контакт: председатель IETF Описание: протокол запросов и ответов DNS поверх TLS/DTLS Ссылка: настоящий документ
7. Развитие проекта
В ранних версиях проекта документа предлагалось устанавливать TLS-сеанс путём повышения уровня существующего соединения. Клиент сигнализировал бы о заинтересованности в TLS установкой бита «TLS OK» в поле флагов механизмов расширения DNS (EDNS(0)). Сервер подтверждал бы согласие ответом с установленным битом TLS OK.
Поскольку предполагалось, что клиент не хочет раскрывать информацию до защиты канала, предлагалось использовать для этого «фиктивный запрос». Предлагались имя запроса STARTTLS, тип TXT и класс CH.
Сигнализация TLS OK имеет достоинства и недостатки. Важное достоинство — возможность согласования TLS клиентом и сервером. Если сервер слишком занят или не хочет предоставлять TLS определённому клиенту, он может отрицательно ответить на проверочный запрос TLS. Дополнительная польза — серверы могли бы собирать информацию о распространённости DNS поверх TLS по биту TLS OK в запросах ещё до реализации и развёртывания. Другим ожидаемым преимуществом была возможность работы DNS поверх TLS на порту 53: не пришлось бы «расходовать» ещё один порт и вводить новые правила межсетевых экранов на промежуточных устройствах.
Однако оставалось неясно, будут ли промежуточные устройства пропускать бит TLS OK, поскольку поле флагов EDNS0 не менялось много лет. Другой недостаток — бит TLS OK мог бы облегчить атаки с понижением уровня защиты, неотличимые от неисправности промежуточного устройства. С точки зрения производительности подход с повышением уровня соединения требовал дополнительной задержки в один RTT для фиктивного запроса.
После этого предложения отдельно предложили DNS поверх DTLS. Утверждалось, что DNS поверх DTLS способен работать на порту 53, но только потому, что сервер без DTLS трактует запрос DNS поверх DTLS как ответ: он видит флаг QR, установленный в 1. Хотя технически это работает, такой результат представляется неудачным и, возможно, нежелательным.
Для DNS как поверх TLS, так и поверх DTLS полезен единый общеизвестный порт: он позволяет избежать дополнительной задержки и ошибочной трактовки запросов как ответов.
8. Вопросы безопасности
DNS поверх TLS предназначен для снижения рисков конфиденциальности, возникающих из-за возможности прослушивания DNS-сообщений. Он не решает остальные проблемы безопасности DNS; остаётся ряд рисков, способных повлиять на эффективность защиты конфиденциальности:
1. Известны атаки на TLS, включая атаку посредника и понижение уровня протокола. Это общие атаки на TLS, не специфичные для DNS поверх TLS; их обсуждение приведено в RFC о TLS. Клиенты и серверы ОБЯЗАНЫ (MUST) соблюдать рекомендации по реализации TLS и положения безопасности [BCP195]. Если DNS-клиенты запоминают серверы, поддержка TLS которыми известна, они могут обнаруживать атаки с понижением уровня защиты. Для серверов, с которыми нет истории соединений и которые явно не поддерживают TLS, клиент в зависимости от профиля и требований конфиденциальности может: (a) попробовать другой доступный сервер, (b) продолжить без TLS или (c) отказаться отправлять запрос.
2. В некоторых сетях присутствуют промежуточные устройства [RFC3234], которые, как известно, могут мешать обычному разрешению DNS. Выделенный порт DNS поверх TLS должен предотвращать такое вмешательство. Как правило, клиенты, у которых попытка TLS не удалась, в зависимости от своего профиля и требований конфиденциальности могут вернуться к незашифрованному DNS либо подождать и повторить попытку позже.
3. Любое взаимодействие по DNS в открытом виде может изменить злоумышленник-посредник. Например, незашифрованные запросы и ответы между клиентом и сервером могут передаваться через порт 53. Поэтому клиенты МОГУТ (MAY) отбрасывать кэшированные сведения о возможностях сервера, объявленные в открытом виде.
4. Сам документ не предлагает способов противодействия известному анализу трафика или утечкам по сторонним каналам. Даже при зашифрованных сообщениях удачно расположенный наблюдатель может извлечь некоторые сведения, анализируя время передачи и размеры сообщений. Для устранения утечек из-за размеров сообщений клиенты и серверы могут рассмотреть дополнение сообщений padding [RFC7830]. Поскольку анализ трафика может основываться на разных типах закономерностей и классификаторов, одних простых схем дополнения может быть недостаточно для противодействия такой атаке. Однако дополнение войдёт в состав более сложных средств защиты от анализа трафика, которые, вероятно, будут разработаны со временем. Разработчики, способные обеспечить гибкость использования дополнения, смогут лучше подготовиться к внедрению таких средств в будущем.
Как отмечалось ранее, DNSSEC и DNS поверх TLS — независимые и полностью совместимые протоколы, каждый из которых решает свои задачи. Использование одного не уменьшает необходимости или полезности другого.
9. Ссылки
9.1. Нормативные ссылки
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015,
<https://www.rfc-editor.org/info/bcp195>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<http://www.rfc-editor.org/info/rfc7766>.
9.2. Информационные ссылки
[CONFIDENTIAL-DNS]
Wijngaards, W. and G. Wiley, "Confidential DNS", Work in
Progress, draft-wijngaards-dnsop-confidentialdns-03, March
2015.
[DNSCRYPT-WEBSITE]
Denis, F., "DNSCrypt", December 2015,
<https://www.dnscrypt.org/>.
[DNSCurve] Dempsky, M., "DNSCurve: Link-Level Security for the Domain
Name System", Work in Progress, draft-dempsky-dnscurve-01,
February 2010.
[DNSoD] Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", Work in Progress, draft-ietf-dprive-dnsodtls-06,
April 2016.
[DNSSEC-TRIGGER]
NLnet Labs, "Dnssec-Trigger", May 2014,
<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[IPSECA] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A.
Mohaisen, "Opportunistic Encryption with DANE Semantics
and IPsec: IPSECA", Work in Progress,
draft-osterweil-dane-ipsec-03, July 2015.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<http://www.rfc-editor.org/info/rfc3234>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003,
<http://www.rfc-editor.org/info/rfc3646>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016,
<http://www.rfc-editor.org/info/rfc7828>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016,
<http://www.rfc-editor.org/info/rfc7830>.
[TDNS] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
and N. Somaiya, "Connection-Oriented DNS to Improve
Privacy and Security", 2015 IEEE Symposium on Security and
Privacy (SP), DOI 10.1109/SP.2015.18,
<http://dx.doi.org/10.1109/SP.2015.18>.
[TLS-DTLS-PROFILES]
Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
Work in Progress, draft-ietf-dprive-dtls-and-tls-
profiles-01, March 2016.
[TLS-FALSESTART]
Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", Work in Progress,
draft-ietf-tls-falsestart-02, May 2016.
Приложение A. Пример профиля конфиденциальности с закреплением ключа, полученного по внешнему каналу
В разделе приведён пример практического применения профиля с минимальным набором из двух закреплённых значений.
Клиентская DNS-система настроена сетевой службой на использование профиля с закреплением ключа, полученного по внешнему каналу; набор содержит два закреплённых значения. В представлении HTTP Public Key Pinning (HPKP) [RFC7469] это:
pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI=" pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="
Клиент также настраивает IP-адреса ожидаемого DNS-сервера, например 192.0.2.3 и 2001:db8::2:4.
Клиент подключается к одному из этих адресов на TCP-порт 853 и начинает TLS-рукопожатие: согласование TLS 1.2 с обменом ключами Диффи — Хеллмана. Сервер отправляет сообщение с тремя сертификатами A, B и C и корректно подписывает сообщение ServerKeyExchange с помощью ключа, соответствующего открытому ключу сертификата A.
Клиент вычисляет хеш SHA-256 от SPKI сертификата A и сравнивает его с обоими закреплёнными значениями из набора. Если совпадает любое из них, проверка успешна; клиент продолжает TLS-соединение и может отправить первый DNS-запрос.
Если ни одно из значений не совпадает с SPKI сертификата A, клиент проверяет, действительно ли сертификат A выдан сертификатом B. Если да, он вычисляет хеш SHA-256 от SPKI сертификата B и сравнивает его с обоими закреплёнными значениями. Если совпадает любое из них, проверка успешна. В противном случае клиент проверяет, выдан ли B сертификатом C, а затем сравнивает закреплённые значения с хешем SPKI сертификата C.
Если ни одно SPKI в криптографически действительной цепочке сертификатов не совпадает ни с одним значением из набора, клиент закрывает соединение с ошибкой и помечает IP-адрес как неработающий.
Благодарности
Авторы благодарят Stephane Bortzmeyer, John Dickinson, Brian Haberman, Christian Huitema, Shumon Huque, Simon Joseffson, Kim-Minh Kaplan, Simon Kelley, Warren Kumari, John Levine, Ilari Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei Tatuya, Tim Wicinski и Glen Wiley за рецензирование спецификации. Авторы также благодарят Nikita Somaiya за раннюю работу над этой идеей.
Работа Zi Hu, Liang Zhu и John Heidemann над документом частично финансировалась Управлением науки и технологий Министерства внутренней безопасности США (DHS), Агентством перспективных исследовательских проектов в сфере внутренней безопасности (HSARPA), подразделением кибербезопасности, BAA 11-01-RIKA, и информационным управлением Исследовательской лаборатории ВВС по соглашению FA8750-12-2-0344 и контракту D08PC75599.
Участники
Следующие лица внесли значительный вклад в документ:
Sara Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
Email: sara@sinodun.com URI: http://sinodun.com
Daniel Kahn Gillmor ACLU 125 Broad Street, 18th Floor New York, NY 10004 United States
Адреса авторов
Zi Hu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States
Phone: +1-213-587-1057 Email: zihu@outlook.com
Liang Zhu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States
Phone: +1-310-448-8323 Email: liangzhu@usc.edu
John Heidemann USC/Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 United States
Phone: +1-310-822-1511 Email: johnh@isi.edu
Allison Mankin Independent
Phone: +1-301-728-7198 Email: Allison.mankin@gmail.com
Duane Wessels Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
Phone: +1-703-948-3200 Email: dwessels@verisign.com
Paul Hoffman ICANN
Email: paul.hoffman@icann.org
Перевод: RFCNET · rfcnet.ru
Original copyright notice
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Неофициальный перевод. При расхождениях см. оригинал.