Colleagues, you may recall Olaf posted a proposal to the list a few weeks ago. It was about changes to the in-addr.arpa delegation process to accommodate DNSSEC. In other words, updates to the templates and database to allow for keying material, additional checks at the NCC, etc, etc. I'm surprised and a little disappointed that nobody has commented on Olaf's proposal. Perhaps the timing was bad. Since the proposal emerged in the run-up to an IETF during the summer holidays, maybe everyone was too busy getting a sun tan or reading the latest IETF I- Ds. :-) Olaf suggested a deadline of early August for the consultation period. There's been no response on the list, so I'm reluctant to declare consensus without some feedback from the WG. It would not be wise to presume that the WG's silence implied unqualified consent. So, following a discussion with Peter and Jaap, your WG co-chairs have decided to extend the deadline for comments until the end of August. The WG chairs have a meeting on Aug 31st, so that would be a good opportunity to take the proposed policy forward. I would like to ask all members of the WG to read Olaf's proposal and comment on it before Aug 31st, even if it's just to say that you think the proposal is fine as it is. Your comments and feedback would be greatly appreciated. Thanks.
Olaf, Jim, all,
Colleagues, you may recall Olaf posted a proposal to the list a few weeks ago. It was about changes to the in-addr.arpa delegation process to accommodate DNSSEC. In other words, updates to the templates and database to allow for keying material, additional checks at the NCC, etc, etc.
To my eyes the proposal is good and I am happy somebody is taking the plunge. Congratulations. Two comments: http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html To a layman, the meaning of DLV can't be tracked down. A reference missing? http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html I suggest making the ds-rdata attribute an [inverse key] Best regards, Marcos
http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html To a layman, the meaning of DLV can't be tracked down. A reference missing?
Thanks for your comments Marcos. I personally think the reference to DLV needs to be replaced with something more generic. IIUC, so far nothing has been openly published about Domain Lookaside Validation and the code supporting it in BIND9.3 doesn't work. It may be that production quality DLV never sees the light of day or that some other (ad hoc?) mechanisms emerge for establishing DNSSEC trust anchors. And since the NCC is supposed to be neutral, it shouldn't be seen to be favouring one technique/kludge over another. [Even though nothing else like DLV seems to be on the horizon at present.] And since the authors of DLV hope this scheme would be short-lived, it may not be a good idea to explicitly mention DLV in a policy document. Whenever DLV died or got superseded, the document would need to be updated if it mentioned DLV. So from that perspective, it may be better if the text in the proposal was made more generic. Perhaps it should say something like "The NCC would consider publishing its KSKs in appropriate registries that may emerge to facilitate the establishment of DNSSEC trust anchors"? Another suggestion: how about establishing a trust anchor for .arpa and have the NCC's KSKs signed by that? This might help the other RIRs to sign their reverse trees or allow DNSSEC to spread into the IPv6 and ENUM worlds. Any comments?
Jim,
I personally think the reference to DLV needs to be replaced with something more generic
I concur.
So from that perspective, it may be better if the text in the proposal was made more generic. Perhaps it should say something like "The NCC would consider publishing its KSKs in appropriate registries that may emerge to facilitate the establishment of DNSSEC trust anchors"?
I don't think that would be even necessary. The document already states " Maintenance of these keys is a process that does not scale well. We are working to come up with a solution to this issue."
how about establishing a trust anchor for .arpa and have the NCC's KSKs signed by that?
Is .arpa signed? Regards, Marcos
On Aug 23, 2005, at 16:52, Marcos Sanz/Denic wrote:
Is .arpa signed?
No. But it should be orders of magnitude easier to do that than get DLV to fly. :-) In principle IAB could sign .arpa tomorrow, assuming someone was able and willing to hold its KSKs.
At 17:12 +0100 8/23/05, Jim Reid wrote:
On Aug 23, 2005, at 16:52, Marcos Sanz/Denic wrote:
Is .arpa signed?
No. But it should be orders of magnitude easier to do that than get DLV to fly. :-) In principle IAB could sign .arpa tomorrow, assuming someone was able and willing to hold its KSKs.
Don't forget "in-addr.arpa." and "ip6.arpa." - they delegate some of NCC's zones. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Is .arpa signed? No. But it should be orders of magnitude easier to do that than get DLV to fly. :-) In principle IAB could sign .arpa tomorrow, assuming someone was able and willing to hold its KSKs. Don't forget "in-addr.arpa." and "ip6.arpa." - they delegate some of NCC's zones.
and don't forget that this does not scale. manual coordination to maintain trusted keys for 292 tlds just does not work. and that assumes that the tlds are signed, not counting all the thrid and ninth level zones that make noise when the zones above them are not signed. this does not fly until the root is signed. and that does not fly until there is a key management plan and technology for it. randy
On Aug 26, 2005, at 21:26, Randy Bush wrote:
In principle IAB could sign .arpa tomorrow, assuming someone was able and willing to hold its KSKs.
Don't forget "in-addr.arpa." and "ip6.arpa." - they delegate some of NCC's zones.
and don't forget that this does not scale.
Randy, you've confused me. What aspect of DNSSEC specifically "does not scale"? Do you mean having everyone embed trust anchors in their name server configurations for every signed TLD while we wait for the root to be signed? If so, I agree that's not scalable. But that's not what was under discussion here. At least I hope it wasn't.
manual coordination to maintain trusted keys for 292 tlds just does not work. and that assumes that the tlds are signed, not counting all the thrid and ninth level zones that make noise when the zones above them are not signed.
I raised the prospect of getting .arpa signed, not 292 tlds. If this was done, there would be one trust anchor for infrastructure zones and that should simplify things in the context of the NCC's proposals for deploying DNSSEC. Perhaps that might help the other RIRs to follow the NCC's lead. It should also allow us to get operational experience in handling keying material, signing policies and so on that could inform the discussion on getting the root signed. ie Once the layer-9 stuff about that stopped (if it ever will), the lessons learned from gradually deploying DNSSEC in .arpa could provide a valuable knowledge base of practical experience to draw on.
this does not fly until the root is signed. and that does not fly until there is a key management plan and technology for it.
Well yes. But somebody has to start somewhere. IMO signing .arpa could/should be a stepping stone towards that goal. Please note these are my personal opinions and the usual disclaimers apply.
Randy, you've confused me. What aspect of DNSSEC specifically "does not scale"? Do you mean having everyone embed trust anchors in their name server configurations for every signed TLD while we wait for the root to be signed?
yep
If so, I agree that's not scalable. But that's not what was under discussion here. At least I hope it wasn't.
no. you just want me to hold the trust keys for the zones you think are important. and, in today's email (for some value of 'today'), brett warns us that he has a handful of third level zones he thinks are important enough. hence "does not scale." randy
Just extracting one sentence out of Randy's e-mail:
no. you just want me to hold the trust keys for the zones you think are important. and, in today's email (for some value of 'today'), brett warns us that he has a handful of third level zones he thinks are important enough.
hence "does not scale."
RIPE NCC thinks it is important enough to sign the zones. If any of these handful of third level zones is not important enough for your operations to go through the trouble of validating then you do not need to configure them; During early deployment of DNSSEC, there is a burden for the validating clients. I agree that if we do not get to a point where validators only have to configure between one and a handful of trust-anchors and those trust-anchors get automatically rolled DNSSEC will not reach the masses. On the other hand we have to start deploying somewhere. Olaf Kolkman PS: The IETF DNSEXT group has a work item on automatic key-rollover; work is progressing slowly.
I agree that if we do not get to a point where validators only have to configure between one and a handful of trust-anchors and those trust-anchors get automatically rolled DNSSEC will not reach the masses.
On the other hand we have to start deploying somewhere.
while i do have sympathy for this, when i consider, or try to consider, what the trust model and reliability of low-level roll-out of a hundred or a thousand scattered zones, the mind boggles. as trust keys require manual maintenance, there will be seemingly random failures, real fun debugging, ... and the trust won't distribute, it's SxC. hence, i think of it as more operational practice than deployment. testing whether folk can configure servers and clients, and reconfigure them, and debug them, and ... in a sense, this is a good thing. in another sense, it is expensive at a time when we are not rich. randy
On Aug 30, 2005, at 17:09, Randy Bush wrote:
I agree that if we do not get to a point where validators only have to configure between one and a handful of trust-anchors and those trust-anchors get automatically rolled DNSSEC will not reach the masses.
On the other hand we have to start deploying somewhere.
while i do have sympathy for this, when i consider, or try to consider, what the trust model and reliability of low-level roll-out of a hundred or a thousand scattered zones, the mind boggles. as trust keys require manual maintenance, there will be seemingly random failures, real fun debugging, ... and the trust won't distribute, it's SxC.
This is why I suggested starting with trying to get .arpa signed. Since it's controlled by the IAB, the zone should be free from the level-9 (and up) issues that infest the root. That would/should mean a single trust anchor for those who wanted to take part in the first faltering steps towards DNSSEC deployment. In the context of what the NCC is proposing, that would mean .arpa signing the KSKs for the stuff delegated by IANA to the NCC. This has to be better than having a bunch of trust anchors for each apex under ip6.arpa and in- addr.arpa -- let's not forget e164.arpa too -- that's managed by the NCC. We appear to agree that path is less than desirable.
Marcos, Marcos Sanz/Denic wrote:
http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html I suggest making the ds-rdata attribute an [inverse key]
Yes, that makes sense. Unless there are objections, we will implent this in the server. -- Shane Kerr RIPE NCC
On Tue, 23 Aug 2005 16:56:49 +0200 Marcos Sanz/Denic <sanz@denic.de> wrote:
To my eyes the proposal is good and I am happy somebody is taking the plunge. Congratulations. Two comments:
http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html To a layman, the meaning of DLV can't be tracked down. A reference missing?
As far as I know, at that time there wasn't a publication to refer to at the time that the procedure was published. There are now two: an ID from Sam Weiler and an articl in a Journal from Paul Vixie. It describes similar methods which different details. jaap
Hi Jim, If I may bring this thread back on track. I don't know why the WG is asked to comment on procedure as well as policy, but here goes: What does "reasonable" mean in the below sentence on: http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html "Is the signature validity period close to expiring and are the Times To Live (TTLs) a reasonable fraction of the signature validity period?" I'm confused about this para on same page: "Web Interface Restrictions We will develop a web interface to make it easy to create domain objects with the appropriate "ds-rdata:" attributes. It will have some operational restrictions It will use the SEP flag to select the keys for which DSRRs are needed. It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute." How do you use the "currently available object" to create an object if this object doesn't exist until you create it? I am clearly missing smt, but it escapes me at the moment. I support Jim's suggestion in re: generic replacement of "DLV" mention. The rest looks fine to me, -- Cheers, McTim nic-hdl: TMCG
Hello McTim.
I don't know why the WG is asked to comment on procedure as well as policy, but here goes:
Input on the procedure is more than welcome. Thanks!
What does "reasonable" mean in the below sentence on: http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
"Is the signature validity period close to expiring and are the Times To Live (TTLs) a reasonable fraction of the signature validity period?"
This refers to draft-ietf-dnsop-dnssec-operational-practices-04 section 4.1.1. o We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period. If the TTL would be of similar order as the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of [2] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL". As a result query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches. To avoid query load peaks we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. We currently test on the TTL being at least 2 times smaller than the signature validity period.
I'm confused about this para on same page:
"Web Interface Restrictions We will develop a web interface to make it easy to create domain objects with the appropriate "ds-rdata:" attributes. It will have some operational restrictions
It will use the SEP flag to select the keys for which DSRRs are needed.
It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute."
How do you use the "currently available object" to create an object if this object doesn't exist until you create it?
That text applies to when a key rollover is being performed. During the initial upload the default is the DNSKEY RR with the SEP flag set.
I am clearly missing smt, but it escapes me at the moment.
I support Jim's suggestion in re: generic replacement of "DLV" mention.
On the issue of the DLV registries: the intention is that in the absence of a signed root we will try to participate in initiatives that allow for 'easy' trust anchor maintenance. Since DLV is the only technique currently under discussion so that got hard-wired into the procedure document. As soon as the root and intermediary zones are signed it is probably best to move away from these alternative key distribution mechanism. At this moment there is no working DLV implementation, nor a DLV registry to participate in. I hope this clarifies. --Olaf Kolkman
HI Olafje, On 8/30/05, Olaf M. Kolkman <olaf@ripe.net> wrote: ttp://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
"Is the signature validity period close to expiring and are the Times To Live (TTLs) a reasonable fraction of the signature validity period?"
<snip> We currently test on the TTL being at least 2 times smaller than the signature validity period.
ok, ta, sounds "reasonable" to me.
I'm confused about this para on same page:
It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute."
How do you use the "currently available object" to create an object if this object doesn't exist until you create it?
That text applies to when a key rollover is being performed. During the initial upload the default is the DNSKEY RR with the SEP flag set.
aha, sorry it wasn't clear to me at the time, it is now. Will it be clear to non-english speakers who try to follow the procedure? Maybe a mention of the key rollover would generate less confusion? <snip>
I hope this clarifies.
yes, thnx. -- Greetz, McTim nic-hdl: TMCG
participants (8)
-
Edward Lewis -
Jaap Akkerhuis -
Jim Reid -
Marcos Sanz/Denic -
McTim -
Olaf M. Kolkman -
Randy Bush -
Shane Kerr