DNSCurve против DNSSEC

DNSCurve обеспечивает фактическое шифрование для пакетов DNS, хотя и только на основе скачкообразной перестройки и, в частности, на скачке между рекурсивным сервером и полномочным сервером.

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

DNSSEC, с другой стороны, предоставляет сквозную проверяемую криптографическую подпись, которая доказывает, что полученные данные такие же, как на авторитетном сервере. DNSSEC использует криптографические методы, но фактически не шифрует трафик DNS.

Использование DNSCurve алгоритмов шифрования эллиптических кривых позволяет использовать гораздо меньшие ключи, чем с RSA, для достижения того же уровня криптографической стойкости. Однако есть предложения включить подобные алгоритмы в список, предполагаемый DNSSEC.

DNSSEC стандартизирован IETF (RFC 4034 и RFC 4035, обновлен RFC 5155) и реализован в нескольких очень популярных реализациях серверов имен, включая BIND (конечно) и NSD/Unbound. PowerDNS получит поддержку DNSSEC очень скоро.

DNSSEC, по общему признанию, сложен, но продолжаются усилия по его упрощению (см., Например, http://opendnssec.org/), и развертывание постоянно увеличивается. Различные TLD (.se, .br, .org, .gov и т. Д.) Уже подписаны DNSSEC, и было объявлено, что корневой зоной будет DNSSEC, подписанная к концу года.

DNSCurve довольно интересен, но благодаря независимому способу его разработки у него очень мало шансов увидеть какое-либо значительное развертывание. ИМХО у него нет шансов когда-либо быть развернутым на корневых серверах.

Кстати, ваше утверждение о DNSSEC с использованием "взломанного шифрования" представляется совершенно необоснованным. На каком основании вы говорите это?

Ключи подписи зоны обычно (но не обязательно) имеют длину 1024 бита. Эти ключи обычно меняются каждый месяц или около того, и в настоящее время наилучшие оценки состоят в том, что для перебора 1024-битного ключа потребуется не менее пары лет.

На данный момент атака грубой силы против 1024-битного RSA потребует около двух лет на несколько миллионов вычислительных ядер и много десятков гигабайт памяти на процессор или материнскую плату.

что не совсем ваш типичный ботнет. Из той же статьи:

Далее, рассматривая оборудование специального назначения, наиболее оптимистичный подход предполагает, что просеивание для 1024-битного модуля RSA может быть выполнено в течение года примерно за 10 000 000 долларов США плюс единовременные затраты на разработку около 20 000 000 долларов США при сопоставимых затратах времени и средств. для матрицы. По нашему мнению, (общий) скептицизм, с которым встречаются такие замыслы, не относится к делу. Такие цифры не следует интерпретировать как верхние границы, т. Е. "Будьте осторожны, 1024-битный RSA может быть сломан за два года примерно за двадцать миллионов долларов (при условии свободного развития)", но как нижние границы, то есть "нет причин для беспокойства слишком много: даже при очень благоприятных условиях атаки факторинг 1024-битного модуля RSA по-прежнему требует огромных ресурсов ". Таким образом, оценки должны восприниматься не как угрожающие, а как внушающие доверие.

Или из годичной статьи PCPro:

Чтобы оценить это, взломать RSA-1024-битный ключ, по оценкам Касперского, потребуется около 15 миллионов компьютеров, работающих безуспешно в течение года, чтобы добиться успеха.

Честно говоря, никто не собирается вкладывать столько усилий в взлом ZSK одного домена!

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

Комментарий к заявлениям LWN

DNSCurve защищает канал, а не сообщение. Он не может использоваться для защиты от вредоносных кешей и не является функциональным эквивалентом DNSSEC.

и ссылки на обсуждение на французском языке.

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

Основное различие между DNSSec и DNSCurve состоит в том, что DNSSec подписывает все, существует четкая цепочка доверия от корня до записей хоста, предоставляемых DNS-серверами каждого оператора.

DNSCurve НЕ подписывает ничего, что вообще не имеет цепочки доверия. Целью DNSCurve является предотвращение пассивной или слепой постановки ответов DNS.

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

DNSCurve даже не пытается.

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

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

На мой взгляд, все, что нужно, - это решение DNS, которое по меньшей мере столь же надежно, как и основной транспорт. Он должен практически предотвращать определение DNS-записей злоумышленниками, которые слепо вводят ложные сообщения или пассивно сниффируют запросы и подделывают UDP-ответы. Не нужно гарантировать безопасность сверх этого. Таким образом, Интернет продолжает маршрутизировать пакеты и предоставлять услуги DNS надежным, но не обязательно безопасным способом.

DNSSec и его якоря глобального доверия, на мой взгляд, являются глупым поручением, которое почти полностью сосредоточено на решении проблемы, которой не существует. (Все конечные системы шифрования, которые можно использовать через Интернет, уже имеют свои собственные методы проверки личности)

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

DNSCurve защищает сеть таким образом, чтобы служба именования была, по крайней мере, такой же надежной, как и основная передача пакетов по сети, но не в большей степени. На мой взгляд, это решает именно ту проблему, с которой на самом деле сталкиваются в реальном мире. DNSCurve предотвращает пассивное MITM, но практически не защищает от активного MITM без кэширования подписи в стиле ssh "скачок веры".

Чтобы сыграть в защиту дьяволов, широкомасштабное развертывание DNSSec может иметь положительные последствия. Инфраструктура PKI может заменить безопасные серверы CA SSL и обеспечить некоторую доверительную привязку для IPSec и других зашифрованных разговоров между узлами.

Честно? Ни один из них не достаточно хорош. DNSSEC разваливается под собственным весом: он слишком сложен, полон дыр и, вероятно, никогда не будет работать должным образом. DNSCurve хорош в том, что он делает, но недостаточно далеко. Проще подключиться к DNS-серверу, но из-за того, как он был написан и продвигается, вероятно, никогда не увидит широкого применения.

Я предпочел бы развернуть DNSCurve, чем DNSSEC, на моем собственном (рекурсивном) DNS-сервере, но только потому, что DNSCurve более четко говорит о том, что он может и не может делать, и не дает ложного чувства безопасности, как DNSSEC - много умные люди думают, что DNSSEC достаточно хорош, а это не так.

Я догадываюсь, что в войнах за безопасность DNS еще впереди, и мы, вероятно, увидим третий вариант. Надеемся, что он будет построен на DNSCurve, так как я думаю, что DNSCurve чрезвычайно хорошо спроектирован для обеспечения защиты канала обратно совместимым образом.