Может кто-нибудь проинформирован, дайте пространный ответ о различиях и преимуществах / недостатках обоих подходов?
Я не специалист по DNS, не программист. У меня есть приличное базовое понимание DNS и достаточно знаний, чтобы понять, как работают такие вещи, как баг каминского. Насколько я понимаю, DNSCurve имеет более надежное шифрование, намного проще в настройке и в целом является лучшим решением.
DNSSEC излишне сложен и использует взломанное шифрование, однако он обеспечивает сквозную безопасность, чего нет в DNSCurve. Однако многие из прочитанных мною статей, похоже, указывают на то, что сквозная безопасность мало полезна или не имеет никакого значения.
Так что же правда? Какое решение лучше или каковы недостатки / преимущества каждого из них?
редактировать:
Я был бы признателен, если бы кто-нибудь мог объяснить, что достигается за счет шифрования содержимого сообщения, когда целью является аутентификация, а не конфиденциальность.
Доказательство того, что ключи являются 1024-битными ключами RSA, Вот.
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:
Чтобы представить себе это в перспективе, для взлома 1024-битного ключа RSA, по оценке Касперского, потребуется около 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 чрезвычайно хорошо разработан для обеспечения обратной совместимости с каналом.
Я пришел к выводу, что DNSCurve - лучший вариант.
Так как:
DNSSEC использует для подписи 1024-битные ключи RSA, которые в 2003 году уже считались нерушимыми в крупных сетях, ботнетах. Этот случай актуален и сегодня.
Для правильной реализации необходимо переписать большую часть кода.
Корневые серверы не подписывают полную базу данных, не обеспечивая полной защиты.
Возможны повторные атаки до 30 дней после истечения срока действия домена.
Для обеспечения безопасности необходимо раскрыть все доменные имена.
DNSCurve не имеет этих проблем и обеспечивает аутентификацию, доступность и конфиденциальность (например, отсутствие необходимости раскрывать имена) в отличие от DNSSEC. Кроме того, он не требует модификации кода, только дополнительное программное обеспечение.
Он также имеет защиту от поддельных пакетов, чего нет в DNSSEC, а также защиту от атак повторного воспроизведения из-за использования одноразовых номеров. DNSCurve может подвергаться атаке MITM, в отличие от DNSSec, но я понимаю, что если бы DNSCurve был реализован полностью до корня, этого не было бы.