[dns-wg] final? draft of NTIA response

No hats. Speaking only as an old kernel/network stack programmer and someone who at one time had to work with various US govt agencies including NTIA.  And who just wants to see this done in both a timely, secure, and stable fashion. And believing that with the changing US Administration - "yes, we can change" how things are done.  I don't care who signs the root just as long as it is done securely, timely and we don't lock ourselves into anything - organizationally or technically.  DNSSEC deployment seems like an evolving process technically and politically.


> -----Original Message-----
> From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of
> Jim Reid
> Sent: Friday, November 07, 2008 2:07 PM
> To: dns-wg at ripe.net
> Subject: [dns-wg] final? draft of NTIA response
>
> Colleagues, here is what I hope is the final draft of our response to
> the NTIA. I trust we can reach consensus on this. There is very little
> time to continue with update/review cycles, so I would appreciate if
> any comments were confined to showstoppers. We might have reservations
> or quibbles about some of the detail or phrasing. However unless these
> materially affect the response, could I ask you to please keep these
> to yourself? My worry here is that further tweaks lead to yet more
> comments and tweaks, and this goes on and on and on. The current
> langauge may not be perfect. However I hope it is something that we
> can all agree is good enough.
>
> I would also ask WG members to say they support the text (assuming you
> do of course). It would be better to have positive statements of
> support instead of declaring that silence on this topic is consensus
> for the WG.
>
>
> #
> #       $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 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

Replace this sentence with:
"We urge the development of a solution that leads to the prompt introduction of a signed root zone."

The NTIA NOI is asking YOU to design it.  Not for you to accept or adopt another's solution.  Nothing is cast in stone.  Be as technical as you want to be.  They are looking for technical feedback.

> 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 recognised as a
> global initiative.

Looking at this from DoC/NTIA's eyes, this says DNSSEC can NOT be deployed till all the worlds governments come to them and say they want it.
If this is your intent, it is not my place to argue.  Its fine.
But if it not, this has to be reworded.

If the intent is to say that DNSSEC at the root must be implemented/deployed in a way that is recognized (trusted?) by the world, then id suggest:
"The introduction of DNSSEC to the root zone must be made in such a way as to be globally recognised."

>
> 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.

This reads (again reading it in my old job capacity) a bit like you do not want DNSSEC.  Again, if that's the view, that's fine.  However, if not I would say:
"Addition of DNSSEC to the root zone must be done in a way that only enhances the security and stability of the Domain Name System."
OR
"Addition of DNSSEC to the root zone must be done in a way that does not negatively impact the security and stability of the Domain Name System."


>
> 4. When balancing the various concerns about signing the root zone,
> the chosen approach must provide an appropriate level of trust and
> confidence by offering a maximally secure technical solution.

We are not choosing what they give us.  We are telling them how to design it. So I would say "developed" instead of "chosen". Left out "technical" to not suggest specifics about HSM's or facilities or what have you since these are general point.
"When balancing the various concerns about signing the root zone, the approach developed must provide an appropriate level of trust and confidence by offering a maximally secure solution."

>
> 5. Deployment of a signed root should be done in a timely but not
> hasty manner.
>
> 6. To assist with a timely deployment, any procedural changes
> introduced by DNSSEC should be aligned with the current process for
> coordinating changes to and the distribution of the root zone. However
> those procedural changes 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.

I strongly believe the first sentence would still be read by USG folk as saying you want the root DNSSEC implementation to not change the current IANA-NTIA-VeriSign arrangement in the slightest.  If this is what you want, this is fine.

However, the NOI is asking for your technical input not constrained by policy or current structures.  Why not think outside this old box?  Might be easier to change in this new US Administration and I think bringing in the techies from NIST on this one bodes well for NTIA.   I truly believe this is an opportunity to build a secure, and yes timely, solution.  Most of the world's DNNSEC experience is in RIPE!

With respect to the second sentence.  It also strongly suggests changes to the current troika would be hard to come by - again policy issues.  Just as a newbie observer, I have the sense that if VeriSign starts performing the signing function as part of its separate CRADA contract with NTIA, it will likely never move to another organization (whereas the IANA function is designed to be moved..  I know.. unlikely but I invite you to look at the IANA and CRADA contracts - really .. definitely no hats).   Tell me if I am wrong.
Again, if you are happy with the current arrangement and want it to stay that way, that's fine.

If however the idea is to get DNSSEC deployed fast but not hastily, that was already said elsewhere.  So I would remove this point.  As it stands it clearly tells NTIA to select VeriSign...and again if this is what people want, that would be fine with me since as an American it gives me strong legal rights regarding corporations.  Just seems like moving a root signing system from one place to another, though I see no technical problems with it, will be "made difficult" with various technical and managerial arguments once it is in place.  This would mean the hope for a non-US corp signed root gets even dimmer.

Assuming the current roles are frozen or cannot be changed in a timely fashion and that we therefore must live by them is a policy issue.   It may be hard to separate tech and policy issues here but if we are willing to touch on policy, I would like to make these points slightly differently.   Ill watch the list.


>
> 7. Policies and processes for signing the root zone should make it
> easy for TLDs to supply keys and credentials so the delegations for
> those TLDs can benefit from a common DNSSEC trust anchor, the signed
> root.
>
> 8. There is no technical justification to create a new organisation to
> oversee the process of signing of the root.
>
> 9. No data should be moved between organisations without appropriate
> authenticity and integrity checking.

Again, I get the sense that an artificial constraint on technical designs is being placed here by assuming multiple physically separate organizations.  If this is what you want, that's fine.  However a more general statement would be:
"If data is moved between organizations, it should be with appropriate authenticity and integrity checking."

>
> 10. The public part of the key signing key must be distributed as
> widely as possible.

Anyone could generate a key and publish its public half widely but it would not be any good unless users trust it, e.g., accept it as having been generated and managed in an acceptable way for them.  So I suggest:
"The public part of the widely agreed to key signing key must be distributed as widely as possible."

>
> 11. The organisation that generates the root zone file must sign the
> file and therefore hold the private part of the zone signing key.
>
> 12. Changes to the entities and roles in the signing process must not
> necessarily require a change of keys.
>
>

-Rick