[dns-wg] NTIA response - v5

On Nov 6, 2008, at 11:48, Peter Koch wrote:

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

Ditto.

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

Yes.

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

This is implementation detail. It's not relevant to the *principles*  
we're stating. Let's not debate key lengths or which form of secure  
key handling hardware is best. That debate can be had somewhere else:  
dnsop for example. IMO "maximally secure" is good enough for the  
purposes of this letter.

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

This is too subtle a distinction to matter IMO Peter. The people who  
will be reading any response (and acting on it) will not be DNS  
protocol engineers and crypto geeks. How about:

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

The intent here is to dissuade NTIA/ICANN/politicians from finding an  
excuse to introduce yet more bureaucracy to oversee the co-ordination  
of a signed root. A clear and unequivocal statement saying this is not  
needed will help to deflect those layer-9 arguments. Adding more text  
to this point will dilute that message and may well create more  
confusion, not less. Not to mention opening up rat-holes....

IMO the text is fine as-is.

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

IMO the text is fine as-is. We're not writing a procedures manual or a  
functional spec here.

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

Again, I believe the current text is fine as-is.

IMO (9) primarily speaks to the movement of DS records and related  
stuff between TLDs and the root. (11) is about how the signed root  
zone is generated. In other words, it shouldn't be necessary for the  
root zone generator to go off and fetch the ZSK from somewhere else,  
then check it, every time it spits out a new signed root zone file.  
Besides, the root zone generator needs to have the flexibility to  
quickly change the ZSK for operational reasons: hard to do if some  
other entity is holding the ZSK.

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

Nope. The ambiguity here is deliberate. In all likelihood it's just  
KSKs that could be affected by a change of roles or organisations. But  
this should not be assumed or explicitly stated.

> second: what is the meaning of "must not necessarily" as opposed to
> "must not"?

Wiggle room. Suppose one of the chosen entities screws up and has an  
important key compromised. The powers that be could be forced to  
choose someone else to take on that role and introduce a new key.  
OTOH, if a change of organisation or role is amicable, the existing  
key(s) move from the old to the new entity. So if one day the root KSK  
moves from my house to your house (say), that move shouldn't  
necessarily mean every TLD needs to generate new KSKs and/or ZSKs. But  
a change of TLD keys might be needed in that scenario because I've  
been perceived to be less trustworthy than you. For some definition of  
trustworthy.