I support this text (v 1.9) as well. 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-----
# # $Id: ntia-draft,v 1.9 2008/11/13 20:20:41 jim Exp $ #
The RIPE community 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. This view is supported by the letter from the RIPE community to ICANN as an outcome of discussions at the May 2007 RIPE meeting in Tallinn: http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf.
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 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.