[dns-wg] NTIA response - v5

On Wed, Nov 05, 2008 at 10:42:38PM +0000, Jim Reid wrote:

> PS: Please try to avoid suggestions on cosmetic changes to the text  
> unless these would improve the clarity. The WG needs to reach  
> consensus on a statement in a day or two. So we should try to focus on  
> what we are trying to say rather than how we are actually saying it.  

<co-chair hat=on>
As a matter of process, the timeline as of Dubai suggests that the final
draft response shall be ready by November, 10th. I.e., the DNS WG should
have reached consensus by then - or the effort is goinf to die.
After that date, further edits are not expected, but the RIPE community
(as represented by the ripe-list mailing list) is asked for comment,
aftre which the presence or absence of consensus will have to be judged.
</co-chair>

> The RIPE community (or DNS WG?) thanks the NTIA for its consultation

As an editorial matter, I understand the part in brackets (same below)
would come into effect if and only if the broader RIPE community does
not accept the proposal _and_ the DNS WG still plans to pursue.

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

It is unclear to me what the implications of "maximally secure" are.
Does this imply FIPS 140 level 4 HSMs and 4K key lengths?  I doubt that,
but I'd appreciate a clarification here to avoid ambiguity.

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

I'd avoid the notion of delegations being signed, because that can be
read in a way inconsistent with statement (1).  The prime function of
a DNSSEC signed root zone is a secure, centralized way of publishing
TLD trust anchors: "... delegations for those TLDs can be accompanied
by the TLDs' signed Trust Anchors."

> 8. There is no technical justification to create a new organisation to
> oversee the process of signing of the root.

That's probably true, but one could argue that _technically_ there's
also no need for today's role split, so I doubt this adds much.  If this
is a comment re: any particular proposal, the text should be more explicit.

> 9. No data should be moved between organisations without appropriate
> authenticity and integrity checking.

Ack.  The list doesn't say anything re: confidentiality requirements or,
more precisely, moving ZSK private key material around. Shouldn't the
latter be discouraged?

> 11. The organisation that generates the root zone file must sign the
> file and therefore hold the private part of the zone signing key.

Why this if (9) was followed?  Not saying (11) is bad, but it needs
a bit more explanation.

> 12. Changes to the entities and roles in the signing process must not
> necessarily require a change of keys.

I see two ambiguities here: first, which I assume 'keys' means KSK here;
second: what is the meaning of "must not necessarily" as opposed to
"must not"?

-Peter ('s own opinions)