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@sidn.nl W http://www.sidn.nl/
-----Original Message----- From: dns-wg-admin@ripe.net [mailto:dns-wg-admin@ripe.net] On Behalf Of Jim Reid Sent: Monday, November 10, 2008 9:57 AM To: dns-wg@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.