Кратко

  • В draft-ietf-dance-client-auth-14 клиент TLS 1.3 передаёт полное имя владельца TLSA; сервер запрашивает это имя, проверяет DNSSEC и сопоставляет запись с сертификатом или необработанным открытым ключом.
  • Успех доказывает ограниченную связь DNS и ключа. Текущее назначение, allowlist сервера, разрешение приложения и наблюдаемый итог требуют отдельных подтверждений.

Сервер сначала помещает пустое dane_clientid в CertificateRequest. Клиент отвечает в Certificate полным именем своего TLSA. Сервер ничего не достраивает и задаёт DNS именно этот вопрос. Проверенный DNSSEC RRset и хотя бы одно совпадение TLSA показывают, что другая сторона контролирует соответствующий закрытый ключ.

Но эта квитанция не подтверждает, что имя по-прежнему закреплено за тем же устройством, сотрудником или организацией. Она не включает локальный список допуска и тем более не решает, может ли приложение выполнить конкретную операцию. Сам проект оставляет allowlisting и authorization политике сервера.

Текущий статус не равен принятию

Версия 14 датирована 11 сентября 2026 года. Datatracker называет её активным Internet-Draft группы DANCE с предполагаемым статусом Proposed Standard. Второй IETF Last Call завершается 29 сентября. Это не RFC и не свидетельство внедрения.

Security Directorate присвоил результат Ready с небольшими замечаниями. DNS Directorate присвоил Not ready: формы _service и _device не выполняют требование RFC 8552 о регистрации имён с подчёркиванием, а описание текстового ClientName и предела 255 октетов остаётся спорным. Оба заключения — часть актуальной картины.

Где заканчивается доказательство

Клиентские имена могут быть сервисными, устройственными или свободными. TLS переносит полное имя, но не определяет его административный смысл. DNSSEC подтверждает данные под цепочкой доверия, а не реальную принадлежность метки.

Сервер проверяет ответ до настроенного trust anchor либо доверяет защищённо подключённому валидирующему резолверу и AD bit. Неподписанный ответ, небезопасная делегация, ошибка DNSSEC, NXDOMAIN и NODATA не создают аутентифицированный набор TLSA.

DANE-EE 3 прямо сопоставляет ключ и не требует имени в сертификате. DANE-TA 2 и PKIX 0/1 требуют также совпадения ClientName с dNSName SAN по RFC 7671. Необработанные ключи используют RFC 7250. Эти варианты меняют путь аутентификации, но не власть приложения.

Для аудита нужны отдельные записи о ClientName, DNS и TTL, валидаторе, trust anchor, полях TLSA, сертификате или SPKI, назначении имени, состоянии учётной записи/устройства, allowlist, решении приложения и результате. DNS-кэш может пережить переназначение. TLS может пройти, а приложение отказать. Разрешённая операция может завершиться ошибкой.

TLS 1.3 шифрует Certificate, но последующий DNS-запрос способен раскрыть имя. Минимизация QNAME по RFC 9156 уменьшает раскрытие. Наблюдение запроса не доказывает компрометацию.