<br>Dear Peter,<br><br>Thanks for the good work. I hereby support the proposal.<br><br>Regards,<br><br>Brieuc-Yves Cadat<br><br><div class="gmail_quote">2008/11/14 Peter Koch <span dir="ltr"><<a href="mailto:pk@denic.de">pk@denic.de</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Dear RIPE Community,<br>
<br>
as mentioned in my email sent on Monday, the DNS working group has come<br>
up with a response to the US NTIA's Notice of Inquiry (NoI) regarding<br>
the introduction of DNSSEC for the DNS root zone (for details see<br>
<<a href="http://www.ntia.doc.gov/DNS/DNSSEC.html" target="_blank">http://www.ntia.doc.gov/DNS/DNSSEC.html</a>>).<br>
<br>
The text below reflects the consensus of the DNS working group.<br>
<br>
As a follow up to our earlier efforts (see below), the DNS WG suggests that<br>
the response to the NTIA come from the broader RIPE community. So, this is<br>
the DNS WG's request for your support and endorsement of the proposal.<br>
<br>
Please read the text and voice your support or opposition.  As mentioned<br>
earlier, we will have to meet an external deadline. Therefore, we are not<br>
looking for editorial suggestions.  Regrettably, it is impractical to further<br>
refine or reword the text, since that would require more editing cycles and<br>
new consensus calls, which time won't permit.<br>
The WG chairs' collective and the RIPE Chair have agreed that it needs<br>
a binary decision on the proposal as presented here.<br>
<br>
It is possible that the text doesn't represent the optimum for everyone.<br>
Still, please consider whether you can support it as a community statement.<br>
In any case, the NoI is open for anybody, so you might want to send<br>
your individual response and/or contribute to other group efforts, as well.<br>
<br>
Clarifying questions are welcome, probably best asked on the DNS WG mailing<br>
list or to the DNS WG co-chairs <<a href="http://www.ripe.net/ripe/wg/dns/index.html" target="_blank">http://www.ripe.net/ripe/wg/dns/index.html</a>>.<br>
<br>
Given the 24 Nov deadline and to allow some time for the evalutaion of the<br>
list traffic, you are kindly asked to send your explicit statements to this<br>
list no later than<br>
<br>
                Friday, 21 Nov 2008 12:00 UTC.<br>
<br>
Thanks in advance for your consideration!<br>
<br>
-Peter Koch [DNS WG co-chair]<br>
<br>
-----------------------------------------------------------------------------<br>
<br>
#<br>
#       $Id: ntia-draft,v 1.9 2008/11/13 20:20:41 jim Exp $<br>
#<br>
<br>
The RIPE community thanks the NTIA for its consultation on proposals<br>
to sign the root and is pleased to offer the following response to<br>
that consultation. We urge the adoption of a solution that leads to<br>
the prompt introduction of a signed root zone. Our community considers<br>
the introduction of a signed root zone to be an essential enabling<br>
step towards widespread deployment of Secure DNS, DNSSEC. This view<br>
is supported by the letter from the RIPE community to ICANN as an<br>
outcome of discussions at the May 2007 RIPE meeting in Tallinn:<br>
<a href="http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf" target="_blank">http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf</a>.<br>
<br>
It is to be expected that a community as diverse as RIPE cannot have a<br>
unified set of detailed answers to the NTIA questionnaire. However<br>
several members of the RIPE community will be individually responding<br>
to that questionnaire. We present the following statement as the<br>
consensus view of our community about the principles that should form<br>
the basis of the introduction of a signed DNS root.<br>
<br>
1. Secure DNS, DNSSEC, is about data authenticity and integrity and<br>
not about control.<br>
<br>
2. The introduction of DNSSEC to the root zone must be made in such a<br>
way that it is accepted as a global initiative.<br>
<br>
3. Addition of DNSSEC to the root zone must be done in a way that does<br>
not compromise the security and stability of the Domain Name System.<br>
<br>
4. When balancing the various concerns about signing the root zone,<br>
the approach must provide an appropriate level of trust and confidence<br>
by offering an optimally secure solution.<br>
<br>
5. Deployment of a signed root should be done in a timely but not<br>
hasty manner.<br>
<br>
6. Updates from TLD operators relating to DNSSEC should be aligned<br>
with the operational mechanisms for co-ordinating changes to the root<br>
zone.<br>
<br>
7. If any procedural changes are introduced by the deployment of<br>
DNSSEC they should provide sufficient flexibility to allow for the<br>
roles and processes as well as the entities holding those roles to be<br>
changed after suitable consultations have taken place.<br>
<br>
8. Policies and processes for signing the root zone must be<br>
transparent and trustworthy, making it straightforward for TLDs to<br>
supply keys and credentials so the delegations for those TLDs can<br>
benefit from a common DNSSEC trust anchor, the signed root.<br>
<br>
9. There is no technical justification to create a new organisation to<br>
oversee the process of signing of the root.<br>
<br>
10. No data should be moved between organisations without appropriate<br>
authenticity and integrity checking, particularly the flow of keying<br>
material between a TLD operator and the entity that signs the root.<br>
<br>
11. The public part of the key signing key must be distributed as<br>
widely as possible.<br>
<br>
12. The organisation that generates the root zone file must sign the<br>
file and therefore hold the private part of the zone signing key.<br>
<br>
13. Changes to the entities and roles in the signing process must not<br>
necessarily require a change of keys.<br>
<br>
-----------------------------------------------------------------------------<br>
<br>
</blockquote></div><br>