Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)

From: Dean Anderson <[email-masked]>
Date: Tue, 12 Aug 2008 12:56:12 -0400 (EDT)

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-masked]>
To: [email-masked]
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 _pFrom [email-masked]  Tue Aug 12 09:56:54 2008
Date: Tue, 12 Aug 2008 12:56:12 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

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-masked]>
To: [email-masked]
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 _pacackets_. 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

kets_. 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Patrik Wallstrom <[email-masked]>
Date: Tue, 12 Aug 2008 20:19:32 +0200

> This message seems to answer many of the questions over the last few

.SE have 922 domains with DS records. The lack of .COM domains is  
probably because .COM is not signed. It is much easier to put a trust  
anchor in your resolver for .SE than to put 70 million trust anchors  
for all .COM domains. I for one is looking forward to what .ORG will  
do to the uplift on signed .ORG domains.

And .SE does not even care about confidentiality, you should probably  
not store things in DNS that are supposed to be secret to begin with.

-- 
patrik_wallstrom->foodfight->[email-masked]>+46-733173956

---

From: Patrik Wallstrom <[email-masked]>
Date: Tue, 12 Aug 2008 20:19:32 +0200