DNSCurve против DNSSEC

DNSCurve против DNSSEC

Может ли кто-нибудь из информированных лиц дать развернутый ответ о различиях и преимуществах/недостатках обоих подходов?

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

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

Так что же верно? Какое решение лучше или каковы недостатки/преимущества каждого из них?

редактировать:

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

Доказательство того, что ключи являются 1024-битными ключами RSA,здесь.

решение1

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

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

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 довольно интересен, но из-за независимого способа его разработки у него очень мало шансов увидеть какое-либо значительное внедрение. IMHO, оннульвероятность когда-либо быть развернутым на корневых серверах.

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

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

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

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

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

Или от годовалого ребенкаСтатья PCPro:

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

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

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

решение2

Акомментарий к LWNпретензии

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

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

решение3

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

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

DNSCurve НЕ подписывает ничего, нет никакой цепочки доверия. Фокус DNSCurve сужен до предотвращения пассивного или слепого подстраивания ответов DNS.

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

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

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

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

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

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

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

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

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

решение4

Я пришел к выводу, что DNSCurve — лучший вариант.

Потому что:

DNSSEC использует 1024-битные ключи RSA для подписи, которые уже в 2003 году считались невзламываемыми крупными сетями, ботнетами. Это актуально и сегодня.

Для корректной реализации придется переписать большую часть кода.

Корневые серверы не подписывают всю базу данных, не обеспечивая полной защиты.

Возможны повторные атаки в течение 30 дней после истечения срока действия домена.

Для обеспечения безопасности необходимо раскрыть все доменные имена.

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

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

Связанный контент