On request, now as text. The original is the PDF though, so I do not guarantee this version is exactly like the current version on PDF. I hope so though! Patrik -- that missed lunch...see some of you in the desert RIPE and NTIA 29th of October 2008 A - DNSSEC is about data authenticity and integrity and not about control. B - The addition of DNSSEC to the root zone must be recognised as a global initiative. C - Addition of DNSSEC must be done in a way that the deployment of DNS is not at risk. D - Deployment should be done in a timely but not hasty manner. E - Any procedural changes introduced by DNSSEC should be aligned with the process for coordinating changes to and the distribution of the root zone. F - Policies and processes for signing the root zone should make it easy for TLDs to participate. G - There is no technical justification to create a new organisation to oversee the process of signing of the root. H - No data should be moved between organisations without appropriate authenticity and integrity checking. I - The public part of the KSK must be distributed as widely as possible. J - The organisation that creates the zone file must hold the private part of the ZSK. K - Changes to the entities and roles in the signing process must not require a change of keys.
Regardless of my personally agreeing with such a statement or not, here are my reactions to some of the bullets. At 15:01 +0400 10/29/08, Patrik Fältström wrote:
B - The addition of DNSSEC to the root zone must be recognised as a global initiative.
I'm unclear on the intent of the B statement. See my comment on E.
E - Any procedural changes introduced by DNSSEC should be aligned with the process for coordinating changes to and the distribution of the root zone.
In some interpretations of B & E, these two could be conflicting. I.e., B implies that the current state of root zone management is too centered in the US, E evokes a message encouraging the status quo. Mind you - I am not commenting on B or E, but my reading of the two leaves come confusion in my mind. Perhaps I am misunderstanding B and/or E as it is presented here.
F - Policies and processes for signing the root zone should make it easy for TLDs to participate.
As someone employed by a TLD registry, it's not clear to me how or why such rather internal matters of the root zone matter to my job. Again, not saying this is a bad statement, but it begs for more detail or direction. I am not saying that the policies and processes for signing the root should be closed to the public. I just don't see the relevance to the TLD.
J - The organisation that creates the zone file must hold the private part of the ZSK.
My guess is that the intention in J is to say "the org that creates the zone file is the sole possessor of the private ZSK(s) and *performs the signing function*." Otherwise it doesn't matter if the creator has the key at all.
K - Changes to the entities and roles in the signing process must not require a change of keys.
I technically disagree with that, if there is a change in the entity performing the zone signing, the private key material should not have to be transferred out in the transition. The private key material of concern here is the ZSK, not the KSK. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
Since I pushed on this subject, maybe my perspective is useful. Signing a TLD or higher zone is pretty pointless unless it contains DS records. It is really important that the process for the child to maintain the DS record in the parent zone be as easy as possible. At the root, where literally everybody comes together, the opportunity for getting this wrong is large. For example, a TLD operator might have good reason that it chooses not to reveal to want to change its KSK quickly. The process for signing the root should make this as easy as possible. John On 2008Oct29, at 7:30 PM, Edward Lewis wrote:
F - Policies and processes for signing the root zone should make it easy for TLDs to participate.
As someone employed by a TLD registry, it's not clear to me how or why such rather internal matters of the root zone matter to my job. Again, not saying this is a bad statement, but it begs for more detail or direction.
I am not saying that the policies and processes for signing the root should be closed to the public. I just don't see the relevance to the TLD.
On 29 okt 2008, at 19.30, Edward Lewis wrote:
Regardless of my personally agreeing with such a statement or not, here are my reactions to some of the bullets.
Let me clarify what discussion lead to each one of them.
At 15:01 +0400 10/29/08, Patrik Fältström wrote:
B - The addition of DNSSEC to the root zone must be recognised as a global initiative.
I'm unclear on the intent of the B statement. See my comment on E.
Running the root zone is something that have impact on everyone. Not only organisations and individuals in the USA. This include of course an urge to NTIA to take comments from entities from abroad into consideration, just like comments from entities within the USA.
E - Any procedural changes introduced by DNSSEC should be aligned with the process for coordinating changes to and the distribution of the root zone.
In some interpretations of B & E, these two could be conflicting. I.e., B implies that the current state of root zone management is too centered in the US, E evokes a message encouraging the status quo.
E say that DNSSEC management must be in sync with management of the root zone. People today trust the DNS given the hierarchy we have in the namespace with IANA at the root. DNSSEC should be in sync with that. If that is changed (we all know about the JPA, complaints on US Gov etc etc), then also DNSSEC processes should be changed. I.e. after adding DNSSEC to the way we do management of the root zone today (including some potential changes), we should still only have one process for the root zone management. Not one for DNSSEC and one for the root zone. It is one. "There can only be one!" ;-)
Mind you - I am not commenting on B or E, but my reading of the two leaves come confusion in my mind. Perhaps I am misunderstanding B and/or E as it is presented here.
Understood. It could be confusing.
F - Policies and processes for signing the root zone should make it easy for TLDs to participate.
As someone employed by a TLD registry, it's not clear to me how or why such rather internal matters of the root zone matter to my job. Again, not saying this is a bad statement, but it begs for more detail or direction.
I am not saying that the policies and processes for signing the root should be closed to the public. I just don't see the relevance to the TLD.
People here recognized that when one talk about "trust" and DNSSEC people often talk about the trust the resolver operator have on the trust anchor. One forget to talk about the trust a TLD operator have to have on the root zone management. They have to trust the process so that they publish their DS. Further, they today make changes according to a specific process (via IANA etc), that they to some degree "trust". Adding DNSSEC must take that into consideration. How easy/ hard it is for TLDs to participate.
J - The organisation that creates the zone file must hold the private part of the ZSK.
My guess is that the intention in J is to say "the org that creates the zone file is the sole possessor of the private ZSK(s) and *performs the signing function*." Otherwise it doesn't matter if the creator has the key at all.
Ok. Thanks!
K - Changes to the entities and roles in the signing process must not require a change of keys.
I technically disagree with that, if there is a change in the entity performing the zone signing, the private key material should not have to be transferred out in the transition. The private key material of concern here is the ZSK, not the KSK.
People here said two things to me: a) It would be good if change of ZSK or KSK operator would NOT imply a silent period or _VERY_ complicated key rollover. b) If the keys are contained in hardware (say 3 HSM), then a transition from one holder to another could be made by physically carrying one of the HSM to the new operator. Tests can be done. Then when those tests are positive, the two other HSM can be carried away. When that is done and things work, then a key rollover process can start as normal. This and other things lead me to add text like the one above. "Must not" is probably too strong though. Patrik
On 30 okt 2008, at 08.05, Patrik Fältström wrote:
a) It would be good if change of ZSK or KSK operator would NOT imply a silent period or _VERY_ complicated key rollover.
changing the holder of the ZSK (e.g. the root zone maintainer) doesn't have to be very complicated. some time before the change of maintainers, the new maintainer would submit its first set of ZSK to the KSK holder for signing and the old maintainer would include this in the root zone for some short period of time. I do however believe that changing the holder of the KSK will be complicated, unless a proven automatic key rollover mechanism has been developed, implemented _and_ deployed. so while I wouldn't hold my breath waiting for this to happen, I hope that the initial KSK holder will be stable and that it is possible to transfer the KSK in case the holder needs to be changed. jakob
On 30 okt 2008, at 10.28, Jakob Schlyter wrote:
I do however believe that changing the holder of the KSK will be complicated, unless a proven automatic key rollover mechanism has been developed, implemented _and_ deployed. so while I wouldn't hold my breath waiting for this to happen, I hope that the initial KSK holder will be stable and that it is possible to transfer the KSK in case the holder needs to be changed.
Fair... Now, we had this bullet: K - Changes to the entities and roles in the signing process must not require a change of keys. Then I thought about changing it to the following: K - Changes to the entities and roles in the signing process should minimize issues related to potential changes in keys when the entities changes. Now, I am a bit confused... :-) Jakob, Ed, others...do you have any suggestion on text? Patrik
Patrik Fältström wrote on 30-10-2008 07:34: [...]> Now, we had this bullet:
K - Changes to the entities and roles in the signing process must not require a change of keys.
Then I thought about changing it to the following:
K - Changes to the entities and roles in the signing process should minimize issues related to potential changes in keys when the entities changes.
Now, I am a bit confused... :-)
Jakob, Ed, others...do you have any suggestion on text?
I was under the impression that point K essentially said that implementation should not cast the current root zone management setup (with regards to the entities) in stone. If this is so, how about the following: K - Changes of the entities representing roles in the signing process must be possible and have minimum effect on the keys.
Patrik
Andrei
At 10:34 +0400 10/30/08, Patrik Fältström wrote: Regarding item K -
Jakob, Ed, others...do you have any suggestion on text?
This seems like the statement is about to get "wrapped around the axle." Perhaps we need to get back to basics, that is, put this in engineering terms - the language we speak. "The root zone's KSK public key management and distribution process should be designed to minimize the impact on name servers throughout the Internet in the event that changes are made to the operators involved." What we are after here (in the DNS WG) is reliable (including "smooth") technical operations. What I'm trying to suggest are words that avoid dealing with the business and political, etc., issues we all know are hanging in the air but are beyond the core expertise of the WG. I don't know if my words accomplish that, but that's what I'm trying to do. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
participants (5)
-
Andrei Robachevsky -
Edward Lewis -
Jakob Schlyter -
John Schnizlein -
Patrik Fältström