Кратко

  • Редакция draft-ietf-dance-client-auth-14 загружена 11 сентября и остаётся Internet-Draft на стадии Working Group Last Call. Это не RFC и не утверждённый стандарт.
  • Документ называет четыре результата вместо проверенного DNSSEC набора TLSA: сбой проверки, неаутентифицированный ответ, NXDOMAIN и NODATA. Сервер разрывает соединение либо, если разрешает политика, считает клиента неаутентифицированным.
  • Узкая квитанция решения должна сохранять класс DNS, путь доверия, версию политики и последующую авторизацию. Это редакционное предложение, а не требование IETF.

Новая редакция не равна новому статусу

Datatracker датирует 11 сентября 2026 года редакцию 14 документа «TLS Client Authentication via DANE TLSA records». Он принадлежит активной группе DANCE в области безопасности IETF и претендует на статус Proposed Standard. Текущее состояние иное: In WG Last Call, идёт последующая работа ответственного за документ. В IESG указано Waiting for AD Go-Ahead::AD Followup.

Это координаты процесса, не сообщение об утверждении. История показывает редакцию 13 от 23 июля. 28 июля рабочая группа вернула состояние из Submitted to IESG for Publication в In WG Last Call. Редакция 14 принята системой 11 сентября; RFC не опубликован.

Содержательное изменение сосредоточено в одном шаге сервера. Редакция 13 говорила о неудаче проверки DNSSEC. Редакция 14 охватывает любой результат, кроме DNSSEC-проверенного набора TLSA, и перечисляет четыре класса.

Для каждого действует общая развилка. Сервер обязан прекратить соединение с уведомлением TLS handshake_failure либо, когда это допускает его политика, рассматривать клиента как неаутентифицированного. Спецификация точнее определила вход, но не забрала у оператора решение о допустимом риске.

Имя для запроса сообщает клиент

В RFC 6698 и RFC 7671 DANE обычно описывает проверку серверного сертификата или ключа по записи TLSA. Проект DANCE переносит доверие DNS на клиентскую сторону.

Поддерживающий сервер объявляет предлагаемое расширение dane_clientid в CertificateRequest. Клиент, желающий применить DANE, отправляет в сообщении Certificate полное имя владельца своей записи TLSA. Сервер не строит его из порта и транспорта, а запрашивает именно переданное имя. Механизм работает с TLS 1.3 или DTLS 1.3 и более поздними версиями.

Сервер может сам проверить DNSSEC до настроенного якоря доверия, обычно корневого. Другой вариант — довериться валидирующему резолверу по защищённому соединению и потребовать бит AD. Итог может совпасть, но источник доказательства и ответственная сторона будут разными.

На момент исследования в реестре IANA TLS ExtensionType нет видимого значения dane_clientid. Проект тоже пишет о будущем назначении. Нельзя приписывать ему номер, массовое внедрение или поддержку производителей.

Четыре класса требуют разных вопросов

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

Неаутентифицированный ответ из-за неподписанной зоны или небезопасной делегации — другое наблюдение. Здесь нет целой защищённой цепочки, а не обязательно имеется подписанный ответ, который оказался неверным. RFC 4033 разделяет подписанные и неподписанные зоны и ожидания, возникающие от якорей доверия.

NXDOMAIN сообщает, что запрошенного имени нет. NODATA допускает существование имени, но не нужного типа TLSA. Различие, закреплённое обработкой отрицательных ответов в RFC 2308, отделяет удалённую идентичность устройства от имени, для которого ещё не опубликовали учётные данные.

Ни одна категория не является вердиктом о злоумышленнике. Устаревшее имя, намеренно небезопасная делегация, незавершённая публикация и сломанная цепочка — разные гипотезы.

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

После DNS остаются сопоставление и права

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

Успешное сопоставление аутентифицирует клиента в смысле DANE, но не выдаёт права приложения. Сервер может применять списки разрешений, ограничения доменов и собственные правила авторизации. Аутентифицированная идентичность может не иметь доступа; неаутентифицированное соединение может видеть только публичный ресурс.

Модель должна хранить три состояния отдельно: DNS-результат, сопоставление DANE и авторизацию приложения. Один флаг успеха смешивает решения разных владельцев правил.

Квитанция без лишнего наблюдения

Переносить внутреннее расследование в TLS не нужно. Имя клиента может обозначать человека, устройство или роль; раздел безопасности проекта предупреждает о риске корреляции. Подходит локальная защищённая квитанция решения поиска. Это предложение Daniel Kade, не требование IETF, DANCE или IANA.

Квитанция связывает время; разрешённую форму или защищённый хеш переданного имени TLSA; тип запроса; один из четырёх классов; состояние DNSSEC; локальную проверку или защищённый резолвер; ссылку на якорь доверия либо политику разрешения; версию серверной политики; выбранную ветвь. Результат сопоставления сертификата и итоговая авторизация добавляются отдельно, только если выполнение дошло до этих шагов.

Пропущенный шаг помечается не достигнут. После NXDOMAIN нельзя придумывать несовпадение сертификата, а небезопасную делегацию нельзя для удобства называть ложной. Доступ и срок хранения зависят от чувствительности идентичности. Публичный отчёт может показать агрегаты по классам без имён устройств и истории соединений.

Policy Mirror Хэна Лу предлагает проверять актора, правило и доказательство раздельно. Оператор DNS контролирует имя и делегацию, клиент называет искомую идентичность, сервер выбирает проверку и политику TLS, приложение назначает права. Minimum Initial Specification сохраняет будущий выбор благодаря малому общему ядру. Редакция 14 оставляет решение локальным; квитанция лишь не даёт ему утратить наблюдаемое основание.

Источники

  1. IETF Datatracker — draft-ietf-dance-client-auth-14
  2. История документа
  3. Редакция 13
  4. Редакция 14
  5. Рабочая группа DANCE
  6. RFC 6698 — DANE TLSA
  7. RFC 7671 — эксплуатация DANE
  8. RFC 2308 — отрицательное кэширование DNS
  9. RFC 4033 — введение и требования DNSSEC
  10. Реестр IANA TLS ExtensionType
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification