[dns-wg] final? draft of NTIA response

Mohsen Souissi wrote:you
> Jim &all
>   
Mohsen,
I can just support you as I expected the same interpration.

Dima
> Thank you for all the efforts you put in this work and congratulations
> for the result.
>
> It appears to me that the reservations I raised in Dubai about the
> risk our text be interpreted as an endorsement of the current
> process/actors have been well addressed in the recent versions.
>
> Now, speaking individuall as a member of this working group, I support
> this text as is* and I'm in favor of moving it forward at least as a
> DNS-WG document (if we happened not to get a consensus at the RIPE
> meeting level).
>
> Mohsen.
>
> * "Le mieux est l'ennemi du bien" as we say in French and further
>   improvements which are of course possible would be too
>   energy/time-consuming for editors and for the wg.
>
>  On 07 Nov, Jim Reid wrote:
>  | Colleagues, here is what I hope is the final draft of our response to  
>  | the NTIA. I trust we can reach consensus on this. There is very little  
>  | time to continue with update/review cycles, so I would appreciate if  
>  | any comments were confined to showstoppers. We might have reservations  
>  | or quibbles about some of the detail or phrasing. However unless these  
>  | materially affect the response, could I ask you to please keep these  
>  | to yourself? My worry here is that further tweaks lead to yet more  
>  | comments and tweaks, and this goes on and on and on. The current  
>  | langauge may not be perfect. However I hope it is something that we  
>  | can all agree is good enough.
>  | 
>  | I would also ask WG members to say they support the text (assuming you  
>  | do of course). It would be better to have positive statements of  
>  | support instead of declaring that silence on this topic is consensus  
>  | for the WG.
>  | 
>  | 
>  | #
>  | #	$Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $
>  | #
>  | 
>  | The RIPE community (or DNS WG?) thanks the NTIA for its consultation
>  | on proposals to sign the root and is pleased to offer the following
>  | response to that consultation. We urge the adoption of a solution that
>  | leads to the prompt introduction of a signed root zone. Our community
>  | considers the introduction of a signed root zone to be an essential
>  | enabling step towards widespread deployment of Secure DNS, DNSSEC.
>  | 
>  | It is to be expected that a community as diverse as RIPE cannot have a
>  | unified set of detailed answers to the NTIA questionnaire. However  
>  | several
>  | members of the RIPE community will be individually responding to that
>  | questionnaire. We present the following statement as the consensus
>  | view of our community (or the DNS Working Group?) about the principles
>  | that should form the basis of the introduction of a signed DNS root.
>  | 
>  | 1. Secure DNS, DNSSEC, is about data authenticity and integrity and
>  | not about control.
>  | 
>  | 2. The introduction of DNSSEC to the root zone must be recognised as a
>  | global initiative.
>  | 
>  | 3. Addition of DNSSEC to the root zone must be done in a way that does
>  | not compromise the security and stability of the Domain Name System.
>  | 
>  | 4. When balancing the various concerns about signing the root zone,
>  | the chosen approach must provide an appropriate level of trust and
>  | confidence by offering a maximally secure technical solution.
>  | 
>  | 5. Deployment of a signed root should be done in a timely but not
>  | hasty manner.
>  | 
>  | 6. To assist with a timely deployment, any procedural changes
>  | introduced by DNSSEC should be aligned with the current process for
>  | coordinating changes to and the distribution of the root zone. However
>  | those procedural changes should provide sufficient flexibility to
>  | allow for the roles and processes as well as the entities holding
>  | those roles to be changed after suitable consultations have taken
>  | place.
>  | 
>  | 7. Policies and processes for signing the root zone should make it
>  | easy for TLDs to supply keys and credentials so the delegations for
>  | those TLDs can benefit from a common DNSSEC trust anchor, the signed
>  | root.
>  | 
>  | 8. There is no technical justification to create a new organisation to
>  | oversee the process of signing of the root.
>  | 
>  | 9. No data should be moved between organisations without appropriate
>  | authenticity and integrity checking.
>  | 
>  | 10. The public part of the key signing key must be distributed as
>  | widely as possible.
>  | 
>  | 11. The organisation that generates the root zone file must sign the
>  | file and therefore hold the private part of the zone signing key.
>  | 
>  | 12. Changes to the entities and roles in the signing process must not
>  | necessarily require a change of keys.
>
>