Re: [dns-wg] NTIA and RIPE

[Patrik Fältström paf@localhost]

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