Subject: [dnsext] How are people implementing hold-down in RFC 5011?

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Oct 2014 10:13:30 -0700

Greetings. In reading RFC 5011 more carefully, I am finding that some of the wording is confusing (possibly just to me). I have a few questions for people who have implemented it in systems, but also want to hear from the greater DNS community.

Section 2.2 says:

   Assume two trust point keys A and B.  Assume that B has been
   compromised.  An attacker could generate and add a new trust anchor
   key C (by adding C to the DNSKEY RRSet and signing it with B), and
   then invalidate the compromised key.  This would result in both the
   attacker and owner being able to sign data in the zone and have it
   accepted as valid by resolvers.

I am assuming that "invalidate" means "revoke". Pictorially, I think this means the following progression in time:
   1: Owner's zone: A signs (A B)
   2: Attacker's zone: B signs (A Br C)
(Here, "Br" means "B with the REVOKE bit set".)

Immediately after the relying party has seen (2), B can never be trusted again, even while they are waiting for the hold-down timer for adding C.

Later in Section 2.2, it says:

   In the given example, the zone owner can recover from a compromise by
   revoking B and adding a new key D and signing the DNSKEY RRSet with
   both A and B.

The time progression here sounds like:
   1: Owner's zone: A signs (A B)
   2a: Attacker's zone: B signs (A Br C)
   2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D)
2a happens before 2b because that is how the owner discovers that B was compromised.

I don't understand why B signs (A D) in 2b. B is already untrusted to anyone who saw 2a, and is untrusted by anyone looking at all of 2b. These instructions seem to be saying "put a signature into the zone that cannot be validated". I would think that 2b should just be "B signs (Br) and A signs (A D)", but that's not what the RFC says.

So: has anyone implemented what the RFC says? If so, did you try it with some validating resolvers? What were the results?

Or: am I completely misreading something in this section?

--Paul Hoffman

---

From: Michael StJohns <[email-masked]>
Date: Tue, 07 Oct 2014 16:03:53 -0400

At 01:13 PM 10/7/2014, Paul Hoffman wrote:
>I am assuming that "invalidate" means "revoke". 

Yes.  

>Pictorially, I think this means the following progression in time:

1.5 Attacker's zone: B signs (B C)
(This has to happen for the Add Hold down time until C becomes a valid trust anchor.  In general this is going to be B and C sign (B, C) for the hold down period).

>(Here, "Br" means "B with the REVOKE bit set".)

2 is actually B and C sign (Br C).

>Immediately after the relying party has seen (2), B can never be trusted again, even while they are waiting for the hold-down timer for adding C.

Revocation takes place immediately.  Once the bit is set and validly signed, the key is revoked and can't be used for anything except signing the revocation.  So in B and C sign (Br C), the signature over the keys by B only has impact on Br,  The signature by C over the keys only has impact if C has already been added to the validators trust anchor set.

>2a happens before 2b because that is how the owner discovers that B was compromised.

What happens at a validator depends on what the validator sees.  In general this goes:

A Signs (A B)
B is compromised
Owner:  A and B sign (A Br D) - B is revoked and D starts its process of being added as a trust anchor.
Attacker:  B signs (B C)

The key point is that if the validator sees even one of the "A and B sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail validation leading to C not being added to the trust anchor set.

>I don't understand why B signs (A D) in 2b. B is already untrusted to anyone who saw 2a, and is untrusted by anyone looking at all of 2b. These instructions seem to be saying "put a signature into t…

You can't actually have two different versions of the DNSKEY RRSet being simultaneously offered by a single responder.  You *can* have multiple signatures over a single DNSKEY RRSet.

So the above is actually "A and B sign (A Br D)".  It's also actually more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs.  So you get "B signs Br to revoke itself", "A signs D to add D to the trust anchor set" and "A signs Z so that Z chains to the root of trust".  

That's expressed by a DNSKEY RRSet consisting of B with the revoke bit, D with the SEP bit and Z without the SEP bit with two RRSIG(DNSKEY) records consisting of a signature by A and  a signature by B.

Mike

>_______________________________________________
>dnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsext

---

From: Michael StJohns <[email-masked]>
Date: Tue, 07 Oct 2014 16:10:41 -0400

>So the above is actually "A and B sign (A Br D)".  It's also actually more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs.  So you get "B signs Br to revoke itself", "A signs D to add…

Sorry - 

This is actually "A and B sign (A Br D and Z)".

A signing key needs to be included in the DNSKEY RRSet even if its already accepted as a trust anchor.  That's mainly so the key id reference of the RRSIG (DNSKEY) can find the appropriate public key for validation. 

Mike

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Oct 2014 16:57:25 -0700

Thanks for the clarifications. I still have a bunch of questions, and I really do wonder if implementers agree with your interpretations.

> (This has to happen for the Add Hold down time until C becomes a valid trust anchor.  In general this is going to be B and C sign (B, C) for the hold down period).

There is nothing in the quoted paragraph from the RFC that indicates that the attacker gets C to be a valid trust anchor. It sounds like you meant to say "the attack is only going to work if a relying party trust C, and that will only happen after the hold-down period, so the attacker first introduces C, then only that has succeeded for some desired targets, revokes B".

> 2 is actually B and C sign (Br C).

When the RFC says "and signing it with B", it might be clearer if it says "and signing it with B and C". It is far from clear which messages from the attacker are for public consumption (which would be seen by the zone owner) and which are meant for restricted relying parties. 

> Revocation takes place immediately.  Once the bit is set and validly signed, the key is revoked and can't be used for anything except signing the revocation.  So in B and C sign (Br C), the signatu…

Yup.

> The key point is that if the validator sees even one of the "A and B sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail validation leading to C not being added to the trust anch…

Yes, that's clearly the intent, and it should work (assuming that the resolver follows the "revoke B as soon as you see a B-signed-Br anywhere" rule).

> A signing key needs to be included in the DNSKEY RRSet even if its already accepted as a trust anchor.  That's mainly so the key id reference of the RRSIG (DNSKEY) can find the appropriate public k…

Why D? Is it a replacement for B because 5011 works better with more than one trust anchor? I didn't see anything in the section that explained D, and from what you say above, it looks like I guessed wrong the first time.

--Paul Hoffman

---

From: Michael StJohns <[email-masked]>
Date: Thu, 09 Oct 2014 12:46:57 -0400

>There is nothing in the quoted paragraph from the RFC that indicates that the attacker gets C to be a valid trust anchor. It sounds like you meant to say "the attack is only going to work if a relyi…

The add hold down time is meant to provide some breathing room for the owner against an attacker adding a new trust anchor.  If the attacker holds only one key (B), and the owner doesn't revoke it, then eventually the attacker can add a new trust anchor (C).  The incantation for the attacker is "B and C sign (B C X)" where X is a ZSK key owned by the attacker.   The moment that the owner sees something it hasn't itself signed, signed with B, then the owner should issue "A and B sign (A, Br, D, Z)" where D is the owner's replacement for B and where Z is a ZSK key owned by the owner.

Any SEP key can become a trust anchor if it is validly signed and is in the DNSKEY RRSet for the add hold down time (plus one retrieval).

>When the RFC says "and signing it with B", it might be clearer if it says "and signing it with B and C". It is far from clear which messages from the attacker are for public consumption (which would…

That's not actually a matter of concern for the zone owner.   The incantation to revoke a key K is "K signs (Kr)".  As I noted elsewhere, you can't actually have multiple disjoint DNSKEY RRSets for a given name, so that you end up doing a union of all the keys to be signed into a single DNSKEY RRSet and you provide signatures by all signers over all the keys.

With respect to the relying party - he doesn't know and can't tell - who originated the DNSKEY and signature data he's seeing.  It's a crap shoot as to which version of the "truth" (owner or attacker) he sees.  The 5011 model is designed to make it as difficult as possible for an attacker to feed its version of truth to a specific validating resolver for a long enough period of time so that resolver installs a new trust anchor AND never sees the revocation of the compromised trust anchor.

>Yes, that's clearly the intent, and it should work (assuming that the resolver follows the "revoke B as soon as you see a B-signed-Br anywhere" rule).

I can't help it if they don't read the black and white text of 5011.  

>   A key is considered revoked when the resolver sees the key in a
>   self-signed RRSet and the key has the REVOKE bit (see <http://tools.ietf.org/html/rfc5011#section-7>Section 7
>   below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
>   NOT use this key as a trust anchor or for any other purpose except to
>   validate the RRSIG it signed over the DNSKEY RRSet specifically for
>   the purpose of validating the revocation.  Unlike the 'Add' operation
>   below, revocation is immediate and permanent upon receipt of a valid
>   revocation at the resolver.

>Why D? Is it a replacement for B because 5011 works better with more than one trust anchor? I didn't see anything in the section that explained D, and from what you say above, it looks like I guesse…

Yes, D is the owner's replacement for B.    I don't name the keys as "C" and "D" in section 6.1, but that's what's happening.

You used "C" as the "Attacker's new trust anchor" in this series of messages.  I probably would have used something more disjoint in the explanation.

So to clarify.

1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand for any of the regularly generated ZSKs)
2) B is a stand by key - it's a trust anchor, but not used for regular quarterly signing
3) The normal DNSKEY RRSet is "A signs (A Z)"
4) If A or B is compromised then generate a new key pair C
5) Assuming A is compromised issue a new RRSET  "A and B sign (Ar B C Z)"  and propagate that for twice the add hold down time.  (the add hold down time to get the bits set, the additional time to pick up stragglers - the additional time is just suspenders and belt)
6) Once you've done (5) for long enough, issue a new "normal" RRSET "B signs (B Z)".  C is now a standby key.

In practice, it may take a little time to get folks together for the key ceremony for C, so you may end up with an interim DNSKEY RRSet "A and B sign (Ar B Z)" for a few days.  [Which by itself suggests a need to be able to do signatures without having everyone physically present]

In the above, the attacker's only ploy is to do "A signs (A N X)" where N is a new trust anchor key owned by the attacker and X is a new ZSK also owned by the attacker.  His hope is that the validly signed (by compromised key A) RRSet gets accepted for a short while by specific targets and maybe long enough to get a new trust anchor key accepted by those specific targets.

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 13 Oct 2014 10:59:54 +0200

Hi,

On 09-10-14 18:46, Michael StJohns wrote:
>> Thanks for the clarifications. I still have a bunch of questions, and
>> I really do wonder if implementers agree with your interpretations.

I have implemented this (http://nlnetlabs.nl/projects/autotrust/) and I 
agree with Michael's interpretations (even if it was after an hour 
asking questions at some past IETF).

I am trying to clarify below, although most stuff seems already 
straighted out.

>> >> Greetings. In reading RFC 5011 more carefully, I am finding that
>> some of the wording is confusing (possibly just to me). I have a few
>> questions for people who have implemented it in systems, but also want
>> to hear from the greater DNS community.
>> >>
>> >> Section 2.2 says:
>> >>
>> > (This has to happen for the Add Hold down time until C becomes a
>> valid trust anchor.  In general this is going to be B and C sign (B,
>> C) for the hold down period).
>>
>> There is nothing in the quoted paragraph from the RFC that indicates
>> that the attacker gets C to be a valid trust anchor. It sounds like
>> you meant to say "the attack is only going to work if a relying party
>> trust C, and that will only happen after the hold-down period, so the
>> attacker first introduces C, then only that has succeeded for some
>> desired targets, revokes B".
>
>
> The add hold down time is meant to provide some breathing room for the
> owner against an attacker adding a new trust anchor.  If the attacker
> holds only one key (B), and the owner doesn't revoke it, then eventually
> the attacker can add a new trust anchor (C).  The incantation for the
> attacker is "B and C sign (B C X)" where X is a ZSK key owned by the
> attacker.   The moment that the owner sees something it hasn't itself
> signed, signed with B, then the owner should issue "A and B sign (A, Br,
> D, Z)" where D is the owner's replacement for B and where Z is a ZSK key
> owned by the owner.
>
> Any SEP key can become a trust anchor if it is validly signed and is in
> the DNSKEY RRSet for the add hold down time (plus one retrieval).

All above seems pretty clear.

>> When the RFC says "and signing it with B", it might be clearer if it
>> says "and signing it with B and C". It is far from clear which
>> messages from the attacker are for public consumption (which would be
>> seen by the zone owner) and which are meant for restricted relying
>> parties.
>
> That's not actually a matter of concern for the zone owner. The
> incantation to revoke a key K is "K signs (Kr)".  As I noted elsewhere,
> you can't actually have multiple disjoint DNSKEY RRSets for a given
> name, so that you end up doing a union of all the keys to be signed into
> a single DNSKEY RRSet and you provide signatures by all signers over all
> the keys.

When the RFC says "and signing it with B" in section 2.2 Add Hold-Down, 
it talks about adding C to the DNSKEY RRset. C is still a stand-by key 
and does not necessarily need to sign the DNSKEY set. C will still be 
added to the validator in the AddPend state.

When B is revoked, you do want to sign with both B and C: B to self-sign 
(Br) and C to sign the DNSKEY RRset.

> With respect to the relying party - he doesn't know and can't tell - who
> originated the DNSKEY and signature data he's seeing.  It's a crap shoot
> as to which version of the "truth" (owner or attacker) he sees.  The
> 5011 model is designed to make it as difficult as possible for an
> attacker to feed its version of truth to a specific validating resolver
> for a long enough period of time so that resolver installs a new trust
> anchor AND never sees the revocation of the compromised trust anchor.
>
>
>> >> Immediately after the relying party has seen (2), B can never be
>> trusted again, even while they are waiting for the hold-down timer for
>> adding C.
>> >
>> > Revocation takes place immediately.  Once the bit is set and validly
>> signed, the key is revoked and can't be used for anything except
>> signing the revocation.  So in B and C sign (Br C), the signature over
>> the keys by B only has impact on Br,  The signature by C over the keys
>> only has impact if C has already been added to the validators trust
>> anchor set.
>>
>> Yup.
>>

I think the time progression is as follows:

1a:  Owner's zone: A signs (A B)
1b:  Attacker's zone: B signs (B C)
2a:  Owner's zone: A and B signs (A Br D)
2b:  Attacker's zone: B and C signs (Br C)

The owner should do step 2a before the attacker is able to do 2b.

>> > Owner:  A and B sign (A Br D) - B is revoked and D starts its
>> process of being added as a trust anchor.
>> > Attacker:  B signs (B C)
>> >
>> > The key point is that if the validator sees even one of the "A and B
>> sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail
>> validation leading to C not being added to the trust anchor set.
>>
>> Yes, that's clearly the intent, and it should work (assuming that the
>> resolver follows the "revoke B as soon as you see a B-signed-Br
>> anywhere" rule).
>
>
>>     A key is
>> considered revoked when the resolver sees the key in a
>>     self-signed RRSet and the key has the REVOKE bit (see
>> Section 7  <http://tools.ietf.org/html/rfc5011#section-7>
>> >> I don't understand why B signs (A D) in 2b. B is already untrusted
>> to anyone who saw 2a, and is untrusted by anyone looking at all of 2b.
>> These instructions seem to be saying "put a signature into the zone
>> that cannot be validated". I would think that 2b should just be "B
>> signs (Br) and A signs (A D)", but that's not what the RFC says.
>> >
>> > You can't actually have two different versions of the DNSKEY RRSet
>> being simultaneously offered by a single responder.  You *can* have
>> multiple signatures over a single DNSKEY RRSet.
>> >
>> > So the above is actually "A and B sign (A Br D)". It's also actually
>> more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs.
>> So you get "B signs Br to revoke itself", "A signs D to add D to the
>> trust anchor set" and "A signs Z so that Z chains to the root of trust".
>> >
>> > That's expressed by a DNSKEY RRSet consisting of B with the revoke
>> bit, D with the SEP bit and Z without the SEP bit with two
>> RRSIG(DNSKEY) records consisting of a signature by A and  a signature
>> by B.
>>
>>
>> > A signing key needs to be included in the DNSKEY RRSet even if its
>> already accepted as a trust anchor.  That's mainly so the key id
>> reference of the RRSIG (DNSKEY) can find the appropriate public key
>> for validation.
>>
>> Why D? Is it a replacement for B because 5011 works better with more
>> than one trust anchor? I didn't see anything in the section that
>> explained D, and from what you say above, it looks like I guessed
>> wrong the first time.
>
>
> Yes, D is the owner's replacement for B.    I don't name the keys as "C"
> and "D" in section 6.1, but that's what's happening.
>
> You used "C" as the "Attacker's new trust anchor" in this series of
> messages.  I probably would have used something more disjoint in the
> explanation.
>
>
> So to clarify.
>

Since B is a standby key, it should be "A signs (A B Z)"

> 5) Assuming A is compromised issue a new RRSET  "A and B sign (Ar B C
> Z)"  and propagate that for twice the add hold down time.  (the add hold
> down time to get the bits set, the additional time to pick up stragglers
> - the additional time is just suspenders and belt)

6) should be "B signs (B C Z)".

Best regards,
   Matthijs

> In practice, it may take a little time to get folks together for the key
> ceremony for C, so you may end up with an interim DNSKEY RRSet "A and B
> sign (Ar B Z)" for a few days.  [Which by itself suggests a need to be
> able to do signatures without having everyone physically present]
>
>
> In the above, the attacker's only ploy is to do "A signs (A N X)" where
> N is a new trust anchor key owned by the attacker and X is a new ZSK
> also owned by the attacker.  His hope is that the validly signed (by
> compromised key A) RRSet gets accepted for a short while by specific
> targets and maybe long enough to get a new trust anchor key accepted by
> those specific targets.
>
>
>> --Paul Hoffman
>
>
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Oct 2014 11:58:26 -0400

At 04:59 AM 10/13/2014, Matthijs Mekking wrote:
>When the RFC says "and signing it with B" in section 2.2 Add Hold-Down, it talks about adding C to the DNSKEY RRset. C is still a stand-by key and does not necessarily need to sign the DNSKEY set. C will still be added to the validator in the AddPend state.
>
>When B is revoked, you do want to sign with both B and C: B to self-sign (Br) and C to sign the DNSKEY RRset.

It depends.  If A is still sacrosanct - then the usual incantation for the owner will be  "A and B sign (A Br C Z)" where C is a new trust anchor and Z is the ZSK.    C becomes a standby trust anchor and doesn't have to actually sign the root DNSKEY RRSet until it's placed into active service.

For the attacker, trying to add a new trust anchor that he owns (N), the incantation is going to be "B and N sign (B N X)" where X is a ZSK owned by the attacker.

The attacker - if all he holds is B - can't sign Br until after the Add Holddown period expires if he's trying to add a new attacker owned trust anchor.

>The owner should do step 2a before the attacker is able to do 2b.

Right, but 2a can happen as soon as the owner notices something hinky with the zone or suspects a compromise.  2b can't happen until 1b has been out in the wild for the entire Add Holddown time otherwise the attacker is throwing away its only mechanism for installing new trust anchors.

>Since B is a standby key, it should be "A signs (A B Z)"

No.  Once B is added as a trust anchor, it need not be included in the root DNSKEY RRSet.   If B is not signing anything, there is no reason to include it.

>6) should be "B signs (B C Z)".

Same thing as above.  Once C is a trust anchor, unless its actively signing something, there's no need to include it in the DNSKEY RRSet.  [However, you increase the "take" rate for resolvers the longer you leave it there - especially if there are intermittently connected resolvers]

Keys enter the trust anchor set only by being present in the root DNSKEY RRSet and signed by a previous trust anchor for a minimum period of time (the Add Hold Down).   Keys leave the trust anchor set only through revocation.   

Mike

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 14 Oct 2014 10:49:56 +0200

On 13-10-14 17:58, Michael StJohns wrote:
>>>> Thanks for the clarifications. I still have a bunch of
>>>> questions, and I really do wonder if implementers agree with
>>>> your interpretations.
>>
>>
>>>>>
>>>>>> 2: Attacker's zone: B signs (A Br C) (Here, "Br" means "B
>>>>>> with the REVOKE bit set".)
>>>>>
>>>> When the RFC says "and signing it with B", it might be clearer
>>>> if it says "and signing it with B and C". It is far from clear
>>>> which messages from the attacker are for public consumption
>>>> (which would be seen by the zone owner) and which are meant for
>>>> restricted relying parties.
>>>
>>> incantation to revoke a key K is "K signs (Kr)".  As I noted
>>> elsewhere, you can't actually have multiple disjoint DNSKEY
>>> RRSets for a given name, so that you end up doing a union of all
>>> the keys to be signed into a single DNSKEY RRSet and you provide
>>> signatures by all signers over all the keys.
>>
>> When the RFC says "and signing it with B" in section 2.2 Add
>> Hold-Down, it talks about adding C to the DNSKEY RRset. C is still
>> a stand-by key and does not necessarily need to sign the DNSKEY
>> set. C will still be added to the validator in the AddPend state.
>>
>> When B is revoked, you do want to sign with both B and C: B to
>> self-sign (Br) and C to sign the DNSKEY RRset.
>
> It depends.  If A is still sacrosanct - then the usual incantation
> for the owner will be  "A and B sign (A Br C Z)" where C is a new
> trust anchor and Z is the ZSK.    C becomes a standby trust anchor
> and doesn't have to actually sign the root DNSKEY RRSet until it's
> placed into active service.

The scenario above is for the attacker, he has no incentive of keep 
publishing A.

> For the attacker, trying to add a new trust anchor that he owns (N),
> the incantation is going to be "B and N sign (B N X)" where X is a
> ZSK owned by the attacker.
>
> The attacker - if all he holds is B - can't sign Br until after the
> Add Holddown period expires if he's trying to add a new attacker
> owned trust anchor.
>
>
>
>>> With respect to the relying party - he doesn't know and can't
>>> tell - who originated the DNSKEY and signature data he's seeing.
>>> It's a crap shoot as to which version of the "truth" (owner or
>>> attacker) he sees.  The 5011 model is designed to make it as
>>> difficult as possible for an attacker to feed its version of
>>> truth to a specific validating resolver for a long enough period
>>> of time so that resolver installs a new trust anchor AND never
>>> sees the revocation of the compromised trust anchor.
>>>
>>>
>>>> trusted again, even while they are waiting for the hold-down
>>>> timer for adding C.
>>>>>
>>>> signed, the key is revoked and can't be used for anything
>>>> except signing the revocation.  So in B and C sign (Br C), the
>>>> signature over the keys by B only has impact on Br,  The
>>>> signature by C over the keys only has impact if C has already
>>>> been added to the validators trust anchor set.
>>>>
>>>> Yup.
>>>>
>>>>>> In the given example, the zone owner can recover from a
>>>>>> compromise by revoking B and adding a new key D and signing
>>>>>> the DNSKEY RRSet with both A and B.
>>>>>>
>>>>>> The time progression here sounds like: 1: Owner's zone: A
>>>>>> signs (A B) 2a: Attacker's zone: B signs (A Br C) 2b:
>>>>>> Owner's zone: B signs (Br) and A signs (A D) and B signs (A
>>>>>> D) 2a happens before 2b because that is how the owner
>>>>>> discovers that B
>>>> was compromised.
>>
>> 1a:  Owner's zone: A signs (A B) 1b:  Attacker's zone: B signs (B
>> C) 2a:  Owner's zone: A and B signs (A Br D) 2b:  Attacker's zone:
>> B and C signs (Br C)
>>
> Right, but 2a can happen as soon as the owner notices something hinky
> with the zone or suspects a compromise.  2b can't happen until 1b has
> been out in the wild for the entire Add Holddown time otherwise the
> attacker is throwing away its only mechanism for installing new trust
> anchors.

Correct.

>>> Yes, D is the owner's replacement for B.    I don't name the keys
>>> as "C" and "D" in section 6.1, but that's what's happening.
>>>
>>> You used "C" as the "Attacker's new trust anchor" in this series
>>> of messages.  I probably would have used something more disjoint
>>> in the explanation.
>>>
>>>
>>> So to clarify.
>>>
>>> 1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand
>>> for any of the regularly generated ZSKs) 2) B is a stand by key -
>>> it's a trust anchor, but not used for regular quarterly signing
> No.  Once B is added as a trust anchor, it need not be included in
> the root DNSKEY RRSet.   If B is not signing anything, there is no
> reason to include it.

That depends on your key rollover mechanism. In the Double-DS rollover, 
you don't need to add B, in Double-KSK and Double-Signature you do.

But if you want B to keep as a trust anchor at the validator, you better 
leave it in the DNSKEY RRset, otherwise it goes to the `Missing` state, 
an abnormal state. That can't be good.

In the Autotrust implementation, missing trust anchors will be removed 
after a (fairly long) time, otherwise we might end up with a bunch of 
valid, but missing, trust points which are no longer in use. That sounds 
like a weakness in the system.

>>> 4) If A or B is compromised then generate a new key pair C 5)
>>> Assuming A is compromised issue a new RRSET  "A and B sign (Ar B
>>> C Z)"  and propagate that for twice the add hold down time.  (the
>>> add hold down time to get the bits set, the additional time to
>>> pick up stragglers - the additional time is just suspenders and
>>> belt) 6) Once you've done (5) for long enough, issue a new
>>> "normal" RRSET "B signs (B Z)".  C is now a standby key.
>>
> Same thing as above.  Once C is a trust anchor, unless its actively
> signing something, there's no need to include it in the DNSKEY RRSet.
> [However, you increase the "take" rate for resolvers the longer you
> leave it there - especially if there are intermittently connected
> resolvers]

Same thing as above. You want to keep it in the DNSKEY RRset, or the 
validator will mark the trust anchor as `Missing`.

> Keys enter the trust anchor set only by being present in the root
> DNSKEY RRSet and signed by a previous trust anchor for a minimum
> period of time (the Add Hold Down).   Keys leave the trust anchor set
> only through revocation.

Right, and to me that sounds like a weakness. Missing trust points 
should be cleaned up too.

Best regards,
   Matthijs

>> Best regards, Matthijs