DNSSEC Keys - and trying to not leaving them around
torinthiel at data.pl
Wed Jan 12 22:00:14 UTC 2011
On 01/12/11 16:07, Mark Elkins wrote:
> So now I want to resign the zone. Its already signed. How can I do that
> without having to have the Private KSK still around. I'd have thought
> that I'd just perhaps need the Private ZSK around to re-sign new zone
> (here I removed the KSK Private file - 9983)
> I think this works - but I get the message:
> dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading
> private key file example.com/NSEC3RSASHA1/9983: file not found
> So why is dnssec-signzone worried about the private part of a KSK that
> it (I believe) should not need? Bug?
Because it tries to resign whole zone, with new validity period. That's
why it needs KSK. You could try passing it the previously-signed
message, and add -i parameter.
However, see below why this is not necessary a good idea.
> My zone changes quite a bit - so what I was thinking to do is Sign a
> very basic copy of the zone (SOA, NS records - not much else) - then
> move the Private KSK's off the disk completely - then add in my
> "dynamic" data and re-sign as often as I need (whenever my "dynamic"
> data changes) with just my Private ZSK available.
KSK is only used to sign DNSKEY records. SOA, NS and everything else are
signed by ZSK.
> After about 6 month (whatever) - I can then create a new KSK - bring
> back my original 'off-disk' Private KSK - sign a new basic copy of my
> zone - take the two Private KSK's offline and go through the whole KSK
> roll-over process. ie - I only have the private part of the KSK on the
> disk for a very short time - usually its off-site. I should be able to
> generate my very basic zone on a completely different server - perhaps
> not connected to the Internet at all - and just (via USB stick) copy
> over the basic signed zone every six months?
You definitely can generate signatures offline. That's what's done for
the root zone.
But watch for one thing. You don't need to change KSK every time you
re-sign your zone. Changing the KSK requires some good timing, changing
the DS records in parent zone (if you publish them, and good odds that
you don't control the parent zone, only have some web/email/phone
interface to change your record) and informing all DLV repositories you
might be in and everyone that has configured your key as a trust anchor.
That's not something you want to do often.
What you also don't want, is long signature periods. Why? Because for as
long as a signature is valid, an attacker can pretend to anyone in the
Internet that your zone hasn't changed. E.g. you move your web server
from 18.104.22.168 to 22.214.171.124, update zone files, test that it works. But an
attacker has your older A and RRSIG records, and can present them to
someone in place of your correct answers. The receiver sees this
response, verifies RRSIG (it validates, after all you've created it) and
believes you still have 126.96.36.199 address.
Now, thin about what happens if the DNSKEY record gets attacked this
way, and you've changed it because your ZSK got stolen. As long as
signature is valid you're vulnerable.
Better, generate a range of signatures for DNSKEY with your KSK, say one
for each month' and keep those RRSIGs secret for now. Guard them the
same way you guard ZSK, but in different place, and release them into
the zone file only when needed. That way if ZSK gets compromised you
just scrap those signatures, generate new ZSK and new signatures.
Just don't put those signatures with ZSK. It it gets compromised so do
the signatures, and you're screwed.
More information about the bind-users