I have updated the draft response to reflect today's comments. Aside from tweaking the introductory paragraph -- I hope this now sets the right tone without upsetting Stephane -- the significant change was to move Rick's comments about trust to nomber 4 from number 12 on the list. This seemed to be a more suitable place for this point. Is version 5 of the draft now something that the WG as a whole can accept? 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. Within reason of course.... # # $Id: ntia-draft,v 1.6 2008/11/05 22:36:42 jim Exp $ # The RIPE community (or DNS WG?) thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC. 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 does not compromise the security and stability of the Domain Name System. 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. 5. Deployment of a signed root should be done in a timely but not hasty manner. 6. 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. 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. 8. There is no technical justification to create a new organisation to oversee the process of signing of the root. 9. No data should be moved between organisations without appropriate authenticity and integrity checking. 10. The public part of the key signing key must be distributed as widely as possible. 11. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key. 12. Changes to the entities and roles in the signing process must not necessarily require a change of keys.
much better - wrt the opening statement, I suspect this should be couched as a response from teh RIPE DNS WG and not the Ripe community as a whole, since I suspect they have not seen the text or had a chance to comment on the same. --bill
On Nov 5, 2008, at 23:01, bmanning@vacation.karoshi.com wrote:
much better - wrt the opening statement, I suspect this should be couched as a response from teh RIPE DNS WG and not the Ripe community as a whole, since I suspect they have not seen the text or had a chance to comment on the same.
Bill, the algorithm here is: if (no wg consensus by this weekend) give up send agreed WG text to ripe-announce if (ripe consensus by Nov 20th-ish) send letter(we == RIPE community) else send letter(we == DNS WG)
On Thu, Nov 06, 2008 at 01:25:02PM +0000, Jim Reid wrote:
On Nov 5, 2008, at 23:01, bmanning@vacation.karoshi.com wrote:
much better - wrt the opening statement, I suspect this should be couched as a response from teh RIPE DNS WG and not the Ripe community as a whole, since I suspect they have not seen the text or had a chance to comment on the same.
Bill, the algorithm here is:
if (no wg consensus by this weekend) give up send agreed WG text to ripe-announce if (ripe consensus by Nov 20th-ish) send letter(we == RIPE community) else send letter(we == DNS WG)
ack... thanks. --bill
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)
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.
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
On Nov 6, 2008, at 18:10, Peter Koch wrote:
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.
This is true. The people who make those arguments for a new organisation or role to oversee DNSSEC in the root will make them regardless. But for those who have to debate that issue at places like IGF, it would be helpful them to point to community statements which say "we don't see a technical justification for adding another level of bureaucracy to the process".
(I seem to have lost the message I actually wanted to reply to...) FWIW, I've been lurking and following the discussion. The current response seems sensible to me. I guess it is obvious that the NTIA can come back to us and for further discussion/clarification? David.
:Jim Reid wrote Jim, I speak in hat as a member of ccTLD .ru dnssec wg. We can support this statement in general too.. For us - it will be most important to get more flexibility in current situation. You should understand that we translated some pieces of text in our ways. and our interpretation in Russion could be different. I am personally think that you and Patrick did a great job. I expect that in result we can give our own statement aligned wittoo.h this one and with Russian translation and interpretation thanks, Dima
I have updated the draft response to reflect today's comments. Aside from tweaking the introductory paragraph -- I hope this now sets the right tone without upsetting Stephane -- the significant change was to move Rick's comments about trust to nomber 4 from number 12 on the list. This seemed to be a more suitable place for this point.
Is version 5 of the draft now something that the WG as a whole can accept?
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. Within reason of course....
# # $Id: ntia-draft,v 1.6 2008/11/05 22:36:42 jim Exp $ #
The RIPE community (or DNS WG?) thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC.
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 does not compromise the security and stability of the Domain Name System.
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.
5. Deployment of a signed root should be done in a timely but not hasty manner.
6. 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.
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.
8. There is no technical justification to create a new organisation to oversee the process of signing of the root.
9. No data should be moved between organisations without appropriate authenticity and integrity checking.
10. The public part of the key signing key must be distributed as widely as possible.
11. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key.
12. Changes to the entities and roles in the signing process must not necessarily require a change of keys.
participants (5)
-
bmanning＠vacation.karoshi.com -
David Malone -
Dmitry Burkov -
Jim Reid -
Peter Koch