Subject: Trust point removal issue?

From: Mike StJohns <[email-masked]>
Date: Mon, 05 Dec 2005 14:46:56 -0500

I'm soliciting input from the list for the following:

One of the possibilities in the "timers" trust anchor ID is that all 
trust anchors at a trust point can be deleted (e.g. by setting the 
revoke bit on all of the DNSKEY records).  One of the chairs asked me 
to clarify whether or not that resulted in a branch of the tree that 
was "secure" but unverifiable (since there were no trust anchors/root 
keys).  The other option is that the deletion of all the trust 
anchors results in the deletion of the trust point with the branch 
becoming unsecure (not subject to DNSSEC verification).

My personal opinion is that deletion of all of the trust anchors 
should result in deletion of the trust point.  This comes from the 
robustness principle where I'd rather the accidental deletion of the 
root trust anchors not result in a total inability (by secure 
resolvers) to resolve any DNS name.

Any discussion either way?

Mike

--
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: "Scott Rose" <[email-masked]>
Date: Mon, 5 Dec 2005 15:22:08 -0500

> -----Original Message-----
> From: [email-masked]
>

I would agree - deletion of all the trust anchors would move the zone from
"signed" to "unsecure", just as if any other zone lacking a secure entry
point.  No different than a self-signed zone.

At least I'm assuming that is what you are saying.
Scott

---

From: Mike StJohns <[email-masked]>
Date: Mon, 05 Dec 2005 15:52:21 -0500

>At least I'm assuming that is what you are saying.

That's it exactly.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 06 Dec 2005 11:47:15 -0500

>>At least I'm assuming that is what you are saying.

<chair-hat=off>
As far as I can tell there are at least two reasons why a zone may want to
have its trust anchors removed.
1. As you say to for the zone to go insecure, i.e. turn of DNSSEC.

2. When parent signs DS and child zone wants the DS records used, and intents
    to stop signing DNSKEY set including old KSK with the revoke bit set.
    In this case the zone only wants to use the out-of-band parent-child
    DS exchange to change TA/KSK for the zone. Without this one zones that
    start out using TA update nay have to support both DS and TA-update forever
    possibly leading to inconsistencies and errors.

As for other uses, I'm not sure there are none but can not rule them out at
this point, as I only recently realized the need for the second one in the
transition to DS.

Anyone have other usage models?

    Olafur

---

From: Mike StJohns <[email-masked]>
Date: Tue, 06 Dec 2005 12:52:32 -0500

>    possibly leading to inconsistencies and errors.

For this one, I don't think it matters.  Validly 
signed data below a trust point is valid if 
either the DNSKEY RRSet at the trust point is 
signed by a trust anchor OR the DNSKEY RRSet is 
signed by a DNSKEY that's named in a validly 
signed DS RRSet in the parent zone that can 
itself be signature chained back to a valid trust 
anchor.  So you don't actually have to delete the 
trust point to transition from trust point to DS.

Perhaps this needs to be specified more clearly 
in the trust anchor management docs?

Mike