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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
