[ga] FYI Bernstein on DNSSEC

["Joe Baptista" <baptista@xxxxxxxxxxxxxx>]

FYI

---------- Forwarded message ----------
From: D. J. Bernstein <djb@xxxxxxxx>
Date: Sat, Aug 9, 2008 at 8:28 PM
Subject: Re: Kaminsky on djbdns bugs
To: dns@xxxxxxxxxxxxx


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



-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084