Hi Jim, thanks for your patient response.
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.
maybe I misrepresented my intentions. Of course key lengths and matters of specific technology are far too detailed for this kind of response. However, "maximally secure" is too wide a term IMHO to be useful without a scale. Even more so since there's a balance between this "maximum" and operational reality.
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:
Exactly my point. If they were, they knew that the delegation isn't signed - technically. More importantly, there's also no other "signing" of the delegation.
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.
Sounds much better to me, thanks.
8. There is no technical justification to create a new organisation to
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
I doubt that any attempt, be that by reflex or by perceived attempt and angenda, to introduce bureaucracy can simply be defeated by a "no" statement, but so be it.
9. No data should be moved between organisations without appropriate authenticity and integrity checking.
11. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key.
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
Sure, but (9) could also be applied to an RZM and a separate root signer. Not that I'd see anyone here favor this, but the beauty is in the eye of the addressee.
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.
The suggestions I've seen so far suggest to transfer the data or to transfer the ZSK once, not on every occasion, so this is besides the point. I can live with (11) as is, only I'd prefer a bit more reasoning.
12. Changes to the entities and roles in the signing process must not necessarily require a change of keys.
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.
This is a new requirement. Not the change of entities but the compromise would suggest a key rollover in this case. Let's just focus on the preconditions set forth in the text.
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.
I do not like this ambiguity and "wiggle room". The statement doesn't hurt, but with that additional explanation it doesn't say much, either. Again: so be it. -Peter