revised text for NTIA response - v4
I have updated the list of bullet points to reflect the recent comments and feedback. There are a few minor tweaks and some introductory motherhood and apple pie statements. Point 5 has the most substantive change. I think it now accommodates the concerns that some have expressed about the possibilty that the existing way of managing the root could become entrenched by the deployment of DNSSEC. Perhaps the two sentences here need to be split into discrete statements? We have to be careful here. If we don't go along with the current process for co-ordinating root zone changes, politicians will latch on to that as an excuse to open another line of attack over USG control of the Internet. If that happens, we won't get a signed root any time soon. So I hope the line we can all agree on is "Let's go with the current process for managing the root for now to get DNSSEC deployed. But don't introduce a signed root in a way that will prevent a different mechanism with perhaps different entities and roles being used at some point later on.". I hope we can all live with that. This is what I have tried to encapsulate in point 5. Point 12 is a tweaked version of Richard Lamb's remarks. I think this could/should be moved nearer to the top of the list. Anyway, now it's time for comments. It would be helpful if you contribute alternate text along with any clarifications or remarks. ie Please don't just say "Point X is unclear/confusing". Please say why it's confusing and suggest better wording. If we are to reach consensus by this weekend, the discussion needs to be focused and direct. # # $Id: ntia-draft,v 1.4 2008/11/03 10:25:25 jim Exp $ # RIPE welcomes the NTIA's consultation on the proposals to sign the root and is pleased to support that effort. We urge the NTIA to adopt a solution that leads to a prompt signed root zone. The solution must not compromise the stability and integrity of the root zone management process. It should be flexible enough to allow for the entities and roles involved in the process to be replaced or for the process itself to be replaced. The solution should minimise reasonable concerns, whether they are of a political, economic or business nature. 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. 3. Addition of DNSSEC to the root zone must be done in a way that the security and stability of the Domain Name System is not at risk. 4. Deployment of a signed root should be done in a timely but not hasty manner. 5. 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. 6. 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. 7. There is no technical justification to create a new organisation to oversee the process of signing of the root. 8. No data should be moved between organisations without appropriate authenticity and integrity checking. 9. The public part of the key signing key must be distributed as widely as possible. 10. The organisation that generates the root zone file must hold the private part of the zone signing key. 11. Changes to the entities and roles in the signing process must not necessarily require a change of keys. 12. 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.
Anyway, now it's time for comments. It would be helpful if you contribute alternate text along with any clarifications or remarks. ie Please don't just say "Point X is unclear/confusing". Please say why it's confusing and suggest better wording. If we are to reach consensus by this weekend, the discussion needs to be focused and direct.
# # $Id: ntia-draft,v 1.4 2008/11/03 10:25:25 jim Exp $ #
10. The organisation that generates the root zone file must hold the private part of the zone signing key.
the imperative in this point is made with zero justification. why the "must hold"? I think a more pragmatic reply (if the previous points are to be respected) would be something along these lines: 10. The organization that generates the root zone file must sign the file and therefore must hold the private part of the zone signing key. or 10. The organization that generates the root zone file must have unfettered access to the zone signing key components. I have a slight inclination towards the second. --bill
On Nov 3, 2008, at 16:05, bmanning@vacation.karoshi.com wrote:
10. The organisation that generates the root zone file must hold the private part of the zone signing key.
the imperative in this point is made with zero justification. why the "must hold"?
Well, it will be hard to sign the root if the entity that generates the zone hasn't got access to the private part of the ZSK.
On Mon, Nov 03, 2008 at 04:12:02PM +0000, Jim Reid wrote:
On Nov 3, 2008, at 16:05, bmanning@vacation.karoshi.com wrote:
10. The organisation that generates the root zone file must hold the private part of the zone signing key.
the imperative in this point is made with zero justification. why the "must hold"?
Well, it will be hard to sign the root if the entity that generates the zone hasn't got access to the private part of the ZSK.
thats hardly true - unless the presumptive argument is that the generator also signs. going w/ your earlier thread, the pragmatic approach (get the zoen signed this decade) is exactly down that line of argument. I, however, am taking a slightly divergent POV. I think it si required to create a third party to generate/hold/use the keys (some blend of options #3 and #6 in the graphics) a strictly technical solution would be to eliminate two of the three parties currently involved. there is no technical reason things are structured they way they are today. there are sound political reasons to create a new structure, one that does not assemble the data or publish the data but simply attests to the data. anyway, point 10 woudl be clearer if the reason fo rthe must was made explicit. --bill
On Nov 3, 2008, at 16:22, bmanning@vacation.karoshi.com wrote:
thats hardly true - unless the presumptive argument is that the generator also signs.
Well Bill, that seems to be a valid assumption as far as this WG goes. Other options are theoretically possible, but from a pragmatic PoV they don't make sense IMO. Having one entity create an unsigned file to give to someone else to sign (and distribute?) just adds more complexity and more opportunities for things to go wrong. One could also argue that "generating" the zone includes the insertion of RRSIGs, DS records, NSEC3 and so on.
going w/ your earlier thread, the pragmatic approach (get the zoen signed this decade) is exactly down that line of argument.
Indeed. Let's get the root signed! Soon!
I, however, am taking a slightly divergent POV. I think it si required to create a third party to generate/hold/use the keys (some blend of options #3 and #6 in the graphics)
a strictly technical solution would be to eliminate two of the three parties currently involved. there is no technical reason things are structured they way they are today.
By all means Bill express that as your view when you respond to the NTIA consultation. However please don't open up that can of worms here. There are diverging (perhaps mutually exclusive) views in this WG about which of the NTIA proposals are better/ideal/preferred. I doubt a consensus can emerge around one of them from the WG and we've pretty much decided not to try and look for that because it's likely to be impossible in the time available, if ever. Instead, there's a consensus to state the general high-level principles that we would like to see in a signed DNS root. This was the general direction which prevailed in Dubai last week.
there are sound political reasons to create a new structure, one that does not assemble the data or publish the data but simply attests to the data.
Well so far Bill, I hear no-one else supporting that view. I would advise the WG against exploring this approach right now. Firstly, the clock is ticking. If we can't get consensus on an NTIA response by the end of this week, it's over. If the WG can't make up its mind by then, we can't ask for RIPE community endorsement in time to get something sent to NTIA by the deadline. Which is just 3 weeks away. The second reason is that raising the prospect of creating a new structure will open up all sorts of layer-9 and above rat-holes that will take forever to resolve. This will give the politicians and lawyers an opportunity to pile in and start arguments that will go on until the start of the next Ice Age. IMO that would be bad.
anyway, point 10 woudl be clearer if the reason fo rthe must was made explicit.
Noted. Can we agree to leave the matter there? I'll add some explanatory text for the next version.
On Mon, Nov 03, 2008 at 11:56:16PM +0000, Jim Reid wrote:
On Nov 3, 2008, at 16:22, bmanning@vacation.karoshi.com wrote:
By all means Bill express that as your view when you respond to the NTIA consultation. However please don't open up that can of worms here.
just providing a bit of backing material on some of the unstated assumptions in the RIEP WG response. I have no intention to debate the relative merits over email. (But if I can have a quiet chat over there in the bar w/ you...)
anyway, point 10 woudl be clearer if the reason fo rthe must was made explicit.
Noted. Can we agree to leave the matter there? I'll add some explanatory text for the next version.
i think that will help make the point. (as a native english speaker :) --bill
On 3 nov 2008, at 18.05, bmanning@vacation.karoshi.com wrote:
I think a more pragmatic reply (if the previous points are to be respected) would be something along these lines:
10. The organization that generates the root zone file must sign the file and therefore must hold the private part of the zone signing key.
or
10. The organization that generates the root zone file must have unfettered access to the zone signing key components.
I have a slight inclination towards the second.
I think the first of these is better as the word "unfettered" is not easy to understand if one is not english speaking. I for one have no idea what it means... The simpler the text, the better. Patrik
On Mon, Nov 03, 2008 at 09:11:18PM +0200, Patrik FC$ltstrC6m wrote:
On 3 nov 2008, at 18.05, bmanning@vacation.karoshi.com wrote:
I think a more pragmatic reply (if the previous points are to be respected) would be something along these lines:
10. The organization that generates the root zone file must sign the file and therefore must hold the private part of the zone signing key.
or
10. The organization that generates the root zone file must have unfettered access to the zone signing key components.
I have a slight inclination towards the second.
I think the first of these is better as the word "unfettered" is not easy to understand if one is not english speaking. I for one have no idea what it means...
The simpler the text, the better.
Patrik
Main Entry: fetB7ter Pronunciation: \Kfe-tIr\ Function: noun Etymology: Middle English feter, from Old English; akin to Old English fE t foot Date: before 12th century 1 : a chain or shackle for the feet 2 : something that confines : restraint that clarified, if you are happier with the first choice, i think it will make the response a better one than the current text. --bill
10. The organization that generates the root zone file must sign the file and therefore must hold the private part of the zone signing key.
or
10. The organization that generates the root zone file must have unfettered access to the zone signing key components.
The second version seems to exclude storing the ZSK in an HSM. The first version is more ambiguous. In both cases, I don't quite see what the statement is supposed to mean. Does it advise against the introduction of yet another layer of indirection, by requiring that the organization which makes the final, technical content decision on the root zone (the "generator") also creates the digital signatures? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Thu, Nov 06, 2008 at 12:06:30PM +0100, Florian Weimer wrote:
10. The organization that generates the root zone file must sign the file and therefore must hold the private part of the zone signing key.
or
10. The organization that generates the root zone file must have unfettered access to the zone signing key components.
The second version seems to exclude storing the ZSK in an HSM. The first version is more ambiguous. In both cases, I don't quite see what the statement is supposed to mean. Does it advise against the introduction of yet another layer of indirection, by requiring that the organization which makes the final, technical content decision on the root zone (the "generator") also creates the digital signatures?
--
the first statement is an amplification ... the added text is "...and therefore..." eg. the org must hold the private key if it is going to sign the zone. the second actually does no preclude an HSM, but does acknowledge the NoI requirement that the administrator must have access to the signing keys (both K&Z, public and private). --bill
On Nov 6, 2008, at 11:06, Florian Weimer wrote:
In both cases, I don't quite see what the statement is supposed to mean. Does it advise against the introduction of yet another layer of indirection, by requiring that the organization which makes the final, technical content decision on the root zone (the "generator") also creates the digital signatures?
It means whoever churns out the zone file for the root should also generate the RRSIGs for the signed version => having access to the ZSK.
On Mon, Nov 03, 2008 at 11:09:18AM +0000, Jim Reid <jim@rfc1035.com> wrote a message of 94 lines which said:
I have updated the list of bullet points to reflect the recent comments and feedback.
The list of bullet points seems reasonable to me and reflects faithfully the discussions IRL in Dubai. However, the new introductory paragraph is very questionable:
RIPE welcomes the NTIA's consultation on the proposals to sign the root and is pleased to support that effort.
RIPE certainly has no business issuing political statements of support like this one! I certainly do not approve the fact that the root signing process is driven by the NTIA and I believe many people in RIPE do not approve either. Let's stick with what we want and do not add any sort of support or applause for the unilateral management of the process by the NTIA.
We urge the NTIA to adopt a solution that leads to a prompt signed root zone.
Same thing here. Stay with technical requirments, do not ask a specific organization to do something.
On Nov 4, 2008, at 11:05, Stephane Bortzmeyer wrote:
RIPE welcomes the NTIA's consultation on the proposals to sign the root and is pleased to support that effort.
RIPE certainly has no business issuing political statements of support like this one! I certainly do not approve the fact that the root signing process is driven by the NTIA and I believe many people in RIPE do not approve either. Let's stick with what we want and do not add any sort of support or applause for the unilateral management of the process by the NTIA.
Stephane, I do not believe this interpretation can be drawn from the opening paragraphs. It's common courtesy to respond to these sorts of consultations by thanking the organisation for offering an opportunity to comment. This does not mean endorsement or acceptance that the people doing the consultation have some form of authority or control over whatever the consultation is about. However let's not debate this: the clock is ticking. Please contribute text. It is not helpful to just say "I don't like this". Please suggest alternate wording that addresses your concerns and could serve as a suitable introduction to our response. I realise some members of this WG do not like the NTIA's involvement in the root zone. However the reality is that unless the NTIA does something (for some definition of something), there won't be a signed root before our grandchildren retire. And if the Internet community doesn't support the NTIA proposals (for some definition of support), the politicians and bureaucrats will intervene to kill or indefinitely postpone the creation of a signed root because they can justifiably claim that support is not there. So the choice here is clear: either the world continues with an unsigned root or it gets a signed root that has involvement of an organisation that some of us would prefer not to have a role in the oversight DNS root.
We urge the NTIA to adopt a solution that leads to a prompt signed root zone.
Same thing here. Stay with technical requirments, do not ask a specific organization to do something.
Same here: suggest alternate text. How about "We urge the adoption of a solution that leads to a prompt signed root zone."?
On Wed, Nov 05, 2008 at 11:11:33AM +0000, Jim Reid <jim@rfc1035.com> wrote a message of 44 lines which said:
Please contribute text.
OK. I suggest to replace: "RIPE welcomes the NTIA's consultation on the proposals to sign the root and is pleased to support that effort. We urge the NTIA to adopt a solution that leads to a prompt signed root zone. The solution must not compromise the stability and integrity of the root zone management process." by: "RIPE wants the root zone to be signed, in order to enable an easier deployment of DNSSEC." and then go on with your text.
On Nov 5, 2008, at 16:37, Stephane Bortzmeyer wrote:
On Wed, Nov 05, 2008 at 11:11:33AM +0000, Jim Reid <jim@rfc1035.com> wrote a message of 44 lines which said:
Please contribute text.
OK. I suggest to replace:
"RIPE welcomes the NTIA's consultation on the proposals to sign the root and is pleased to support that effort. We urge the NTIA to adopt a solution that leads to a prompt signed root zone. The solution must not compromise the stability and integrity of the root zone management process."
by:
"RIPE wants the root zone to be signed, in order to enable an easier deployment of DNSSEC."
and then go on with your text.
Stephane, this your text is somewhat abrupt. I do not consider it appropriate for any formal correspondance, far less something that represents the DNS WG and/or the RIPE community. Our response should be courteous and observe the expected niceties: like thanking NTIA for running a consultation and giving the world a chance to comment. Which the NTIA didn't *have* to do. I will try to construct something from your input that (a) is something the WG/RIPE community can accept as a consensus view; (b) observes the usual etiquette which both parties should follow.
participants (5)
-
bmanning＠vacation.karoshi.com -
Florian Weimer -
Jim Reid -
Patrik Fältström -
Stephane Bortzmeyer