Re: ttl problems in DNSSEC

[Olaf Kolkman <OKolkman@ripe.net>]

 * > I think this would be heading in the wrong direction.  When retiring a key
 * > you want to remove the signatures, not perpetuate them.
 * 
 * Depends on the reason:
 * 
 * Key compromise: Right.  The compromised key should not be used to sign
 * things nor advertised [by the real owner].

Hmm we just wrote something different in the the resolver-rollover
draft. We've suggested to use the compromised key to sign a new ZONE
keyfile; as a mechanism to limit the damage.

Let me expand on the idea a little. Bare with me though, this is (a
maybe wild) idea that I want to open up to critique...


Suppose "The evil person who goes by many names but we call him Harry"
has compromised a key of Alice's zone.

That zone is used as a secure entry point for Bob's verifying resolver
(trusted-key in BIND).

If Bob allows auto reconfiguration of trusted-keys of resolvers then
within the refresh interval of Alice's Zone, Bob will pick up the key
set, which can be verified against the old key set by virtue of the
signature.

Now that does not buy Bob real security, Harry can also use the
resolver rollover mechanism to reconfigure Bob's trusted keys. But if
Bob gets Alice's data before Harry's he is safe again. So Harry must
proceed within the refresh time of Alice's or make sure that Alice's
new KEYset does not get propagated over the net; Harry uses a DOS
attack for that.

During the DOS attack Harry can try to spoof Alice's server(s) and
attack Bob. It will however be very difficult for Harry to attack all
the resolvers that have Alice's key configured (Bob's cousins). I
think that would be possible by rerouting DNS traffic, which can be
trace more easily than a DOS attack. If a resolver that does automatic
rollover of trusted keys cannot get to the keyset within an EXPIRE
time interval the zone administrator MUST be warned. If Alice's
server is under a DOS attack most of Bob's cousins will get a warning.

As said Bob is not really secured if he is under attack from Harry but
Bob's cousins might slip through. It's damage limitation.

Since Alice will not know where Bob cousins are (anybody might have
configured the .com or the .nl KEY as trusted-key) there is no way the
message that Alice's key is compromised can be pushed to Bob and
cousins.

 * 
 * <snip>
 * 
 * One conclusion is that key compromises cannot in general be detected
 * until TTLs have expired, but this is hardly a surprise I think.  This
 * may be one reason to use a low TTL on KEY records.

For parent-child trust it is the TTL of the signature over the childs
Key (or the Delegation record) that sets the time a compromised child
key can be used.

The TTLs on SIGs buy you security, not the TTL on KEYs. 

 * Another conclusion is that we should decide if key-rollover using two
 * keys is worth the extra administrative burden (i.e. if it should be
 * recommended practice). 

If there is a zone has a parent one will need a short period (order
TTLs) that there are two keys, otherwise the chain of trust might be
broken during a rollover. If a zone does not have a parent but is used
as a secure entry point you can in principle replace keys. (You have
to make sure though that all resolvers which have your key as
'trusted-key' have the new key configured)

 * It might be possible to design resolvers etc
 * to handle this situation correctly instead, but this require more
 * complexity in software and slightly more trafic when keys are changed.
 *
 * I dunno which is worse.

Me neither :-).


--Olaf

P.S. I'll be  enjoying holidays until July 30. So I won't be able to
follow the discussion on this thread and others. I hope to catch up
before the IETF but I am eager to share ideas in the London Hilton
Hallways....