Subject: [DNSOP] Error in rfc4641bis - change of operator

From: Tony Finch <[email-masked]>
Date: Fri, 14 Sep 2012 11:00:28 +0100

This is horrifically late, I'm afraid - dunno if it's too late to fix it
before publication...

There is a problem in the procedure described in section 4.3.5.1. In the
pre-publication phase the following things happen:

The new operator sets up a copy of the zone signed with new keys, with an
NS RRset pointing at the new servers, and a DNSKEY RRset containing both
old and new public keys, signed with both old and new KSKs.

The old operator adds the new public keys to the DNSKEY RRset and the new
KSK signature, and updates the NS RRset to include the new servers as well
as the old ones.

This change of name servers is wrong! It can lead to validation failures
as follows:

A client has a cached copy of the old DNSKEY RRset. They do a lookup at an
old server (say, www.example AAAA) which validates fine since it is signed
with the old key. As a side-effect it gives them an updated NS RRset which
includes the new servers. They do a second lookup at a new server (say,
www.example A) which is signed which the new key - but the client cannot
validate it because it doesn't have the new DNSKEY RRs.

There is a simpler procedure for change of operator, which only requires
operators to be able to import extra DNSKEY RRs - the same for both the
old and the new operator. It does not require cross-signing as described
in rfc4641bis, and it does not require either operator to host NS records
pointing at a competitor.

(1) The new operator sets up a copy of the zone signed with new keys, with
an NS RRset pointing at the new servers, and a DNSKEY RRset containing the
new public keys and signed with the new KSK.

(2) The old operator imports the new DNSKEY RRs. The new operator imports
the old DNSKEY RRs. Each operator has a DNSKEY RRset containing both sets
of public keys, signed with their own KSK - a different signature at each
operator.

(3) The DS is updated to include the new KSK digest as well as the old
one.

(4) Wait for a TTL. Now all the clients are still using the old operator,
but they are prepared to trust the new one.

(5) Change the delegation NS RRset to point to the new operator.

(4) Wait for a TTL. Now all the clients are using the new operator, and
the old signatures have expired from their caches.

(5) Clean up by deleting the old DS and DNSKEY RRs, and remove the zone
from the old operator.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Miek Gieben <[email-masked]>
Date: Fri, 14 Sep 2012 13:11:23 +0200

[ Quoting <[email-masked]> in "[DNSOP] Error in rfc4641bis - chang..." ]
> This is horrifically late, I'm afraid - dunno if it's too late to fix it

This is indeed pretty late in the game...

> validate it because it doesn't have the new DNSKEY RRs.

I think you're right :(

> pointing at a competitor.

Isn't this?
https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-04
Section 3.1

 Regards,

-- 
    Miek Gieben                                                   http://miek.nl

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Sep 2012 12:40:17 +0100

> https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-04

Er, yes, thanks for reminding me that I should have read that document.

A few differences: That draft makes the excellent point that you only need
to copy the ZSK DNSKEY RRs between the old and new versions of the zone -
there's no need to copy the KSK too. It also considers the TTLs more
carefully than I did. And it proposes to use the registry to transfer the
new DNSKEY RR to the old operator, whereas I was thinking that the domain
owner would do it, either via the operators' web interfaces or via an API
etc. This has the advantage that the same functionality provided by the
operators (adding DNSKEY records without private keys) is useful for
gaining customers not just for losing them - better security economics.

Tony.

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 17 Sep 2012 11:13:32 +0200

Hi Tony,

[CC'ed the AD, as this may lead to a non-negligible change]

I think you are right, this situation can happen in the drawn scenario.
However, I guess a sane validator would try the other name server (NS_A)
if it would receive a validation failure from NS_B.

Would this be fixed by just removing the pre-published NS_B from the
losing operator version of the zone? Probably, except for sticky resolvers.

Nevertheless, if that would fix it or not, we should update the
scenario, or perhaps remove it as Miek suggested. If we look at the
history of the document, the scenario has been mentioned first in
version -01 and the corresponding figure saw the light in version -02.

The working group had detected that this is a complex operation and that
there is a simpler way to handle a change between DNS operators. This is
what you describe in your e-mail as well and is first mentioned in the
document in version -06. A figure for this scenario was provided in
version -09 (although until now it includes unnecessary signatures over
the DNSKEY RRsets and still has the faulty pre-publication of NS_B in
the losing operator version of the zone).

Since I sense that there is a general consensus that using a Double-DS
method is a simpler way to handle a change between DNS operators in
comparison with the Pre-Publication method, I would like to propose the
following:

- Remove the text on the Pre-publication style of changing DNS operators.
- Move the figure from Appendix D to the section of changing DNS operators.

Best regards,
  Matthijs

---

From: Tony Finch <[email-masked]>
Date: Mon, 17 Sep 2012 11:42:47 +0100

> if it would receive a validation failure from NS_B.

I think BIND will do that, but I'm less sure about Unbound and Vantio -
see for instance a recent discussion on the dns-operations list:
https://lists.dns-oarc.net/pipermail/dns-operations/2012-September/008725.html

Duane Wessels's stunt authoritative nameservers are intended to detect
validating resolvers. It alternately serves signed and unsigned versions
of a zone and notices when the resolvers retry after a validation
failure. In practice not all resolvers are persistent enough.

> losing operator version of the zone? Probably, except for sticky resolvers.

Yes, the way to fix it is not to change the child NS RRset at the old
provider A until redelegation time, which is when you are sure resolvers
no longer have the old chain of trust cached and are able to validate the
zone at the new provider B.

There are a couple of ways to deal with sticky resolvers:

(1) Change the NS RRset at A to NS_B after redelegation.

(2) Reconfigure the zone at A to slave from B.

There is a second bug in the draft which leads to lameness rather than
validation failures. After redelegation, the draft says provider A should
serve both NS_A and NS_B, so a sticky resolver will continue to send
queries to A after the zone is deconfigured there in the post-migration
phase.

> - Move the figure from Appendix D to the section of changing DNS operators.

That's probably the right direction. However, I just looked at appendix D
properly. It has errors too :-(

Section 4.3.5.1 says:

   The requirement to exchange signatures has a couple of drawbacks.  It
   requires more operational overhead, because not only the operators
   have to exchange public keys, they also have to exchange the
   signatures of the new DNSKEY RRset.  This drawback does not exist if
   the Double Signature KSK rollover is replaced with a Double-DS KSK
   rollover.  See Figure 15 in Appendix D for the diagram.

But the figure in Appendix D shows that signatures HAVE been exchanged, so
it doesn't have the simplification implied by this text.

Figure 15 also changes the NS RRset at A too soon, so it doesn't fix the
bug I found on Friday.

A minor niggle: It has a "new DS" phase rather than an initial phase,
which is not necessary: you can publish the new DS at the same time as the
new DNSKEY RRs. That is, you can do the "new DS" phase of the double-DS
KSK rollover at the same time as the "pre-publish" phase of the ZSK
rollover.

After all that here is what I think are the minimal changes necessary:

To correct figure 10:

Remove NS_B from the "Child at A" column in the pre-publish phase.

Remove NS_A from the "Child at A" column in the redelegation phase.

The second paragraph of the explanatory text should read:

> The zone is initially delegated from the parent to the name servers of
> operator A. Operator A uses his own ZSK and KSK to sign the zone. The
> cooperating operator A will pre-publish the ZSK and KSK of operator B,
> including the RRSIG over the DNSKEY RRset generated by the KSK of B.
> Operator B needs to publish the same DNSKEY RRset.  When the old DNSKEY
> RRset has expired from the caches, the re-delegation can be made, which
> involves adjusting the NS and DS records in the parent zone to point to
> operator B. To ensure resolvers switch from A to B, operator A should
> also change its NS records to point to operator B. And after all RRSIG
> records related to A have expired from the caches (apart from the DNSKEY
> RRSIG), operator B can stop publishing the keys and signatures belonging
> to operator A.

To correct figure 15:

Change the first column from "new DS" to "initial" and remove DS_B.

In the "Child at A" column of the pre-publish phase, remove NS_B and
RRSIG_K_B(DNSKEY).

In the "Child at B" column of the pre-publish phase, remove
RRSIG_K_A(DNSKEY).

Change the name of the pre-publish phase to "new DS and pre-publish".

In the "Child at A" column of the redelegation phase, remove NS_A.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Sep 2012 12:25:37 +0100

Section 4.1.2, explanatory text:

   initial:  Initial version of the zone.  The parental DS points to
      DNSKEY_K_1.  Before the rollover starts, the child will have to
      verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
      it is needed during the rollover and we refer to the value as
      TTL_DS.

   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
      generates a second KSK, DNSKEY_K_2.  The key is provided to the
      parent, and the child will have to wait until a new DS RR has been
      generated that points to DNSKEY_K_2.  After that DS RR has been
      published on all servers authoritative for the parent's zone, the
      zone administrator has to wait at least TTL_DS to make sure that
      the old DS RR has expired from caches.

   DS change:  The parent replaces DS_K_1 with DS_K_2.

This is missing a necessary wait: the old DNSKEY RRset must expire from
caches before the parent to replaces the DS RR.

Fixed text:

   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
      generates a second KSK, DNSKEY_K_2, introduces it into the key
      set, and signs the new key set with both the old and new KSKs.
      The minimum duration of this phase is the time it takes for
      the data to propagate to the authoritative servers, plus TTL value
      of the key set.

   DS change: The new key is provided to the parent. The child will
      have to wait until the parent replaces DS_K_1 with DS_K_2.  After
      the new DS RR has been published on all servers authoritative for
      the parent's zone, the zone administrator has to wait at least
      TTL_DS to make sure that the old DS RR has expired from caches.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Sep 2012 12:55:02 +0100

Section 4.1.3. This description of a variant rollover is dangerous: the
new key must sign the DNSKEY RRset before the DS change, even if signing
the rest of the zone is delayed.

   This rollover has the drawback that it introduces double signatures
   over all data of the zone.  Taking these zone size considerations
   into account, it is possible to not introduce the signatures made
   with DNSKEY_S_2 at the "new DNSKEY" step.  Instead, signatures of
   DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an
   additional stage between the "DS change" and "DNSKEY removal" step:
   After the DS RRset containing DS_S_1 has expired from distant caches,
   the signatures can be swapped.  Only after the new signatures made
   with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1
   can be removed from the DNSKEY RRset.

Corrected text:

   This rollover has the drawback that it introduces double signatures
   over all data of the zone.  Taking these zone size considerations
   into account, it is possible to not introduce the signatures made
   with DNSKEY_S_2 at the "new DNSKEY" step, except for the signature
   over the DNSKEY RRset.  Instead, signatures of DNSKEY_S_1 in the rest
   of the zone are replaced with signatures of DNSKEY_S_2 in an
   additional stage between the "DS change" and "DNSKEY removal" step:
   After the DS RRset containing DS_S_1 has expired from distant caches,
   the signatures can be swapped.  Only after the new signatures made
   with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1
   can be removed from the DNSKEY RRset.

Tony.