Re: DNSSEC Deployment

[Michael Sinatra <michael () RANCID BERKELEY EDU>]

On 05/17/10 13:05, Jason Frisvold wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Mike,
>
> I believe we met at NANOG46 in Philly.

Yep, I remember.

> 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?

I am serving all of berkeley.edu and about 95+% of its subdomains, plus
32.128.in-addr.arpa, 229.169.in-addr.arpa, and 152.136.in-addr.arpa.  It
has roughly doubled the memory footprint of BIND on our authoritative
servers, which is still well within their capacity.

See the graphs in this presentation
(http://events.internet2.edu/2010/jt-slc/agenda.cfm?go=session&id=10000979&event=1111)

> > 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 set the signature interval, just like you set the TTL.  So you could
make it as long as 30 days or as short as 4-5 days.  Cryptographically,
you don't want to go much longer than 30 days.

> > 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.

Okay, got it.

> > 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.

There is also an entire suite of tools from NLnetlabs, that is
completely different from the BIND codebase.  But if you already use
BIND, it's probably better to stick with it.

The issue of software that has evolved since the early days of the
Internet is a tricky one.  I am more interested in how many eyeballs are
looking at the code now, rather than what has happened in the past.
It's not easy for me to explain, but I am less convinced by discussions
of past vulnerabilities than with what the code looks like now.

> 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 am not following this.  There are usually two keys that you use to
sign your zones.  Those keys are self-signed.  A digest of one of the
keys is placed in the parent zone, and that digest (DS record) is signed
by the parent.  In this way, the chain of trust is maintained.  You
appear to be comparing DNSSEC with the way X.509 signatures are
maintained, and that is not the way that DNSSEC works.  The only "hard"
part is placing the DS record in the parent and I know of no plans to
charge for this.  The only cost is the effort to do the work to get the
DS record into EDU, *and* to make sure that it's right.

> 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.

That's not really an accurate characterization.  What Kaminsky taught us
was that it is much, much easier to poison caches than we previously
thought, regardless of computing power.  Moreover, computing power
*does* come into play when discussing the quick band-aids that were put
into place to protect against Kaminsky (source-port randomization,
query-id randomization).  We have no more bits to play with on either of
those, so our only hope to keep ahead of the randomization curve is to
hope for universal deployment of IPv6, so we can extract some of the
entropy from randomizing over 2^n source IP(v6) addresses!  (No, I am
not totally serious about that, but it *would* work.)

> 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.

This is probably a legitimate concern, and I do see a lot of the DNS
appliance vendors saying, "gosh, DNS sure is getting hard--you should
really outsource it to us."

See
http://www.cricketondns.com/post.cfm/my-theory-which-is-to-say-the-theory-that-is-mine

Knowing that Cricket works for Infoblox, one *could* argue that it's an
attempt to argue for precisely the types of products that Infoblox
sells.  (I don't totally agree with that assessment, but I can see how
one might come to that conclusion.)

> 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.

This isn't new with DNSSEC, and DNSSEC won't stop it.  DNSSEC arguably
puts more data in the DNS, but there are other things that do that too.
 (DKIM, anyone?)  Moreover, closing open resolvers made this much less
effective.  Using authoritative servers for the same thing won't get you
the 1000+-fold increase in amplification that using open resolvers once
would.

> 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.

Exactly the opposite.  Are you thinking of DNSCurve?

> 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?

This is not an attack you can do with DNSSEC, unless the stub resolver
is not validating and you are doing a MITM attack between the caching
resolver and the client.  That's a lot harder than just poisoning a big
juicy cache.  It can easily be mitigated by the use of TSIG or SIG(0),
or by making the stub resolver do (additional) validation.  Again this
is an implementation issue, and it only involves securing the last inch
of the chain.

> 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.

And there really is no rush.  The point of having early adopters is to
see what works from an implementation perspective and what doesn't.
However, there do need to be early adopters, and there's an argument to
be made that EDUs (still) need to be among that group.  Otherwise, the
debate really does amount to little more than handwaving on both sides.

michael