Subject: RE: 3 comments on timers-03

From: "Scott Rose" <[email-masked]>
Date: Thu, 27 Jul 2006 14:40:22 -0400

> -----Original Message-----
> From: Robert Story [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2006 7:11 PM
> MS>
> MS> You definitely don't want to delete a trust anchor from a set just
> MS> because it's missing once.
>
> Isn't this exactly the attack vector described in the first
> paragraph of section 2.1?
>
> The corner case that bugs me with the timers draft is if an
> attacker manages to get a new key into a published DNSKEY RRSet and it
> goes unnoticed for the add hold-down period. Resolvers will consider it
> a valid trust anchor. When the operator notices this and re-publishes,
> they can omit the bad key, but not revoke it. Resolvers that have
> the bad key will continue to trust it until the remove hold-down timer
> expires.
>

Maybe, but that is a corner case.  After thinking about it some more, I
believe most cases where a "missing" trust anchor appears is when a zone
joins a chain of trust.  That is, a zone decides to stop publishing their
own trust anchor and relies on a superior zone as the secure entry point.

Instead of doing the correct revocation procedure, they only delete it, thus
producing the missing state in the resolver/validator.

Scott

> --
> Robert Story
> SPARTA

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mike StJohns <[email-masked]>
Date: Thu, 27 Jul 2006 23:45:53 -0400

After further thought on this, I believe the current approach is the 
less problematic approach.  The corner case Robert cites is at least 
one of the reasons I designed the system as is - under the "missing 
(eventually)  equals revoked" scenario, if a rogue anchor can become 
trusted, then possession of the rogue key is may be sufficient to 
delete all the other trust anchors.   (There's a whole load of timing 
things and keeping the resolver from seeing contrary data, but the 
deletion is at least possible.)

Mike