<html><body>
<p><br>
<font size="5" face="Times New Roman">We agree with the RIPE letter and proposals on designing of signing the DNS root zone. </font><br>
<font size="5" face="Times New Roman">We wait with impatience for DNSSEC testing activities.</font>
<p><font size="4"><br>
Best regards,<br>
<br>
Head of Operators' VAS department<br>
OAO "VimpelCom"<br>
Nataliya V. Romashova <br>
loc. 09 53395<br>
tel. +7 495-961-31-86 #53395<br>
tel. +7(495)743-01-70<br>
fax. +7(495)985-95-55<br>
e-mail: rom@beeline.ru<br>
</font><tt><font size="4"><br>
Subject:<br>
Call for Support: RIPE response to the US NTIA's NoI<br>
From:<br>
Peter Koch <pk@DENIC.DE><br>
Date:<br>
Fri, 14 Nov 2008 23:59:09 +0100<br>
To:<br>
ripe-list@ripe.net<br>
<br>
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>
<</font></tt><a href="http://www.ntia.doc.gov/DNS/DNSSEC.html"><tt><u><font size="4" color="#0000FF">http://www.ntia.doc.gov/DNS/DNSSEC.html</font></u></tt></a><tt><font size="4">>).<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 <br>
<</font></tt><a href="http://www.ripe.net/ripe/wg/dns/index.html"><tt><u><font size="4" color="#0000FF">http://www.ripe.net/ripe/wg/dns/index.html</font></u></tt></a><tt><font size="4">>.<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:</font></tt><tt><u><font size="4" color="#0000FF"><br>
</font></u></tt><a href="http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf"><tt><u><font size="4" color="#0000FF">http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf</font></u></tt></a><tt><font size="4">.<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>
</font></tt><font size="4"><br>
</font></body></html>