<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I fully support the response text below<div><br></div><div>Joao Damas</div><div><br></div><div><div><div>On 14 Nov 2008, at 16:59, Peter Koch wrote:</div><br><blockquote type="cite"><div>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">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">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><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>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>#<span class="Apple-tab-span" style="white-space:pre"> </span>$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">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></div></blockquote></div><br></div></body></html>