Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
ML-DSA для DNSSEC
IANA уже выделила для ML-DSA-44 номер 18 в индексе криптосистем DNSSEC. ML-DSA – это постквантовая криптосистема подписи, родственная ML-KEM, а цифры 4 в обозначении – это идентификатор используемого набора параметров, самого “короткого”. Применение данной квантовостойкой криптосистемы в DNSSEC описано в свежем черновике RFC (Westerbaan/Schmieg), и проверка ML-DSA-подписей уже есть в DNS-сервисе 1.1.1.1. Пример DNS-зоны с ML-DSA-подписью: only.alg18.westerbaan.name. (Большая редкость, понятно.)
Конкретно с этим алгоритмом основная проблема в том, что пусть 44-й вариант и самый “короткий”, но подпись всё равно занимает 2420 байта, а открытый ключ – 1312 байтов. То есть, для передачи данных всё равно потребуется TCP. Естественно, поддержка TCP необходима для работы DNS, но UDP всё ещё остаётся основным транспортом для простых DNS-ответов. Впрочем, возможно, что внедрение посткантовых криптосистем окончательно UDP вытеснит (конечно, UDP – быстрый протокол, но и для TCP есть Fast Open).
Тут можно заметить, что если у вас используется сервис DNS (рекурсивного резолвера) типа 1.1.1.1, то, скорее всего, к нему ваш системный резолвер уже и так подключается по TCP. И действительно, нынче сетевые реалии таковы, что DNS over TLS становится необходимостью, из-за подмены DNS-трафика. Ну а где TLS – там всё равно TCP. Однако не забывайте, что здесь речь-то идёт не о подключении клиента к рекурсивному резолверу, не о “последней миле”, а о том, как резолвер подключается к авторитативным серверам, о “внешем плече”. И вот там, чтобы получить ответ с ключами (DNSKEY) и подписями (RRSIG) ML-DSA, потребуется получить от авторитативных серверов по несколько килобайт данных. Если сравнить с ECDSA, то и трафик увеличивается в десятки раз, и TCP приобретает дополнительный вес. Ну и в типичной конфигурации валидацию DNSSEC-записей выполняет внешний резолвер, не системный.
Занятно, что внедрение ML-DSA в DNSSEC для зон ниже корневой, при том, что в корневой зоне используется не постквантовая криптосистема, – смысла имеет не так много, как можно подумать. Конечно, можно наладить собственную валидацию и проверять конкретные подписи, а ключам верить по значению. Но это не совсем то, чего ожидают от глобального дерева DNSSEC. А в корневой зоне сейчас RSA, а переходить – планируют на ECDSA.
Адрес записки: https://dxdt.blog/2026/09/08/19155/
Похожие записки:
- Starlink и взаимодействие с наземными GSM-сетями
- Let's Encrypt и сертификат для IP-адреса
- DNS и TCP
- Сертификаты Let's Encrypt на шесть дней
- TLS и подмена сертификата на jabber.ru
- Метки и окрашивание контента от LLM-систем
- ML-KEM и скорость вычислений
- Короткоживущие сертификаты dxdt.blog - месяц работы
- ОС Android и новые требования к регистрации
- Реплика: мониторинг и HTTPS без домена
- WhatsApp и E2E-защита сообщений
Новый
Написать комментарий