[dns-wg] one more effort on the NTIA response

Oops, I replied to the wrong email.
I meant I feel confortable with this latest version of the draft, 1,8.


Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E antoin.verschuren at sidn.nl
W http://www.sidn.nl/


> -----Original Message-----
> From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of
> Jim Reid
> Sent: Monday, November 10, 2008 9:57 AM
> To: dns-wg at ripe.net
> Subject: [dns-wg] one more effort on the NTIA response
> 
> Colleagues, I am sorry to say that we have still not reached consensus
> on the proposed response to the NTIA NoI. After discussing this
> yesterday the WG co-chairs felt that further work is needed. We have
> also had reliable feedback that Friday's draft was being
> misinterpreted by some of the likely audience for this response
> outside the WG. I have taken guidance from an informal editing group
> to tweak the response to clear up the ambiguity and potential for
> misunderstanding. So we now have an updated draft response to consider.
> 
> The intention is still to try and get consensus in the WG, ideally on
> the text below. If that can be achieved in the next few days, we will
> then endeavour to get consensus from the RIPE community. And if that
> is done, the agreed text will go to NTIA as a statement of the RIPE
> community. The NTIA deadline makes this a delicate balancing act. On
> the one hand, there's little time left for further discussion. On the
> other, there needs to be reasonable discussion time in both the WG and
> RIPE lists so that the validity of our procedures are not undermined.
> Please bear this in mind before commenting about the latest draft on
> the list.
> 
> Please take a look at the latest revised version below. As before, I
> would ask you to only comment about any matters that you consider to
> be showstoppers and provide suggested alternate text. Please try not
> to focus on minor tweaks to the language as that will divert us all
> from the matter at hand. And take time we don't really have to spare.
> 
> Remember too that we're trying to get consensus within the WG. This is
> hard because there are differing views about how the root could or
> should be signed. There may be wording in the text below that is not
> to your personal taste. And other WG members may well be uncomfortable
> with the stuff in the draft that you like. However I hope we can all
> agree the latest draft is a fair reflection of the collective view of
> the WG. Some compromise and good sense from all of us is needed to
> keep this thing on track.
> 
> Don't forget that what we're doing here is expressing the view of the
> WG (or the RIPE community?) *as a whole*. This does not prevent any of
> you from making your own personal or professional representations to
> the NTIA, something I encourage all of you to do. If some of the
> detail is not to your personal taste, please think carefully about
> whether it's better to handle that inside the WG in the time available
> or by making a personal submission to NTIA. So unless there's
> something in the draft below that you think makes us look bad/stupid/
> wrong, can I ask for your support on this latest version?
> 
> Oh, and if you are happy with the latest draft, please say so on the
> list. Your WG co-chairs will feel a lot more comfortable declaring
> consensus when there are positive statements to that effect on the
> list. This is far better than presuming a default of silence implies
> consent.
> 
> #
> #	$Id: ntia-draft,v 1.8 2008/11/09 17:28:20 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 made in such a
> way that it is accepted 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 approach must provide an appropriate level of trust and confidence
> by offering an optimally secure solution.
> 
> 5. Deployment of a signed root should be done in a timely but not
> hasty manner.
> 
> 6. Updates from TLD operators relating to DNSSEC should be aligned
> with the operational mechanisms for co-ordinating changes to the root
> zone.
> 
> 7. If any procedural changes are introduced by the deployment of
> DNSSEC they 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.
> 
> 8. Policies and processes for signing the root zone must be
> transparent and trustworthy, making it straightforward for TLDs to
> supply keys and credentials so the delegations for those TLDs can
> benefit from a common DNSSEC trust anchor, the signed root.
> 
> 9. There is no technical justification to create a new organisation to
> oversee the process of signing of the root.
> 
> 10. No data should be moved between organisations without appropriate
> authenticity and integrity checking, particularly the flow of keying
> material between a TLD operator and the entity that signs the root.
> 
> 11. The public part of the key signing key must be distributed as
> widely as possible.
> 
> 12. The organisation that generates the root zone file must sign the
> file and therefore hold the private part of the zone signing key.
> 
> 13. Changes to the entities and roles in the signing process must not
> necessarily require a change of keys.
>