Re: DNSSEC Deployment

[Jason Frisvold <frisvolj () LAFAYETTE EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mike,

I believe we met at NANOG46 in Philly.

On 05/17/2010 02:53 PM, Michael Sinatra wrote:
> System and network load aren't much of an issue.  As I have said in
> public presentations on the subject, it has taken the world so long to
> deploy DNSSEC that hardware has more than caught up with the additional
> resource load.

Are you serving a lot of DNSSEC data, though?  ie, will it scale?

> The issue that you need to watch for is the additional complexity in
> maintaining up-to-date signatures on all of the records in your zones.
> Your signing process will need to be automated, and how that is done
> (and with what success) heavily depends on how you currently manage DNS.

I've heard multiple answers with respect to this signing.  The initial
answer I was given was that zones needed to be re-signed every 30 days.
 Subsequent answers seem to indicate that the 30-day time period is
variable and up to my comfort level.  Regardless, a re-signing period is
required.

> You are not.  There is nothing about signing the EDU zone that requires
> you to deploy DNSSEC in any way.

Let me rephrase..  The apparent uptick of DNSSEC deployment (ie, roots
serving DNSSEC now) seems to indicate that DNSSEC will be a worldwide
standard.  Given the current momentum, it seems inevitable that
deployment is necessary.

> I am interested in the source of your skepticism, and this being a
> security list, it's probably a good venue to discuss it.  What's on your
> mind?

I am *NOT* an expert on DNSSEC, so please correct any boneheaded
comments I make.  :)  Most of this information comes with very limited
research and lots of "overheard" information from a variety of sources.

Much of this is likely fear at the unknown and lack of information.  To
begin with, BIND seems to be the software of choice.  My comfort level
with BIND is rather low given past problems with security.  I realize it
was re-built from the ground up, so these fears may be unfounded at this
point.  That said, we do use BIND here.

The signing structure is a source of concern as well.  As I understand
it, the key you use to sign your zones is supposed to be signed by the
TLD which is then signed by the root.  My expectation is that there will
be a cost associated with this signing, as well as a time period for
re-signing.  EDUCAUSE will "own" the key for .edu, so this may not be a
huge issue in the educational sector, but in the commercial sector this
is a huge source of concern for me.  If DNSSEC becomes "required," then
this is another source of income drain for smaller entities.  This is a
bit outside of the scope of this list, but still a concern.

I think one of the biggest sources of my skepticism is the "sky is
falling" attitude I'm seeing everywhere concerning DNS.  Since the
"Kaminsky" vulnerability, which was nothing more than a combination of
two very old vulnerabilities coupled with increases in computing power,
there has been this movement to push DNSSEC.  Lots of handwaving, lots
of "end of the internet" speeches, etc.  I am fully aware of cache
poisoning and the problems associated with it.  But given these
"imminent" threats, I have yet to see any high-profile cases involving
cache poisoning.  In my experience, it seems that whenever there is a
lot of handwaving and rushing to "secure" things, there is typically no
imminent threat, but often a fairly large chunk of cash that someone is
eager to get their hands on.

I have seen a few presentations on problems with DNSSEC.  For instance,
from what I understand, it is fairly simple to use DNSSEC as a DDoS
amplifier.  Send a small request with a forged source and the resulting
data, which seems to be several times larger than the request, is sent
to the forged source.

Another example is that DNSSEC verification actually allows forged
packets.  The verification part only verifies the source of the packet,
not the data in the packet.  So, if an attacker can intercept a DNS
reply packet, they can replay that packet to a given resolver and modify
the payload, adding NS+A records at-will.  Where's the security again?

I realize there's a lot to learn here, but just looking at the current
standard and what the intended implementation is, I'm still not sure
this is something I want to actively implement until there's more
information available.  If and when we implement additional DNS
security, I want it to be the right choice, implemented the right way.

You seem to be pretty well versed in DNSSEC, so I look forward to your
insight.

> michael

- --
- ---------------------------
Jason Frisvold
Network Engineer
frisvolj () lafayette edu
- ---------------------------
"What I cannot create, I do not understand"
   - Richard Feynman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvxoW4ACgkQO80o6DJ8UvloMQCeNR//6cMLglitQLFd3as1vdTe
GCQAn3ny4z+Z43wM7Ed3z3nAq84MhYkQ
=7st7
-----END PGP SIGNATURE-----