This message seems to answer many of the questions over the last few
days.
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
---------- Forwarded message ----------
Date: 10 Aug 2008 00:28:22 -0000
From: D. J. Bernstein <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Kaminsky on djbdns bugs
Last week's surveys by the DNSSEC developers ("SecSpider") have found a
grand total of 99 signed dot-com names out of the 70 million dot-com
names on the Internet.
Am I the only person amazed by this? We've had fifteen years of
forgeries, fifteen years of concentrated work on DNSSEC, and we can't
even get simple cryptographic signatures deployed. What an embarrassment
for cryptography!
Jos Backus writes:
> http://cr.yp.to/djbdns/forgery.html states:
> "My top priority for djbdns is to support nym-based security."
Hmmm. This reminds me that some web-page updates are overdue; it's time
for me to announce the results of the attacks that the entire Internet
will be panicking about in 2015. :-)
When I wrote that web page several years ago, I focused on deployment
difficulties (which are obviously a huge issue) and delegating security
to poorly managed central Internet servers (which is a big issue for
high-security sites). But there are other reasons, maybe more important
reasons long term, to be dissatisfied with DNSSEC, motivating the
development of DNSSEC2 and DNSSEC3:
* RFC 4033, Section 4: "DNSSEC provides no protection against denial
of service attacks." In fact, DNSSEC makes denial of service even
easier than it was before.
The basic problem is that DNSSEC signs _records_ but provides no
protection for _packets_. After several packets a DNSSEC cache can
see that it doesn't have the expected signatures and that there
must have been forgeries, but the cache simply fails at that point;
it doesn't have any way to find the right data.
With DNSSEC2, every response packet has an immediately and
efficiently verifiable high-security cryptographic signature.
Forged packets are simply discarded.
* RFC 4033, Section 4: "DNSSEC is not designed to provide
confidentiality." DNSSEC doesn't even try to encrypt packets.
In fact, DNSSEC makes private DNS data _much_ easier for attackers
to see than before, because it exposes a huge amount of information
through "NSEC," and creates interoperability failures if NSEC is
disabled. The latest "NSEC3" adds even more complications but does
essentially nothing to repair the privacy leaks; NSEC3 might be
successful at its marketing goal of stopping European privacy
regulators but it will almost never be successful at the security
goal of stopping attackers.
With DNSSEC3, every request and response packet has high-security
encryption and authentication. Both DNSSEC2 and DNSSEC3 completely
avoid the "NSEC" privacy leaks.
* Although the DNSSEC protocol allows some conservative cryptographic
options that won't be broken in the near future, what DNSSEC users
are actually being told to deploy---to partially compensate for
serious speed problems in DNSSEC---is something that big companies
and botnet operators can _already_ break, namely 1024-bit RSA.
We're still years away from a _public_ announcement of a successful
1024-bit RSA factorization, but I think that telling people to use
1024-bit RSA today is completely irresponsible.
These issues are separate from the question of how keys are distributed.
DNSSEC, DNSSEC2, and DNSSEC3 distribute public keys through parent
servers (as simple NS names in the case of DNSSEC2 and DNSSEC3), so of
course the parent servers can substitute any data they want. DNSSEC2 and
DNSSEC3 have the extra option of embedding public keys into URLs so that
parent servers can't do more damage than turning off service.
---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
