Subject: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13

From: Matthijs Mekking <[email-masked]>
Date: Tue, 16 Oct 2012 16:03:11 +0200

Hi all,

The document draft-ietf-dnsop-rfc464bis-13 has seen some issues while
being in AUTH and RCF-EDITOR state. This e-mail will list all the
suggested changes to address those issues.

* Issue in section 4.1.2.  Key Signing Key Rollovers

There is a missing necessary wait: The old DNSKEY RRset must expire from
caches before the parent can change the DS RRset.

Old text:

   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.

New 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.

* Issue in section 4.1.3.  Single Type Signing Scheme Key Rollover

Not all signatures can skip pre-publication, the new key must sign the
DNSKEY RRset before the DS change, even if signing the rest of the zone
is delayed.

Old 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.  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.

New 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.

* Issue on Section 4.3.5.1.  Cooperating DNS operators

The decision is to handle only one scenario, the alternative approach
from the appendix, and remove the utterly complex, drawback heavy
scenario that is now described first in the document. I'll post the old
and new contents of the section below (warning: it is a bit long). In
addition, Appendix D.  Transition Figure for Changing DNS Operators is
removed.

Old text:

   In this scenario, it is assumed that the losing operator will not
   pass any private key material to the gaining operator (that would
   constitute a trivial case) but is otherwise fully cooperative.

   In this environment, the change could be made with a Pre-Publish ZSK
   rollover whereby the losing operator pre-publishes the ZSK of the
   gaining operator, combined with a Double Signature KSK rollover where
   the two registrars exchange public keys and independently generate a
   signature over those key sets that they combine and both publish in
   their copy of the zone.  Once that is done they can use their own
   private keys to sign any of their zone content during the transfer.

    ------------------------------------------------------------
    initial            |        pre-publish                    |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A                            DS_A
    ------------------------------------------------------------
    Child at A:            Child at A:        Child at B:
     SOA_A0                 SOA_A1             SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)

     NS_A                   NS_A               NS_B
     RRSIG_Z_A(NS)          NS_B               RRSIG_Z_B(NS)
                            RRSIG_Z_A(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
                            DNSKEY_Z_B         DNSKEY_Z_B
     DNSKEY_K_A             DNSKEY_K_A         DNSKEY_K_A
                            DNSKEY_K_B         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)      RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)
                            RRSIG_K_B(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

    ------------------------------------------------------------
          redelegation                 |   post migration      |
    ------------------------------------------------------------
    Parent:
              NS_B                           NS_B
              DS_B                           DS_B
    ------------------------------------------------------------
    Child at A:        Child at B:           Child at B:

     SOA_A1             SOA_B0                SOA_B1
     RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)        RRSIG_Z_B(SOA)

     NS_A               NS_B                  NS_B
     NS_B               RRSIG_Z_B(NS)         RRSIG_Z_B(NS)
     RRSIG_Z_A(NS)

     DNSKEY_Z_A         DNSKEY_Z_A
     DNSKEY_Z_B         DNSKEY_Z_B            DNSKEY_Z_B
     DNSKEY_K_A         DNSKEY_K_A
     DNSKEY_K_B         DNSKEY_K_B            DNSKEY_K_B
     RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)
     RRSIG_K_B(DNSKEY)  RRSIG_K_B(DNSKEY)     RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

               Figure 10: Rollover for cooperating operators

   In this figure A denotes the losing operator and B the gaining
   operator.  RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is
   produced with a KSK, the appended A or B indicates the producers of
   the key pair.  "Child at A" is how the zone content is represented by
   the losing DNS operator and "Child at B" is how the zone content is
   represented by the gaining DNS operator.

   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 new NS record and 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 that DNSKEY RRset has populated 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. And after all
   DNSSEC records related to A have expired from the caches, operator B
   can stop publishing the keys and signatures belonging to operator A
   and vice versa.

   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.

   Thus, if the registry and registrars allow DS records to be published
   that do not point to a published DNSKEY in the child zone, the
   Double-DS KSK rollover is preferred (see Figure 5), in combination
   with the Pre-Publish ZSK rollover.  This does not require sharing the
   KSK signatures between the operators, but both operators still have
   to publish each others ZSKs.

New text:

   In this scenario, it is assumed that the losing operator will not
   pass any private key material to the gaining operator (that would
   constitute a trivial case) but is otherwise fully cooperative.

   In this environment, the change could be made with a Pre-Publish ZSK
   rollover whereby the losing operator pre-publishes the ZSK of the
   gaining operator, combined with a Double-DS KSK rollover.  Once that
   is done they can use their own private keys to sign any of their zone
   content during the transfer.

    ------------------------------------------------------------
    initial             |        new DS and pre-publish        |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A                            DS_A DS_B
    ------------------------------------------------------------
    Child at A:            Child at A:        Child at B:
     SOA_A0                 SOA_A1             SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)

     NS_A                   NS_A               NS_B
     RRSIG_Z_A(NS)          RRSIG_Z_A(NS)      RRSIG_Z_B(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
                            DNSKEY_Z_B         DNSKEY_Z_B
     DNSKEY_K_A             DNSKEY_K_A         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)      RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

    ------------------------------------------------------------
          re-delegation                |   post migration      |
    ------------------------------------------------------------
    Parent:
              NS_B                           NS_B
              DS_A DS_B                      DS_B
    ------------------------------------------------------------
    Child at A:        Child at B:           Child at B:

     SOA_A1             SOA_B0                SOA_B1
     RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)        RRSIG_Z_B(SOA)

     NS_B               NS_B                  NS_B
     RRSIG_Z_A(NS)      RRSIG_Z_B(NS)         RRSIG_Z_B(NS)

     DNSKEY_Z_A         DNSKEY_Z_A
     DNSKEY_Z_B         DNSKEY_Z_B            DNSKEY_Z_B
     DNSKEY_K_A         DNSKEY_K_B            DNSKEY_K_B
     RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)     RRSIG_K_B(DNSKEY)

    ------------------------------------------------------------

               Figure 10: Rollover for cooperating operators

   In this figure A denotes the losing operator and B the gaining
   operator.  RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is
   produced with a KSK, the appended A or B indicates the producers of
   the key pair.  "Child at A" is how the zone content is represented by
   the losing DNS operator and "Child at B" is how the zone content is
   represented by the gaining DNS operator.

   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.
   In the second stage, 'new DS and pre-publish', the cooperating
   operator A will pre-publish the ZSK of operator B, while the new
   operator B publishes the ZSK of operator A. Both operators sign their
   zone with their own ZSKs and KSKs.  At the same time, operator B can
   pre-publish the new DS record, DS_B, that delegates to the KSK of
   operator B.

   When the old DNSKEY and DS RRsets have expired from the caches, i.e.
   all the resolvers are still using the delegation of the old operator
   but are prepared to trust the delegation to the new operator, the
   re-delegation can be made.  This involves adjusting the NS RRset 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. In the post migration stage, when all RRSIG records
   related to A have expired from the caches, operator B can stop
   publishing the keys belonging to operator A and the DS record
   belonging to operator A, DS_A, can be removed from the parent zone.

---

From: Tony Finch <[email-masked]>
Date: Wed, 17 Oct 2012 16:41:54 +0100

> suggested changes to address those issues.

I have reviewed the changes and they look good to me.

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: Antoin Verschuren <[email-masked]>
Date: Tue, 23 Oct 2012 13:32:37 +0200

On 16-10-12 16:03, Matthijs Mekking wrote:
> Hi all,
> 
> The document draft-ietf-dnsop-rfc464bis-13 has seen some issues
> while being in AUTH and RCF-EDITOR state. This e-mail will list all
> the suggested changes to address those issues.

While reading the proposed changes and the whole document again, I
noticed another paragraph that is no longer desired.
My question is that now that we do make some changes, it is advised
that this paragraph is also adjusted to fit current day practices.

The paragraph is 4.3.2.
The advice in this paragraph, which hasn't changed since 2009 when it
was first written down, has been overtaken by new insight and practices.
It advises registries to store only DS in stead of DNSKEY material in
their database. This has proven to be impractical when deploying
DNSSEC on a large scale:

1. Current practice proves that the majority of DNSSEC domains in the
world today is provisioned by sending a DNSKEY record to te registry,
and not DS. Running code for the majority of DNSSEC domains uses DNSKEY.

2. The old advice is based on the assumption that less errors are
being made when cutting and pasting a DS in a webinterface or reading
it since it is smaller than a DNSKEY. Current practice today however
is that this is all automated, and while provisioning 1.3 M DNSSEC
domains, we have not seen such errors.

3. With more algorithms used for DNSSEC today, and some no longer
advised, registries want to hash the DNSKEY to DS themselves so they
don't need to go through a "contacting every child" nightmare when an
algorithm is no longer supported. The DS is owned by the parent, not
the child. Our practice shows that hashing is a minor operation by the
parent. It takes no real effort whatsoever in computation or time.

4. The most important motivation for us to use DNSKEY is consistancy
with new processes that did not exist in 2009. DNSSEC secure transfers
(http://tools.ietf.org/id/draft-koch-dnsop-dnssec-operator-change-04.txt)
is the most important one. In a DNS-operator change, the operator
initiating the change needs to send his new KSK (DNSKEY/DS) to the
registry AND needs to relay his ZSK (DNSKEY). It is confusing that in
bootstrapping a delegation a DS needs to be sent, but when transfering
a DS AND ZSK DNSKEY needs to be sent. It is better to use DNSKEY in
both processes so a child operator is never burdened with calculating
a DS or having to think about 2 different fields in EPP that do not
have the same meaning. So our advise is to use DNSKEY syntax for both
KSK and ZSK when transfering to your parent.

So my advise is to either delete paragraph 4.3.2 since it is bad
advice (there is no convincing motivation given in this paragraph
anyway), or use the motivation given above to advise for using DNSKEY
over DS.

If needed, I'm willing to write text.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Miek Gieben <[email-masked]>
Date: Tue, 23 Oct 2012 15:29:55 +0200

[ Quoting <[email-masked]> in "Re: [DNSOP] Changes since draft-iet..." ]
> The advice in this paragraph, which hasn't changed since 2009 when it

... so you couldn't have sent in a change sooner? ;-)

> their database. 

The paragraph is a *suggestion* in a *bcp*. With the central point 
being that a child can choose its hash. I think this is a too minor
point to (again) stop the AUTH48 process.

 Regards,

-- 
    Miek Gieben                                               http://miek.nl

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 23 Oct 2012 14:46:18 +0100

On 23 Oct 2012, at 14:29, Miek Gieben wrote:

> The paragraph is a *suggestion* in a *bcp*.

	I don't see what point you're trying to make with this remark.

	Indeed, if the suggestion is not congruent with current practice,
	it seems to me that it very much ought not to belong in a so-called
	"Best Current Practice".  You seem to be emphasizing Antoin's
	position; but then you object to it.

	ATB
	/Niall

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 23 Oct 2012 10:00:40 -0400

> 	position; but then you object to it.

As I disagree with the general applicability of Antion's proposal and
consider it a paternalistic overreach I think rfc4641bis should go 
forward w/o change.
While I think the idea of passing keys though the registry between 
operator has some merit I do not see it as viable alternative outside 
few cc'tld's thus it it does not deserve to be included in a BCP without 
full debate.

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Oct 2012 09:34:18 -0500

>and not DS. Running code for the majority of DNSSEC domains uses DNSKEY.

Do you have any proof of this?

I say this in the spirit that outside of .NL, I am not aware of any 
other TLD that takes the key.  I am sure there are others, and I am 
not measuring this factor.  But given what I know, I am surprised at 
the assertion made here.

>domains, we have not seen such errors.

OTOH, we haven't seen problems with the other approach.  We don't 
have 1.3M DNSSEC zones though so I can conclude nothing.

What would be meaningful is to find an example on par, size-wise, 
with your example that opts to accept only key records and show that 
it encounters errors (in significant numbers).

>parent. It takes no real effort whatsoever in computation or time.

Hashing was never the question.  The rationale behind the suggestion 
to just take DS records was based on liability concerns and the 
thought that a registry is just about mapping information (from 
object to entity) and not about producing information.

>KSK and ZSK when transfering to your parent.

There is a discussion to be had, no doubt, but even here you are 
citing a document that is "just" an internet draft as a basis.

>anyway), or use the motivation given above to advise for using DNSKEY

You'd have to demonstrate that it is "bad advice."  You've only 
justified why you have opted to design your operations to accept keys 
and not limit the input to DS records.  Not that your choice is wrong 
or invalid, but an example of one doesn't indicate consensus.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 23 Oct 2012 16:39:20 +0200

On 23-10-12 16:00, Olafur Gudmundsson wrote:

> operator has some merit I do not see it as viable alternative
> outside few cc'tld's thus it it does not deserve to be included in
> a BCP without full debate.

I gave 4 reasons, not one.
Running code and current practice being important ones for the IETF.

But most of all, I fail to see the motivation for the current advice
in the document.
If there is no motivation but just an opinion, I think the advice
should be deleted from the document.

- -- 
Antoin Verschuren

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 24 Oct 2012 16:36:40 +0200

Hi,

I am against changing the suggestion in Section 4.3.2, even though you
provide practices that in one legitimate case DNSKEY is preferred over
DS. Such a change would in my opinion have to go through the working
group and reach consensus there and I am afraid it is way too late for
that. I would not be surprised that after publication, we come up with
even more considerations that are also legit and could have been in the
incorporated into the document. But at this moment I would not like to
discuss changes that delay publication, unless there is detected
something fundamentally wrong with the document.

Also note that this is to be an informational RFC, not a BCP. The
document is not claiming that one approach is better than the other. It
merely provides considerations and provides arguments that can help
operators to make a well-thought decision.

Best regards,
  Matthijs

On 10/23/2012 01:32 PM, Antoin Verschuren wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>