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.