From jim at rfc1035.com Thu Oct 18 09:56:23 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 18 Oct 2007 08:56:23 +0100 Subject: [dnssec-key-tf] Agenda for Monday Message-ID: We really should have an agenda for the meeting on Monday. Any suggestions? My thoughts on this are: [1] TAR - yes or no? The WG was split down the middle on this in Tallin and IMO our TF has yet to consider this issue in detail. The TF discussions so far have tended to work on the assumption that a TAR should exist, which is not a representative view. [2] What properties should a TAR have? Trusted, neutral, etc. I think we've got a rough consensus here. [3] What format should the TAR data be provided? [4] What processes are used for verifying new or updated trust anchors? [5] What are the performance indicators/metrics for a TAR? ie When can it be judged a success or failure and when can it be shut down Maybe we just decide to do the crossword and wait to see what Richard Lamb has to say during the plenary? :-) We can of course discuss these topics on this list. And in some ways I'm trying to provoke that discussion. But if we could give some thought about how to productively use our time together on Monday... From dfk at ripe.net Thu Oct 18 13:52:44 2007 From: dfk at ripe.net (Daniel Karrenberg) Date: Thu, 18 Oct 2007 13:52:44 +0200 Subject: [daniel.karrenberg@ripe.net: Re: [dnssec-key-tf] Agenda for Monday] Message-ID: <20071018115244.GA423@reiftel.karrenberg.net> Oh well, I *am* on this list. Daniel -------------- next part -------------- An embedded message was scrubbed... From: Daniel Karrenberg Subject: Re: [dnssec-key-tf] Agenda for Monday Date: Thu, 18 Oct 2007 13:49:58 +0200 Size: 2698 Url: https://www.ripe.net/ripe/mail/archives/dnssec-key-tf/attachments/20071018/04c0635d/attachment.mht From jim at rfc1035.com Thu Oct 18 13:58:10 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 18 Oct 2007 12:58:10 +0100 Subject: [dnssec-key-tf] Agenda for Monday In-Reply-To: <20071018114958.GE407@reiftel.karrenberg.net> References: <20071018114958.GE407@reiftel.karrenberg.net> Message-ID: On Oct 18, 2007, at 12:49, Daniel Karrenberg wrote: > I have already sugested to invite Richar and anybody else from IANA > to our meeting. Shall I do this if in case Jim is too busy? Please do Daniel. I didn't even realise I held this token. Thanks for the improved agenda too. From daniel.karrenberg at ripe.net Thu Oct 18 13:49:58 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 Oct 2007 13:49:58 +0200 Subject: [dnssec-key-tf] Agenda for Monday In-Reply-To: References: Message-ID: <20071018114958.GE407@reiftel.karrenberg.net> On 18.10 08:56, Jim Reid wrote: > We really should have an agenda for the meeting on Monday. Any > suggestions? My thoughts on this are: > > [1] TAR - yes or no? > The WG was split down the middle on this in Tallin and IMO our TF > has yet to consider this issue in detail. The TF discussions so far > have tended to work on the assumption that a TAR should exist, which > is not a representative view. > > [2] What properties should a TAR have? > Trusted, neutral, etc. I think we've got a rough consensus here. > > [3] What format should the TAR data be provided? > > [4] What processes are used for verifying new or updated trust anchors? > > [5] What are the performance indicators/metrics for a TAR? > ie When can it be judged a success or failure and when can it be > shut down > > > Maybe we just decide to do the crossword and wait to see what Richard > Lamb has to say during the plenary? :-) I suppose he is going to talk about the 'demo' service at https://ns.iana.org/dnssec/status.html and its associated port 53 service. I have already sugested to invite Richar and anybody else from IANA to our meeting. Shall I do this if in case Jim is too busy? > We can of course discuss these topics on this list. And in some ways > I'm trying to provoke that discussion. But if we could give some > thought about how to productively use our time together on Monday... To repeat: IANA is alread offering a service that very much looks like what the SE people asked for. IANA is the best place to do this because it is at the right place in the DNS tree to do this without the danger of creating a separate trust hierarchy. As to productively using time: We should use our time to learn about this service and discuss the questions 2-5 in the light of giving suggestions to the IANA. We should also draft a statement that (the) RIPE (DNS WG) could adopt welcoming and endorsing this initiative by the IANA and re-inforcing it by stating that we will not take our own initiativesin this area as long as this service remains available while the root is not signed. Daniel From dfk at ripe.net Thu Oct 18 15:29:14 2007 From: dfk at ripe.net (Daniel Karrenberg) Date: Thu, 18 Oct 2007 15:29:14 +0200 Subject: [dnssec-key-tf] Re: Invitation to DNSSEC Key Repository Task Force Monday 0900 Amsterdam In-Reply-To: <20071018123620.GA1277@reiftel.karrenberg.net> References: <20071018123620.GA1277@reiftel.karrenberg.net> Message-ID: <20071018132914.GC423@reiftel.karrenberg.net> On 18.10 14:36, Daniel Karrenberg wrote: > > Richard, > > can I call on you to join us at 0900 on Monday in the grand ballroom of the Kras > for a task force meeting. See http://www.ripe.net/ripe/meetings/ripe-55/meeting-plan.html Sorry, too much going on and agendas changing too often. The correct time is as noted in the link *1100* and not 0900. Much mre civil..... ;-) My fault, sorry again. From daniel.karrenberg at ripe.net Thu Oct 18 14:36:20 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 Oct 2007 14:36:20 +0200 Subject: [dnssec-key-tf] Invitation to DNSSEC Key Repository Task Force Monday 0900 Amsterdam Message-ID: <20071018123620.GA1277@reiftel.karrenberg.net> Richard, can I call on you to join us at 0900 on Monday in the grand ballroom of the Kras for a task force meeting. See http://www.ripe.net/ripe/meetings/ripe-55/meeting-plan.html The task force was set up to address requests for a DNSSEC Trust Anchor repository which came up at the last RIPE meeting. See the minutes at: http://www.ripe.net/ripe/wg/dns/r54-minutes.html I have proposed to the TF to look at the IANA's "demo" service as sufficient to fulfill the needs raised. See the attached message. It sould be very nice if you could join us, inform the task force about what IANA is doing here and take back any suggestions that we may have. I hop you can make it. Please let me know. In case you cannot, can we at lease have a few words of explanation and maybe your slide pack for the presentation that you will give later in the week? Thanks Daniel -------------- next part -------------- An embedded message was scrubbed... From: Daniel Karrenberg Subject: Re: [dnssec-key-tf] Agenda for Monday Date: Thu, 18 Oct 2007 13:49:58 +0200 Size: 2698 Url: https://www.ripe.net/ripe/mail/archives/dnssec-key-tf/attachments/20071018/bad9a8c9/attachment.mht From daniel.karrenberg at ripe.net Thu Oct 18 14:38:48 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 Oct 2007 14:38:48 +0200 Subject: [dnssec-key-tf] Agenda for Monday In-Reply-To: References: <20071018114958.GE407@reiftel.karrenberg.net> Message-ID: <20071018123848.GC1277@reiftel.karrenberg.net> On 18.10 12:58, Jim Reid wrote: > On Oct 18, 2007, at 12:49, Daniel Karrenberg wrote: > > >I have already sugested to invite Richar and anybody else from IANA > >to our meeting. Shall I do this if in case Jim is too busy? > > Please do Daniel. I didn't even realise I held this token. Thanks for > the improved agenda too. Done, see copy. From daniel.karrenberg at ripe.net Fri Oct 19 18:28:43 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 19 Oct 2007 18:28:43 +0200 Subject: [dnssec-key-tf] Agenda for Monday In-Reply-To: <20071018123848.GC1277@reiftel.karrenberg.net> References: <20071018114958.GE407@reiftel.karrenberg.net> <20071018123848.GC1277@reiftel.karrenberg.net> Message-ID: <20071019162843.GH423@reiftel.karrenberg.net> On 18.10 14:38, Daniel Karrenberg wrote: > On 18.10 12:58, Jim Reid wrote: > > On Oct 18, 2007, at 12:49, Daniel Karrenberg wrote: > > > > >I have already sugested to invite Richar and anybody else from IANA > > >to our meeting. Shall I do this if in case Jim is too busy? > > > > Please do Daniel. I didn't even realise I held this token. Thanks for > > the improved agenda too. > > Done, see copy. Richard has just confirmed to me that he will join us. Daniel From jim at rfc1035.com Fri Oct 19 23:47:48 2007 From: jim at rfc1035.com (Jim Reid) Date: Fri, 19 Oct 2007 22:47:48 +0100 Subject: [dnssec-key-tf] Agenda for Monday In-Reply-To: <20071019162843.GH423@reiftel.karrenberg.net> References: <20071018114958.GE407@reiftel.karrenberg.net> <20071018123848.GC1277@reiftel.karrenberg.net> <20071019162843.GH423@reiftel.karrenberg.net> Message-ID: On Oct 19, 2007, at 17:28, Daniel Karrenberg wrote: > Richard has just confirmed to me that he will join us. Thanks Daniel. From jim at rfc1035.com Mon Oct 22 12:44:19 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 22 Oct 2007 11:44:19 +0100 Subject: [dnssec-key-tf] notes from today's discussion Message-ID: Here are my notes from today's discussion. Please let me know if I have missed anything or misrepresented anyone's questions and opinions. I will prepare some slides for the WG tomorrow and circulate them for comment and review to the TF before they go to the WG. should we have a TAR? creating a trust hierarchy parallel to DNS is unwise takes pressure off ICANN to solve the later 9 problems DFK - TAR may be moot considering IANA development experimental service for TLDs helpful to getting the root signed because it's homed at IANA Richard Lamb IANA demo is a solid implementation serious effort plan SLAs for slave servers spent money on crypto hardware too early to say for future directions still at an early evaluation phase hope to sign .arpa by ICANN meeting next week TLD operator can go to web site tells IANA to fetch keys fetch keys from DNS -- scp, SSL? IANA generates DS records TLD approves generated DS record before it goes into root no authentication yet of TLD operator making the request DFK - IANA must ensure request comes from real TLD operator MS - leverage existing IANA relationships with TLDs RA - will new kets be automatically picked up no: IANA not considered yet JD - ISC runs similar TAR struggling with authenticating zone owner ISC sends a cookie which zone owner must sign & publish JD - IANA is the right place for this JD will IANA system go beyond a demo? RL - count on this for .arpa JD IANA's intentions for a root management system will effectively be a repository hold tokens LJL - consequences of tests with a signed root could create a shadow/alternate root hierarchy change relationships with existing root operators DFK - WG concerns that the TAR is stable and "permanent" more assurances would help JR - what about the NCC acting as an escrow to IANA? DFK - a cold standby service could be a good idea JD concerns about commitment to renew the keys LJL reponsibility for new keys lies with the child DFK cold standby could archive TLD keys & flag changes PK - I hear backup and hear contingency planning When would standby be activated? Should standby be harvesting keys while it is inactive? RL - trust anchors for TLDs only? LV who would use this? concerns not to turn experimental service into production must not give rise to a look and feel of an alternate root DFK - how to answer Swedish request JD - publish but not through the DNS PK - could bypass the layer9 stuff to get the root signed LJL - more transparency from IANA/ICANN is needed JR - how to answer Swedish request JD - ask NCC to study TAR RL - changing DS records on the fly rather than go through root process DK - NCC would entertain a request for a specification for a TAR engage TF in reviewing the specification included a clear direction to co-operate with IANA JR what about publication method? DK best if it's not DNS easily parseable format XML? tools to churn out config files avoid parallels with alternate roots MS deadlines? JR put this into the specifications DK winding down must be defined from the outset MS - what is the time-frame? DK can't speak to this until the WG request this JR - TF to recommend time scales Spec end Jan TF to review by end Feb public comment on WG implementation by RIPE 56 LJL - push responsibilities for keys to children From jim at rfc1035.com Wed Oct 24 10:33:10 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 24 Oct 2007 09:33:10 +0100 Subject: [dnssec-key-tf] slides for the WG this afternoon Message-ID: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> Gents, here are the slides I proposed to use for the Task Force report to the WG this afternoon. Apologies for not doing this sooner. I ran out of time yesterday. Sigh. Please let me know if the presentation has any errors or omissions. -------------- next part -------------- A non-text attachment was scrubbed... Name: Reid-TARTF-RIPE55.pdf Type: application/pdf Size: 369311 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/dnssec-key-tf/attachments/20071024/29a684bb/attachment.pdf From sanz at denic.de Wed Oct 24 11:21:14 2007 From: sanz at denic.de (Marcos Sanz/Denic) Date: Wed, 24 Oct 2007 11:21:14 +0200 Subject: [dnssec-key-tf] slides for the WG this afternoon In-Reply-To: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> Message-ID: > Please let me know if the > presentation has any errors or omissions. No comments from this side of the room. Thanks for putting this together. Marcos From daniel.karrenberg at ripe.net Wed Oct 24 11:26:31 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 24 Oct 2007 11:26:31 +0200 Subject: [dnssec-key-tf] slides for the WG this afternoon In-Reply-To: References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> Message-ID: <20071024092631.GU1551@reiftel.local> On 24.10 11:21, Marcos Sanz/Denic wrote: > > Please let me know if the > > presentation has any errors or omissions. > > No comments from this side of the room. Thanks for putting this together. me too From Joao_Damas at isc.org Wed Oct 24 11:54:39 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 24 Oct 2007 11:54:39 +0200 Subject: [dnssec-key-tf] slides for the WG this afternoon In-Reply-To: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> Message-ID: <387FAE24-056E-48C3-BD74-63CA95CC243A@isc.org> sounds good On 24 Oct 2007, at 10:33, Jim Reid wrote: > From pk at DENIC.DE Wed Oct 24 11:54:11 2007 From: pk at DENIC.DE (Peter Koch) Date: Wed, 24 Oct 2007 11:54:11 +0200 Subject: [dnssec-key-tf] slides for the WG this afternoon In-Reply-To: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> Message-ID: <20071024095411.GA7171@denics7.denic.de> Jim, > I ran out of time yesterday. Sigh. Please let me know if the > presentation has any errors or omissions. thanks for circulating this. Two remarks regarding slide 4 "What next": 1) "TAR should somehow reflect DNS hierarchy" Maybe I misread this, but I recall we were in agreement that the TAR should be inherently flat, i.e., TLD only (esp. given that ARPA will probably be signed soon) 2) "Need open publication format (XML-ish?) ..." Rather than mentioning the ultimate obvious format, perhaps you could loosely refer to IETF work going on in that area, which the TAR should take into consideration. I trust that the "layer 9" issues with the TAR at IANA bypassing the "signed root"@IANA will be made clear verbally. -Peter From jim at rfc1035.com Wed Oct 24 12:26:57 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 24 Oct 2007 11:26:57 +0100 Subject: [dnssec-key-tf] slides for the WG this afternoon In-Reply-To: <20071024095411.GA7171@denics7.denic.de> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> Message-ID: <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> On Oct 24, 2007, at 10:54, Peter Koch wrote: > 1) "TAR should somehow reflect DNS hierarchy" > Maybe I misread this, but I recall we were in agreement that the > TAR > should be inherently flat, i.e., TLD only (esp. given that ARPA > will > probably be signed soon) We were in agreement about that, but the bullet point was about something else: namely that a TAR shouldn't diverge from the model we have for managing the DNS or give rise to an alternate trust hierarchy. Daniel had a good phrase for this which escapes me right now: perhaps someone could jog my memory? > 2) "Need open publication format (XML-ish?) ..." > Rather than mentioning the ultimate obvious format, perhaps you > could > loosely refer to IETF work going on in that area, which the TAR > should > take into consideration. OK. > I trust that the "layer 9" issues with the TAR at IANA bypassing the > "signed > root"@IANA will be made clear verbally. Yes. From daniel.karrenberg at ripe.net Wed Oct 24 12:43:33 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 24 Oct 2007 12:43:33 +0200 Subject: [dnssec-key-tf] slides for the WG this afternoon In-Reply-To: <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> Message-ID: <20071024104333.GY1551@reiftel.local> On 24.10 11:26, Jim Reid wrote: > On Oct 24, 2007, at 10:54, Peter Koch wrote: > > >1) "TAR should somehow reflect DNS hierarchy" > > Maybe I misread this, but I recall we were in agreement that the > >TAR > > should be inherently flat, i.e., TLD only (esp. given that ARPA > >will > > probably be signed soon) > > We were in agreement about that, but the bullet point was about > something else: namely that a TAR shouldn't diverge from the model we > have for managing the DNS or give rise to an alternate trust hierarchy. > > Daniel had a good phrase for this which escapes me right now: perhaps > someone could jog my memory? I do not now which point you want my alnguage on. 1) Not building DNSSEC trust hierarchies that diverge from the DNS delegation hierarchy. 2) TLDs and equivalent infrastructure domains like in-addr.arpa and e-164.arpa. (and that point may be moot sson) Does that help. > > >2) "Need open publication format (XML-ish?) ..." > > Rather than mentioning the ultimate obvious format, perhaps you > >could > > loosely refer to IETF work going on in that area, which the TAR > >should > > take into consideration. > > OK. i'll try to find it before the session starts > > >I trust that the "layer 9" issues with the TAR at IANA bypassing the > >"signed > >root"@IANA will be made clear verbally. > > Yes. From jim at rfc1035.com Wed Oct 24 14:07:46 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 24 Oct 2007 13:07:46 +0100 Subject: [dnssec-key-tf] slides for the WG this afternoon In-Reply-To: <20071024104333.GY1551@reiftel.local> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> <20071024104333.GY1551@reiftel.local> Message-ID: On Oct 24, 2007, at 11:43, Daniel Karrenberg wrote: > 1) Not building DNSSEC trust hierarchies that diverge from the DNS > delegation hierarchy. That was it! Thanks Daniel. From johani at autonomica.se Wed Oct 24 15:32:14 2007 From: johani at autonomica.se (Johan Ihren) Date: Wed, 24 Oct 2007 15:32:14 +0200 Subject: [dnssec-key-tf] slides for the WG this afternoon In-Reply-To: <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> Message-ID: <5E28166E-6C55-4213-8549-8C2AB4586479@autonomica.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> 1) "TAR should somehow reflect DNS hierarchy" >> Maybe I misread this, but I recall we were in agreement that >> the TAR >> should be inherently flat, i.e., TLD only (esp. given that ARPA >> will >> probably be signed soon) > > We were in agreement about that, but the bullet point was about > something else: namely that a TAR shouldn't diverge from the model > we have for managing the DNS or give rise to an alternate trust > hierarchy. So, being a latecomer to this, I have to question this decision. To me (being one of the people who were in favour of this when we discussed it in Tallinn) the whole point with this is to provide a useful service to reduce resolver side costs of acquiring multiple trusted keys for an increasing number of secure islands. Nowhere do I see a 1-1 mapping between such secure islands and TLDs. However, I do see that a plethora of third party key authentication services like this one will again raise the resolver side cost (which is what we want to avoid). I.e. if I go to RIPE NCC for TLD keys and to COMKEYS.FOO for keys for children of .COM and to a third place for other bits and pieces then we're getting back into doesn't-work-in-practice space. And the whole point of this exercise is to get OUT of that corner, not take a trip around the block and then return to it again. > Daniel had a good phrase for this which escapes me right now: > perhaps someone could jog my memory? > >> 2) "Need open publication format (XML-ish?) ..." >> Rather than mentioning the ultimate obvious format, perhaps you >> could >> loosely refer to IETF work going on in that area, which the TAR >> should >> take into consideration. Perhaps I'm missing something obvious here, but isn't the authentiction method much more important than the exact publication format? I.e. from my POV an arbitrary ASCII blob would work just fine as long as it is covered by a signature I choose to trust. Regards, Johan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRx9JYPotlDfa2H4ZAQIutwP/Ygqv22l9lttfKod98mjQKXYyi/IDfrPa xH7kyv7c9poOUtC/ke78FoOoJpyUJre4FzMqNuBvgjFhYP/A+PiAEGuUCr7YeSxK MmVECMEY4a4wv+xn0eT82BGQFYdzeDE/3RbbEuh2SQ234tOhl9uTF8vlkCrTdTud pL2MkaTlaGw= =UQI8 -----END PGP SIGNATURE----- From jim at rfc1035.com Wed Oct 24 16:30:36 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 24 Oct 2007 15:30:36 +0100 Subject: [dnssec-key-tf] Using the TAR for non-TLD KSKs In-Reply-To: <5E28166E-6C55-4213-8549-8C2AB4586479@autonomica.se> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> <5E28166E-6C55-4213-8549-8C2AB4586479@autonomica.se> Message-ID: On Oct 24, 2007, at 14:32, Johan Ihren wrote: > However, I do see that a plethora of third party key authentication > services like this one will again raise the resolver side cost > (which is what we want to avoid). I agree. But surely a TAR that goes into keys other than TLDs will just create this problem in a slightly different guise? This could also have an unpleasant operational impact on the TAR: perhaps looking after many hundreds of (frequently changing?) KSKs rather than a much smaller number of (probably fairly stable) TLD KSKs. From pk at DENIC.DE Wed Oct 24 16:45:39 2007 From: pk at DENIC.DE (Peter Koch) Date: Wed, 24 Oct 2007 16:45:39 +0200 Subject: [dnssec-key-tf] Using the TAR for non-TLD KSKs In-Reply-To: References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> <5E28166E-6C55-4213-8549-8C2AB4586479@autonomica.se> Message-ID: <20071024144539.GA29153@denics7.denic.de> On Wed, Oct 24, 2007 at 03:30:36PM +0100, Jim Reid wrote: > I agree. But surely a TAR that goes into keys other than TLDs will > just create this problem in a slightly different guise? This could > also have an unpleasant operational impact on the TAR: perhaps > looking after many hundreds of (frequently changing?) KSKs rather > than a much smaller number of (probably fairly stable) TLD KSKs. it makes the TAR operationally more complex and it would also be in conflict with our proposed stop condition. With only TLDs it is straightforward to exit once the root is signed. With other domains in the TAR, this strategy doesn't appear as straightforward to me anymore. -Peter From johani at autonomica.se Wed Oct 24 17:54:22 2007 From: johani at autonomica.se (Johan Ihren) Date: Wed, 24 Oct 2007 17:54:22 +0200 Subject: [dnssec-key-tf] Using the TAR for non-TLD KSKs In-Reply-To: <20071024144539.GA29153@denics7.denic.de> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> <5E28166E-6C55-4213-8549-8C2AB4586479@autonomica.se> <20071024144539.GA29153@denics7.denic.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24 Oct 2007, at 16:45, Peter Koch wrote: > On Wed, Oct 24, 2007 at 03:30:36PM +0100, Jim Reid wrote: > >> I agree. But surely a TAR that goes into keys other than TLDs will >> just create this problem in a slightly different guise? This could >> also have an unpleasant operational impact on the TAR: perhaps >> looking after many hundreds of (frequently changing?) KSKs rather >> than a much smaller number of (probably fairly stable) TLD KSKs. Ahh. And here I thought that the whole point of TAR was to avoid having every validator do the cumbersome fetching and verification of trusted keys and instead do this in one place to change from O(n*m) to O(n). But if this is too much effort for TAR then I think the world would be better served by some entity that could provide that service. On another note, at the heart of this lies a need to make DNSSEC operationally viable on the resolver side as the number of signed zones go up. The primary alternative to TAR is called DLV. DLV will happily take care of all keys wherever they are in the hierarchy. Therefore, if TAR doesn't provide a service that does the same then people will need to use DLV regardless. But if they need DLV regardless, what's the point of TAR? You all know that I'm strongly opposed to DLV, but even so: if TAR doesn't provide an alternative that can be compared to DLV on pros and cons directly then I really don't see a useful niche for TAR in this ecology. > it makes the TAR operationally more complex and it would also be in > conflict > with our proposed stop condition. With only TLDs it is > straightforward > to exit once the root is signed. With other domains in the TAR, this > strategy doesn't appear as straightforward to me anymore. That one I understand completely. However, what is more important: providing a relevant service that justifies this effort in the first place or having a sufficiently simple exit strategy? Johan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRx9qsPotlDfa2H4ZAQJwcAQAmnmvLaPolcHUJgNsJYin/kn2uJNnS1zc u8G9HhMJzHOifgEd1LWAtaouC2OeY5ntRppWUFi2lAxcyLfc6oub3PrI1WsjBP/g Qdwl3sF0z3DrTTtkXCpg6BthMt8uZBAWUSSjE946VKdr7d3hrVpVy/6cDBtelAaj lJtyPDjynYo= =XHz9 -----END PGP SIGNATURE----- From jim at rfc1035.com Wed Oct 24 23:48:08 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 24 Oct 2007 22:48:08 +0100 Subject: [dnssec-key-tf] Using the TAR for non-TLD KSKs In-Reply-To: References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> <5E28166E-6C55-4213-8549-8C2AB4586479@autonomica.se> <20071024144539.GA29153@denics7.denic.de> Message-ID: <0E2531F9-F9F5-4B44-BDF9-89E52B00C5FC@rfc1035.com> On Oct 24, 2007, at 16:54, Johan Ihren wrote: > However, what is more important: providing a relevant service that > justifies this effort in the first place or having a sufficiently > simple exit strategy? This is not an either/or question. IMO the service cannot be relevant unless it has a simple and clear exit strategy. From johani at autonomica.se Thu Oct 25 11:05:40 2007 From: johani at autonomica.se (Johan Ihren) Date: Thu, 25 Oct 2007 11:05:40 +0200 Subject: [dnssec-key-tf] Using the TAR for non-TLD KSKs In-Reply-To: <0E2531F9-F9F5-4B44-BDF9-89E52B00C5FC@rfc1035.com> References: <7239B1E0-6A43-4F4D-9A1F-E6D27B6004C7@rfc1035.com> <20071024095411.GA7171@denics7.denic.de> <8B2334C8-BE5E-40E5-B0B3-C8446E7E8D4D@rfc1035.com> <5E28166E-6C55-4213-8549-8C2AB4586479@autonomica.se> <20071024144539.GA29153@denics7.denic.de> <0E2531F9-F9F5-4B44-BDF9-89E52B00C5FC@rfc1035.com> Message-ID: <16406545-A522-4BF9-BA9F-1B32873DE961@autonomica.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24 Oct 2007, at 23:48, Jim Reid wrote: > On Oct 24, 2007, at 16:54, Johan Ihren wrote: > >> However, what is more important: providing a relevant service that >> justifies this effort in the first place or having a sufficiently >> simple exit strategy? > > This is not an either/or question. IMO the service cannot be > relevant unless it has a simple and clear exit strategy. Fair enough. So then we need to figure out an exit strategy that is sufficiently clear and still deals with non-TLD keys. How about "TAR will shutdown 12 months after the root is signed"? I'm not saying that's a perfect strategy, but it would address the present of tieing TAR to TLDs when there's no underlying reason for that other than the exit strategy. Johan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRyBcZ/otlDfa2H4ZAQI9cAQAnV5aV1PteviTG8OPKmYblggEhpl2sYDk 4vd2O6ItvYNYOOF1Cu9V8AtqSUJPVo7zNwZhZ1PT8n3RvM7jtSAgYjO92DyBGYBF TruDx4r0wjw01b0QZAGP0+r0aJ+rXyymFftSPp5FkIpl7tS1227iJJ0n9XT9SPbM U7PZbEr+SLA= =3+Ul -----END PGP SIGNATURE-----