From Joao_Damas at isc.org Sat Sep 1 01:08:46 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Fri, 31 Aug 2007 16:08:46 -0700 Subject: [dnssec-key-tf] let's get things started In-Reply-To: <20070829180024.GQ16250@unknown.office.denic.de> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> Message-ID: <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> On 29 Aug 2007, at 11:00, Peter Koch wrote: > > 1) Do we agree that "TLD only" best matches the outcome of the > discussion > in Tallinn? > That's the feeling I got. > 2) Is there anything "TLD like" we should consider? > Assuming we are including arpa as a rightful TLD, I think that covers it. Going into second level Domains, third, etc requires something dynamic, which name servers should be able to update by itself (or with the aid of cron-like jobs, but that is even more error prone) and then you end up at some DLV-like scheme. > For the publication part, my understanding is that, although the > term "DLV" > was mentioned, the presenter's primary goal was to have an accessible > Trust Anchor Repository. Correct. Something simple and trusted was my understanding and my desire for this. A simple DNS zone that can be pulled would do the trick (with additional local processing). Failing that, a well formatted text file available through any of http, ftp, rsync, rss syndication on a well known URI could cover this, I believe. The important part of this exercise is to get some trust on the data that is put into the repository, so I would prefer there to be explicit agreement between the repository maintainers and the TLDs whose keys are stored, so there is a chance for advance warning of changes in publication methods, emergency rollover processes, etc. In order to achieve this in a reasonable amount of time one would probably need to craft very simple agreements that wouldn't require lots of review by legal teams, so for instance, no party should try to impose liablility on the other. That also means there must be simple and clear "terms of usage" for the repository, towards its users. Joao From jim at rfc1035.com Mon Sep 3 11:35:50 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Sep 2007 10:35:50 +0100 Subject: [dnssec-key-tf] let's get things started In-Reply-To: <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> Message-ID: <6B4C588C-A457-4E6F-AC7F-BB02189C3BE9@rfc1035.com> On Sep 1, 2007, at 00:08, Joao Damas wrote: > On 29 Aug 2007, at 11:00, Peter Koch wrote: > >> 1) Do we agree that "TLD only" best matches the outcome of the >> discussion >> in Tallinn? > > That's the feeling I got. Same here. Though I worry about the potential to extend any repository for other "important" domains and the implications of that. Especially an exit strategy. >> 2) Is there anything "TLD like" we should consider? > > Assuming we are including arpa as a rightful TLD, I think that > covers it. Maybe, maybe not. Suppose there's some sort of layer-9 problem that prevents IANA/IAB from producing a key for .arpa. Should the repository turn away the ITU if they come along with a key for e164.arpa? Or the NRO (say) with keys for in-addr.arpa and ip6.arpa? From jim at rfc1035.com Mon Sep 3 11:46:48 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Sep 2007 10:46:48 +0100 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> Message-ID: <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> On Sep 1, 2007, at 00:08, Joao Damas wrote: > Correct. Something simple and trusted was my understanding and my > desire for this. > A simple DNS zone that can be pulled would do the trick (with > additional local processing). Failing that, a well formatted text > file available through any of http, ftp, rsync, rss syndication on > a well known URI could cover this, I believe. My preference would be for some sort of out of band means to distribute the keys, not the DNS. There could be other meta-data to distribute -- certificates for instance -- and access to the repository should require some sort of signed agreement IMO. These are hard to do if the keys are just dropped into the DNS somewhere. > The important part of this exercise is to get some trust on the > data that is put into the repository, so I would prefer there to be > explicit agreement between the repository maintainers and the TLDs > whose keys are stored, so there is a chance for advance warning of > changes in publication methods, emergency rollover processes, etc. IMO such an agreement is critical. It should also include the usual sorts of hold harmless provisions: this is a place for consenting adults, no promises or guarantees, etc, etc. > In order to achieve this in a reasonable amount of time one would > probably need to craft very simple agreements that wouldn't require > lots of review by legal teams, so for instance, no party should try > to impose liablility on the other. That also means there must be > simple and clear "terms of usage" for the repository, towards its > users. There should also be a provision for renewing these agreements, say on an annual basis, and a notice period so any party can walk away. Whoever provides the key repository needs to have a clear way of terminating the arrangement. Not just on technical or operational grounds but for something as simple as "we don't want to do this any more". From jim at rfc1035.com Mon Sep 3 16:31:04 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Sep 2007 15:31:04 +0100 Subject: [dnssec-key-tf] RIPE55 logistics Message-ID: <3A22BA02-6439-4121-9A7F-DBCB7E88E790@rfc1035.com> The NCC meeting folks are trying to make a room available for us in case we need a F2F discussion during RIPE55. My personal opinion is this Task Force should be able to do its work by email and physical meetings are not necessary. However it may be better for us to have a room available at RIPE55 and not need to use it than the other way round. The slot that's been offered is 09:00-10:30 on the Monday. If we need to meet, would this slot be acceptable or not? There are a number of other meetings taking place during RIPE55, so scheduling rooms and slots is not simple. So I suppose this means we "reserve" this slot unless there are other commitments for that time/date. [I am usually in bed at that time in the morning.] A clear decision from us would be a big help to the meeting organisers. I think a conference phone could be provided in the meeting room if some of us could only join by phone and we decide to use this slot. IMO if we do need a physical meeting, there are plenty of nice bars and restaurants within walking distance of the Krasnapolsky. :-) From daniel.karrenberg at ripe.net Fri Sep 7 12:10:54 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 7 Sep 2007 12:10:54 +0200 Subject: [dnssec-key-tf] agreements on the use of the repository Message-ID: <20070907101054.GP10273@guest-ws-85.ripe.net> My contribution: Strictly TLDs only. Anything else would open oo many holes. We do not want to buid a trust hierarchy parallel to the DNS. I will do my best with another hat on to see that .arpa is not going to be a problem; in fact I do not expect it to be. Publication format: As many as are required by the users. Pragmatic. At least one easily parseable format. Possibly tools to make popular textual formats out of hat one, e.g. config files for popular DNS software. Location: very preferably IANA itself. If that ccannot be achieved RIPE NCC requiring simple MoUs with each TLD concerned. Explicit intention by RIPE NCC to turn service over to IANA when IANA is ready to perform it. Exit strategy: Yearly review if service is still necessary. Definitely stop 6 months after root signed. Announce a definite stop year? Daniel From pk at DENIC.DE Fri Sep 7 14:33:34 2007 From: pk at DENIC.DE (Peter Koch) Date: Fri, 7 Sep 2007 14:33:34 +0200 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <20070907101054.GP10273@guest-ws-85.ripe.net> References: <20070907101054.GP10273@guest-ws-85.ripe.net> Message-ID: <20070907123334.GC28967@unknown.office.denic.de> On Fri, Sep 07, 2007 at 12:10:54PM +0200, Daniel Karrenberg wrote: > I will do my best with another hat on to see that .arpa is not going to > be a problem; in fact I do not expect it to be. Thanks, Daniel. The ARPA domain (and the beasts underneath) were the ones I had in mind. > Publication format: As many as are required by the users. Pragmatic. > At least one easily parseable format. Possibly tools to make popular > textual formats out of hat one, e.g. config files for popular DNS software. The I-D works on the human interface. Maybe we need to re-phrase "format" to "method": Do we expect the Trust Anchor Repository to be dynamically queried ("TLD only DLV") or only occasionally transferred/downloadded? > Location: very preferably IANA itself. If that ccannot be achieved RIPE > NCC requiring simple MoUs with each TLD concerned. Explicit intention > by RIPE NCC to turn service over to IANA when IANA is ready to perform it. Just a clarification question: is this with any hat? If we start with someone else but IANA, how would this entity authenticate the TLD contact? > Exit strategy: Yearly review if service is still necessary. Definitely > stop 6 months after root signed. Announce a definite stop year? In these n months, would the TLD TAs still be maintained or would the root TA be entered as soon as it is available and the publication stopped eventually? -Peter From jim at rfc1035.com Fri Sep 7 15:15:20 2007 From: jim at rfc1035.com (Jim Reid) Date: Fri, 7 Sep 2007 14:15:20 +0100 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <20070907123334.GC28967@unknown.office.denic.de> References: <20070907101054.GP10273@guest-ws-85.ripe.net> <20070907123334.GC28967@unknown.office.denic.de> Message-ID: <35162C50-567B-44FC-B303-2CE62F324DD2@rfc1035.com> On Sep 7, 2007, at 13:33, Peter Koch wrote: > If we start with someone else but IANA, how would this entity > authenticate > the TLD contact? Peter what makes you think IANA can authenticate the TLD contact? Very few ccTLDs have signed agreements with ICANN/IANA. And even when there is an agreement in place, the authentication is at best flimsy. I got .tel into the root with nothing more than a handful of plain text emails: no PGP signatures, no certificates, nada. One of those emails included a template that told IANA where they were to send their email about delegation matters. The whole process was much more lightweight than getting the NCC to redelegate some chunk of in- addr.arpa. I think this key repository needs to have some sort of self- authenticating bootstrap. ie IF you lodge some private key with the repository AND there's a corresponding public key for that in the TLD zone file THEN the repository trusts you. For some definition of trust. From pk at DENIC.DE Fri Sep 7 15:30:44 2007 From: pk at DENIC.DE (Peter Koch) Date: Fri, 7 Sep 2007 15:30:44 +0200 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <35162C50-567B-44FC-B303-2CE62F324DD2@rfc1035.com> References: <20070907101054.GP10273@guest-ws-85.ripe.net> <20070907123334.GC28967@unknown.office.denic.de> <35162C50-567B-44FC-B303-2CE62F324DD2@rfc1035.com> Message-ID: <20070907133044.GG28967@unknown.office.denic.de> On Fri, Sep 07, 2007 at 02:15:20PM +0100, Jim Reid wrote: > Peter what makes you think IANA can authenticate the TLD contact? please excuse my na?vety. > their email about delegation matters. The whole process was much more > lightweight than getting the NCC to redelegate some chunk of in- > addr.arpa. Yes, I know. But IMHO there should at least be consistency, i.e. the TAR should be fed by the same entity IANA believes to talk to when dealing with other TLD matters. > I think this key repository needs to have some sort of self- > authenticating bootstrap. ie IF you lodge some private key with the > repository AND there's a corresponding public key for that in the TLD > zone file THEN the repository trusts you. For some definition of trust. Right, that's the necessary condition. Our suggestion should include some high level description of a technical check for the TA. However, even if the TEL TLD were signed, _I_ should not be able to put the TEL KSK into the TAR. -Peter From jim at rfc1035.com Tue Sep 11 13:00:08 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 11 Sep 2007 12:00:08 +0100 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! Message-ID: Gents, there has been a deafening silence about the prospect of us holding a physical meeting at RIPE 55. Do we want/need this? The meeting organisers are looking for a definite answer from us. This helps them with the logistics of booking rooms for all the groups who need meeting space at RIPE 55. So here's the deal. Unless there's a clear view from the TF by the end of this week, I will tell Nick on Friday evening that we won't need meeting space. From sanz at denic.de Tue Sep 11 13:46:52 2007 From: sanz at denic.de (Marcos Sanz/Denic) Date: Tue, 11 Sep 2007 13:46:52 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: Message-ID: dnssec-key-tf-admin at ripe.net schrieb am 11.09.2007 13:00:08: > Gents, there has been a deafening silence about the prospect of us > holding a physical meeting at RIPE 55. Do we want/need this? The > meeting organisers are looking for a definite answer from us. This > helps them with the logistics of booking rooms for all the groups who > need meeting space at RIPE 55. Provided the current conversation dynamics (and I know I haven't contributed to it that much so far), it wouldn't be bad to meet in person. It's always possible to cancel the reservation, if later on we realize it's become unnecessary, isn't it? Best Marcos From jim at rfc1035.com Tue Sep 11 14:31:25 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 11 Sep 2007 13:31:25 +0100 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: References: Message-ID: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> On Sep 11, 2007, at 12:46, Marcos Sanz/Denic wrote: > Provided the current conversation dynamics (and I know I haven't > contributed to it that much so far), it wouldn't be bad to meet in > person. > It's always possible to cancel the reservation, if later on we realize > it's become unnecessary, isn't it? Yes and no. First off Nick Hyrka wants to publish our TF meeting in the overall meeting plan. That would allow anyone to come along and "observe": a Fine Thing. However it would look bad if that TF meeting didn't take place or was cancelled: some conspiracy theorists might make noise about smoke-filled rooms and black helicopters. Next, if meeting space is in short supply, I would be a little uncomfortable if we reserve a room and deny some other worthy cause the opportunity of using it if the TF later decides not to meet. This is why I would like us to make a clear decision. And if we decide to meet at RIPE 55, what are we going to discuss? What would an agenda for that meeting look like? Given the low traffic on the list to date, I'm not sure if there is enough justification to meet in person. OTOH, perhaps a physical meeting is the thing that's needed to get this TF to make progress. I would like the TF to make a decision about that. Soon. :-) From pk at DENIC.DE Tue Sep 11 14:54:44 2007 From: pk at DENIC.DE (Peter Koch) Date: Tue, 11 Sep 2007 14:54:44 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> Message-ID: <20070911125444.GF1233@unknown.office.denic.de> On Tue, Sep 11, 2007 at 01:31:25PM +0100, Jim Reid wrote: > This is why I would like us to make a clear decision. And if we > decide to meet at RIPE 55, what are we going to discuss? What would > an agenda for that meeting look like? Given the low traffic on the we've had some discussion of various topics: o Confirm decision to deal with TLD TAs only o Separate TA collection and maintenance from publication o Agree on mission statement and communication: "why are we doing this?" o Discuss and decide on publication: static vs. dynamic (or both?) o Discuss TLD registry authentication, TA acquisition and rollover o Discuss exit strategy o Discuss requirements for and recommendation of TAR operator For at least some of those statements have been sent to the list. > list to date, I'm not sure if there is enough justification to meet > in person. OTOH, perhaps a physical meeting is the thing that's > needed to get this TF to make progress. I would like the TF to make a How else would we make any progress at all? Also, may I ask that averybody on this list, who hasn't spoken up yet (where I'd count that as an implicit statement of interest), whether they are still interested (and able) to participate in the Task Force? Regards, Peter From Joao_Damas at isc.org Tue Sep 11 15:21:03 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Tue, 11 Sep 2007 15:21:03 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <20070911125444.GF1233@unknown.office.denic.de> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <20070911125444.GF1233@unknown.office.denic.de> Message-ID: Peter said it clearly. I would want to meet. As it turns out, face to face always works better than email. Joao On 11 Sep 2007, at 14:54, Peter Koch wrote: > On Tue, Sep 11, 2007 at 01:31:25PM +0100, Jim Reid wrote: > >> This is why I would like us to make a clear decision. And if we >> decide to meet at RIPE 55, what are we going to discuss? What would >> an agenda for that meeting look like? Given the low traffic on the > > we've had some discussion of various topics: > > o Confirm decision to deal with TLD TAs only > o Separate TA collection and maintenance from publication > o Agree on mission statement and communication: "why are we doing > this?" > o Discuss and decide on publication: static vs. dynamic (or both?) > o Discuss TLD registry authentication, TA acquisition and rollover > o Discuss exit strategy > o Discuss requirements for and recommendation of TAR operator > > For at least some of those statements have been sent to the list. > >> list to date, I'm not sure if there is enough justification to meet >> in person. OTOH, perhaps a physical meeting is the thing that's >> needed to get this TF to make progress. I would like the TF to make a > > How else would we make any progress at all? Also, may I ask that > averybody > on this list, who hasn't spoken up yet (where I'd count that as an > implicit > statement of interest), whether they are still interested (and > able) to > participate in the Task Force? > > Regards, > Peter > From roy at dnss.ec Tue Sep 11 15:59:27 2007 From: roy at dnss.ec (Roy Arends) Date: Tue, 11 Sep 2007 15:59:27 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <20070911125444.GF1233@unknown.office.denic.de> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <20070911125444.GF1233@unknown.office.denic.de> Message-ID: <1F44CE92-9DCB-458D-B5E3-B74A32337D34@dnss.ec> On Sep 11, 2007, at 2:54 PM, Peter Koch wrote: > On Tue, Sep 11, 2007 at 01:31:25PM +0100, Jim Reid wrote: > >> This is why I would like us to make a clear decision. And if we >> decide to meet at RIPE 55, what are we going to discuss? What would >> an agenda for that meeting look like? Given the low traffic on the > > we've had some discussion of various topics: > > o Confirm decision to deal with TLD TAs only > o Separate TA collection and maintenance from publication > o Agree on mission statement and communication: "why are we doing > this?" > o Discuss and decide on publication: static vs. dynamic (or both?) > o Discuss TLD registry authentication, TA acquisition and rollover > o Discuss exit strategy > o Discuss requirements for and recommendation of TAR operator > > For at least some of those statements have been sent to the list. > >> list to date, I'm not sure if there is enough justification to meet >> in person. OTOH, perhaps a physical meeting is the thing that's >> needed to get this TF to make progress. I would like the TF to make a > > How else would we make any progress at all? Also, may I ask that > averybody > on this list, who hasn't spoken up yet (where I'd count that as an > implicit > statement of interest), whether they are still interested (and > able) to > participate in the Task Force? I haven't spoken up yet, though I'm interested. Holiday interrupt. My brief on the topics above: I do agree with the decision of TLD TA's only, with the exception of 2nd level arpa domains. Logically 2nd level arpa domains are special enough to be grouped under its own top level. There are not that many 2nd level arpa domains, and I don't see that increasing any time soon. I also see the separation between TA collection, maintenance and publication. But this is a separation in processing only, and need to be properly defined accordingly. On the point of static/dynamic, I don't see why we can't do both. I don't see DLV as a proper solution, though. Exit strategy: stop when the root is signed, given an overlap of a few months. Roy From roy at dnss.ec Tue Sep 11 16:02:00 2007 From: roy at dnss.ec (Roy Arends) Date: Tue, 11 Sep 2007 16:02:00 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> Message-ID: <2166D707-0B6B-4A97-86D7-8717C810A7DB@dnss.ec> On Sep 11, 2007, at 2:31 PM, Jim Reid wrote: > On Sep 11, 2007, at 12:46, Marcos Sanz/Denic wrote: > >> Provided the current conversation dynamics (and I know I haven't >> contributed to it that much so far), it wouldn't be bad to meet in >> person. >> It's always possible to cancel the reservation, if later on we >> realize >> it's become unnecessary, isn't it? > > Yes and no. First off Nick Hyrka wants to publish our TF meeting in > the overall meeting plan. That would allow anyone to come along and > "observe": a Fine Thing. However it would look bad if that TF > meeting didn't take place or was cancelled: some conspiracy > theorists might make noise about smoke-filled rooms and black > helicopters. Next, if meeting space is in short supply, I would be > a little uncomfortable if we reserve a room and deny some other > worthy cause the opportunity of using it if the TF later decides > not to meet. > > This is why I would like us to make a clear decision. And if we > decide to meet at RIPE 55, what are we going to discuss? What would > an agenda for that meeting look like? Given the low traffic on the > list to date, I'm not sure if there is enough justification to meet > in person. OTOH, perhaps a physical meeting is the thing that's > needed to get this TF to make progress. I would like the TF to make > a decision about that. Soon. :-) I do like to meet in person. Lets use Peter's aggregated list of topics, and extend it. Roy From daniel.karrenberg at ripe.net Wed Sep 12 14:01:22 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 12 Sep 2007 14:01:22 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <2166D707-0B6B-4A97-86D7-8717C810A7DB@dnss.ec> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <2166D707-0B6B-4A97-86D7-8717C810A7DB@dnss.ec> Message-ID: <20070912120122.GI372@reiftel.local> We should meet and discuss issues that have ben raised. But first we have to know whether IANA has concrete plans of doing this stuff themselves. If they do we could give input if they don;t the focus changes slightly. Daniel From Joao_Damas at isc.org Wed Sep 12 16:24:20 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 12 Sep 2007 16:24:20 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <20070912120122.GI372@reiftel.local> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <2166D707-0B6B-4A97-86D7-8717C810A7DB@dnss.ec> <20070912120122.GI372@reiftel.local> Message-ID: I would agree with your statement except for the words "but first" Let's get going. If IANA can use whatever work is produced, great. If IANA does not do its thing, then we will have progress on a separate way. DNSSEC has already suffered of too much sitting around for things to happen my 2 cents Joao On 12 Sep 2007, at 14:01, Daniel Karrenberg wrote: > > We should meet and discuss issues that have ben raised. > But first we have to know whether IANA has concrete plans > of doing this stuff themselves. If they do we could give input > if they don;t the focus changes slightly. > > Daniel > From weiler at watson.org Thu Sep 13 01:12:11 2007 From: weiler at watson.org (Sam Weiler) Date: Wed, 12 Sep 2007 19:12:11 -0400 (EDT) Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <20070911125444.GF1233@unknown.office.denic.de> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <20070911125444.GF1233@unknown.office.denic.de> Message-ID: <20070912191004.V6809@fledge.watson.org> Unfortunately, I doubt I'll be at this RIPE meeting (for want of funding). While a physical meeting might be useful for making progress, I probably won't be there. > Also, may I ask that averybody on this list, who hasn't spoken up > yet (where I'd count that as an implicit statement of interest), > whether they are still interested (and able) to participate in the > Task Force? I've been drafting some substantive notes, which I'll send shortly. -- Sam From weiler at watson.org Thu Sep 13 01:23:12 2007 From: weiler at watson.org (Sam Weiler) Date: Wed, 12 Sep 2007 19:23:12 -0400 (EDT) Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> Message-ID: <20070908123810.I15945@fledge.watson.org> Here are some of my thoughts, as bullet points in response to the discussons so far. TLD only or not: I favor TLDs and .arpa. Whether or not .apra and its children are signed in the wild, I think the TAR should aim to include those .arpa beasts. There's nothing wrong with redundancy -- it can even be useful. Publication format: I agree with Daniel: "As many as are required by the users." Multiple formats are good and I have no strong preferences re: dynamically queriable v. bulk only. (In particular, I'm not going to insist on DLV as a publication format.) Location: we should be talking about a service to be run by the NCC. Even if IANA does (or might someday) run such a service, redundancy is useful. Querying the repository: should NOT require any agreement. We don't want to create barriers to using it. -- Sam From daniel.karrenberg at ripe.net Wed Sep 12 17:56:36 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 12 Sep 2007 17:56:36 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <2166D707-0B6B-4A97-86D7-8717C810A7DB@dnss.ec> <20070912120122.GI372@reiftel.local> Message-ID: <20070912155636.GF376@reiftel.karrenberg.net> On 12.09 16:24, Joao Damas wrote: > I would agree with your statement except for the words "but first" > Let's get going. If IANA can use whatever work is produced, great. If > IANA does not do its thing, then we will have progress on a separate > way. > DNSSEC has already suffered of too much sitting around for things to > happen > > my 2 cents > Joao Agree. I intended to say "But first it would be good to know ...." ;-) Daniel From daniel.karrenberg at ripe.net Thu Sep 13 08:08:58 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 13 Sep 2007 08:08:58 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <20070912191004.V6809@fledge.watson.org> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <20070911125444.GF1233@unknown.office.denic.de> <20070912191004.V6809@fledge.watson.org> Message-ID: <20070913060858.GG376@reiftel.karrenberg.net> On 12.09 19:12, Sam Weiler wrote: > Unfortunately, I doubt I'll be at this RIPE meeting (for want of > funding). While a physical meeting might be useful for making > progress, I probably won't be there. We can arrange forremote participation by Marratech or phone. Daniel From dfk at ripe.net Thu Sep 13 09:23:32 2007 From: dfk at ripe.net (Daniel Karrenberg) Date: Thu, 13 Sep 2007 09:23:32 +0200 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <20070908123810.I15945@fledge.watson.org> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> Message-ID: <20070913072332.GO376@reiftel.karrenberg.net> Fully agree with all your points but this one: On 12.09 19:23, Sam Weiler wrote: > > Location: we should be talking about a service to be run by the NCC. > Even if IANA does (or might someday) run such a service, redundancy is > useful. We need to have good arguments for that, because at the last RIPE meeting there was considerable push-back and I thought that this push-back was due to many people thinking that IANA should do this if they cannot get the signing done. The thinking behind that was that IANA already has the agreements and relationships in place to do this, i.e. authenticate TLD admins. The RIPE NCC would have to build these relationships. Not that it is difficult but it is another duplication. Whether this can be sold as good redundancy is a qestion. From weiler at watson.org Thu Sep 13 09:41:35 2007 From: weiler at watson.org (Sam Weiler) Date: Thu, 13 Sep 2007 03:41:35 -0400 (EDT) Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <20070913072332.GO376@reiftel.karrenberg.net> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> Message-ID: <20070913032730.B35615@fledge.watson.org> On Thu, 13 Sep 2007, Daniel Karrenberg wrote: > Fully agree with all your points but this one: > > On 12.09 19:23, Sam Weiler wrote: >> >> Location: we should be talking about a service to be run by the NCC. >> Even if IANA does (or might someday) run such a service, redundancy is >> useful. > > We need to have good arguments for that, because at the last RIPE meeting > there was considerable push-back and I thought that this push-back > was due to many people thinking that IANA should do this if they > cannot get the signing done. The thinking behind that was that > IANA already has the agreements and relationships in place to do this, > i.e. authenticate TLD admins. The RIPE NCC would have to build these > relationships. Not that it is difficult but it is another duplication. > Whether this can be sold as good redundancy is a qestion. When I wrote that paragraph, I had been inspired by this text from you: > Location: very preferably IANA itself. If that ccannot be achieved > RIPE NCC requiring simple MoUs with each TLD concerned. Explicit > intention by RIPE NCC to turn service over to IANA when IANA is > ready to perform it. I think we would be well served to not fret too much about the distant future (e.g. "when IANA is ready") and instead focus on "what do we want today". I'm a fan of IANA running a TAR (trust anchor repository), and I'm happy to see RIPE ask IANA to do so. (I'm also trying to get the IETF to instruct IANA to run one via the dlv-iana draft.) But if that's our only path forward, we risk having IANA drop the ball, which doesn't serve the community. I think we're best served by, in parallel, asking IANA to run a TAR and setting one up at the NCC. Would it be most productive for this task force to focus on the NCC-run option for the moment? -- Sam From pk at DENIC.DE Thu Sep 13 10:11:16 2007 From: pk at DENIC.DE (Peter Koch) Date: Thu, 13 Sep 2007 10:11:16 +0200 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <20070913032730.B35615@fledge.watson.org> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> Message-ID: <20070913081116.GA2865@unknown.office.denic.de> On Thu, Sep 13, 2007 at 03:41:35AM -0400, Sam Weiler wrote: > I think we would be well served to not fret too much about the distant > future (e.g. "when IANA is ready") and instead focus on "what do we > want today". agreed. The "memorandum" said ``get the root signed'', not ``sign the root''. > Would it be most productive for this task force to focus on the > NCC-run option for the moment? The one additional task we have to adress then is the part where the TAR has to establish contact with those TLD registries willing to submit their key(s). Hopefully not too much waste of time. -Peter From weiler at watson.org Thu Sep 13 10:31:10 2007 From: weiler at watson.org (Sam Weiler) Date: Thu, 13 Sep 2007 04:31:10 -0400 (EDT) Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <20070913081116.GA2865@unknown.office.denic.de> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> <20070913081116.GA2865@unknown.office.denic.de> Message-ID: <20070913041829.U35615@fledge.watson.org> On Thu, 13 Sep 2007, Peter Koch wrote: > The one additional task we have to adress then is the part where the TAR > has to establish contact with those TLD registries willing to submit their > key(s). Hopefully not too much waste of time. That's the interesting bit. Happily "making sure we get the right key in the first place" is likely to be pretty easy: the TLDs are publishing keys on their webpages signed with some other cyptosystem (GPG), much like the NCC is doing for its reverse zone keys, and we have heuristics (recognizing each others' voices on the phone) to authenticate many of them. The trick comes in updating the keys (and making sure that we don't list any that we can't update). Here's a strawman proposal: Require, as a condition of being listed in the TAR, that each TLD (or in-addr.arpa entry): a) agree to notify the TAR operator (the NCC) of key changes via a signed message pushed from the TLD b) agree to periodically send signed, timestamped messages to the operator confirming the current key, and c) establish multiple out-of-band communication channels and authentication credentials in case a and/or b fail. [As an option, if the TLD is willing to commit to updating a signed webpage or equivalent, the TAR operator could poll periodically. In that case, we'd need to establish the polling interval, and the TLD would need to resign the webpage periodically (with a timestamp) to avoid infinite replay attacks.] From jim at rfc1035.com Thu Sep 13 11:48:24 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 13 Sep 2007 10:48:24 +0100 Subject: [dnssec-key-tf] DLV and trust anchor repositories In-Reply-To: <20070913032730.B35615@fledge.watson.org> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> Message-ID: <2880FDD2-85FF-4B35-A66B-06B756358030@rfc1035.com> On Sep 13, 2007, at 08:41, Sam Weiler wrote: > I'm a fan of IANA running a TAR (trust anchor repository), and I'm > happy to see RIPE ask IANA to do so. (I'm also trying to get the > IETF to instruct IANA to run one via the dlv-iana draft.) I think we have to be careful here. IMO there are two distinct questions and these should not be intermingled. One is the question of should there be a key repository and who should/could run it. [That's two questions actually.] The other question is what sorts of keys/trust anchors are involved. DLV is the current flavour-of-the- month proposal for trust anchors. But there may be others. I think we should clarify whether decisions on the trust anchor technology (DLV, whatever) should or shouldn't be independent of those about the repository. ie If there's to be a TAR, should it be TA-technology neutral? BTW, when the topic under discussion changes, can we *please* remember to change the Subject: header to match the new discussion thread? Zillions of messages threaded under "agreements on the use of the repository" are not particularly helpful. From jim at rfc1035.com Thu Sep 13 11:50:55 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 13 Sep 2007 10:50:55 +0100 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <20070913060858.GG376@reiftel.karrenberg.net> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <20070911125444.GF1233@unknown.office.denic.de> <20070912191004.V6809@fledge.watson.org> <20070913060858.GG376@reiftel.karrenberg.net> Message-ID: <7D10E067-C1F0-4FFF-BC03-4E67A589B794@rfc1035.com> On Sep 13, 2007, at 07:08, Daniel Karrenberg wrote: > We can arrange forremote participation by Marratech or phone. Thanks for this Daniel. This may not be helpful in Sam's case if he's in California and the physical meeting starts at 9 or 10am Amsterdam time. From pk at DENIC.DE Thu Sep 13 11:59:10 2007 From: pk at DENIC.DE (Peter Koch) Date: Thu, 13 Sep 2007 11:59:10 +0200 Subject: [dnssec-key-tf] initial TLD sign up In-Reply-To: <20070913041829.U35615@fledge.watson.org> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> <20070913081116.GA2865@unknown.office.denic.de> <20070913041829.U35615@fledge.watson.org> Message-ID: <20070913095910.GD2865@unknown.office.denic.de> On Thu, Sep 13, 2007 at 04:31:10AM -0400, Sam Weiler wrote: > That's the interesting bit. Happily "making sure we get the right key > in the first place" is likely to be pretty easy: the TLDs are > publishing keys on their webpages signed with some other cyptosystem [...] not contesting your strawman, the point I tried to make (and already made to Jim in an earlier note) is the initial sign up of a TLD: How does the TAR know they're talking to the right TLD representative. If there's no key, that's probably easy, but as of today five of 267 TLDs do publish one or more DNSKEY RRs (not counting *.ARPA, since I like to follow Daniel's advice). The TAR should be operated in "passive mode", i.e. waiting to be approached by a TLD registry (announcements and encouragement nonwithstanding) and the TAR operator has to find the right link. Once that's established, the list you (Sam) provided should work. -Peter From dfk at ripe.net Thu Sep 13 12:02:01 2007 From: dfk at ripe.net (Daniel Karrenberg) Date: Thu, 13 Sep 2007 12:02:01 +0200 Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <7D10E067-C1F0-4FFF-BC03-4E67A589B794@rfc1035.com> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <20070911125444.GF1233@unknown.office.denic.de> <20070912191004.V6809@fledge.watson.org> <20070913060858.GG376@reiftel.karrenberg.net> <7D10E067-C1F0-4FFF-BC03-4E67A589B794@rfc1035.com> Message-ID: <20070913100201.GB376@reiftel.karrenberg.net> On 13.09 10:50, Jim Reid wrote: > On Sep 13, 2007, at 07:08, Daniel Karrenberg wrote: > > >We can arrange forremote participation by Marratech or phone. > > Thanks for this Daniel. This may not be helpful in Sam's case if he's > in California and the physical meeting starts at 9 or 10am Amsterdam > time Then lets start after RIPE business and before bar time. If we can't do that Sam will have to make a decision. Daniel From weiler at watson.org Thu Sep 13 16:29:00 2007 From: weiler at watson.org (Sam Weiler) Date: Thu, 13 Sep 2007 10:29:00 -0400 (EDT) Subject: [dnssec-key-tf] physical meeting at RIPE 55- again! In-Reply-To: <20070913100201.GB376@reiftel.karrenberg.net> References: <0D69A3BB-4A2D-4138-8BB0-8EF0F51FB848@rfc1035.com> <20070911125444.GF1233@unknown.office.denic.de> <20070912191004.V6809@fledge.watson.org> <20070913060858.GG376@reiftel.karrenberg.net> <7D10E067-C1F0-4FFF-BC03-4E67A589B794@rfc1035.com> <20070913100201.GB376@reiftel.karrenberg.net> Message-ID: <20070913102709.C35615@fledge.watson.org> >> Thanks for this Daniel. This may not be helpful in Sam's case if he's >> in California and the physical meeting starts at 9 or 10am Amsterdam >> time > > Then lets start after RIPE business and before bar time. > If we can't do that Sam will have to make a decision. I was more worried about being on the east coast of the US -- staying up for a meeting that starts at 1am (California time) is more likely than 4am. But afternoon in AMS would certainly be better for me; thanks for suggesting that, Daniel. -- Sam From weiler at watson.org Fri Sep 14 01:07:09 2007 From: weiler at watson.org (Sam Weiler) Date: Thu, 13 Sep 2007 19:07:09 -0400 (EDT) Subject: [dnssec-key-tf] Publication method (was: DLV and trust anchor repositories) In-Reply-To: <2880FDD2-85FF-4B35-A66B-06B756358030@rfc1035.com> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> <2880FDD2-85FF-4B35-A66B-06B756358030@rfc1035.com> Message-ID: <20070913103016.A35615@fledge.watson.org> >> I'm a fan of IANA running a TAR (trust anchor repository), and I'm >> happy to see RIPE ask IANA to do so. (I'm also trying to get the IETF to >> instruct IANA to run one via the dlv-iana draft.) > > I think we have to be careful here. IMO there are two distinct questions and > these should not be intermingled. One is the question of should there be a > key repository and who should/could run it. [That's two questions actually.] > The other question is what sorts of keys/trust anchors are involved. DLV is > the current flavour-of-the-month proposal for trust anchors. But there may be > others. > > I think we should clarify whether decisions on the trust anchor technology > (DLV, whatever) should or shouldn't be independent of those about the > repository. ie If there's to be a TAR, should it be TA-technology neutral? As I wrote yesterday: "I agree with Daniel: 'As many as are required by the users.' Multiple formats are good and I have no strong preferences re: dynamically queriable v. bulk only. (In particular, I'm not going to insist on DLV as a publication format.)" For sundry reasons, the document in front of the IETF does specify a particular publication scheme. But I think it's best for this discussion about an NCC-run TAR to be technology-neutral, at least for now. > BTW, when the topic under discussion changes, can we *please* remember to > change the Subject: header to match the new discussion thread? Zillions of > messages threaded under "agreements on the use of the repository" are not > particularly helpful. Done. -- Sam From dfk at ripe.net Mon Sep 17 14:20:18 2007 From: dfk at ripe.net (Daniel Karrenberg) Date: Mon, 17 Sep 2007 14:20:18 +0200 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <20070913032730.B35615@fledge.watson.org> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> Message-ID: <20070917122018.GS355@reiftel.karrenberg.net> On 13.09 03:41, Sam Weiler wrote: > > I think we would be well served to not fret too much about the distant > future (e.g. "when IANA is ready") and instead focus on "what do we > want today". I am currently sitting 5 feet from David Conrad and had a short chat with him about this area. He ipointed me to a URL of an provisional demonstration service that to me looks very much like what we are discussing here. https://ns.iana.org/dnssec/status.html > ... > But if that's our only path forward, we risk having IANA drop the > ball, which doesn't serve the community. I think we're best served > by, in parallel, asking IANA to run a TAR and setting one up at the > NCC. So to me it looks like our discussion is being overtaken by events which are a Good Thing(TM). But maybe I am missing something that is somehow deficient in the service IANA provides. Note well: many things we build on today started as provisional demonstrations and some have not moved from this stage in 20 years ;-). > Would it be most productive for this task force to focus on the > NCC-run option for the moment? Only if what IANA is doing is deficient. We can of course have RIPE say something like "Should IANA discontinue the service before the root is signed we want the RIPE NCC to take it over asap.?" Of course we should provide input to the IANA on how to improve the service if we have significant input. Daniel From Joao_Damas at isc.org Mon Sep 17 14:47:17 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Mon, 17 Sep 2007 14:47:17 +0200 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <20070917122018.GS355@reiftel.karrenberg.net> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> <20070917122018.GS355@reiftel.karrenberg.net> Message-ID: <1A79B03C-0BBC-4ED0-BE28-A3D6B33CD72E@isc.org> I have Richard (Rick) Lamb, who setup that ns.iana.org service signed to talk at the EOF (having seen his presentation at IETF, and then reminded again by andrei) My question to him and IANA, apart from expressing the appreciation for the work done, is whether his bosses will allow this to continue to be available. Joao On 17 Sep 2007, at 14:20, Daniel Karrenberg wrote: > On 13.09 03:41, Sam Weiler wrote: >> >> I think we would be well served to not fret too much about the >> distant >> future (e.g. "when IANA is ready") and instead focus on "what do we >> want today". > > I am currently sitting 5 feet from David Conrad and had a short chat > with him about this area. He ipointed me to a URL of an provisional > demonstration service that to me looks very much like what we are > discussing here. > > https://ns.iana.org/dnssec/status.html > >> ... >> But if that's our only path forward, we risk having IANA drop the >> ball, which doesn't serve the community. I think we're best served >> by, in parallel, asking IANA to run a TAR and setting one up at the >> NCC. > > So to me it looks like our discussion is being overtaken by events > which are a Good Thing(TM). But maybe I am missing something > that is somehow deficient in the service IANA provides. > > Note well: many things we build on today started as provisional > demonstrations and some have not moved from this stage in 20 > years ;-). > >> Would it be most productive for this task force to focus on the >> NCC-run option for the moment? > > Only if what IANA is doing is deficient. We can of course have RIPE > say something like "Should IANA discontinue the service before the > root is signed > we want the RIPE NCC to take it over asap.?" > > Of course we should provide input to the IANA on how to improve the > service > if we have significant input. > > Daniel > From dfk at ripe.net Mon Sep 17 14:57:20 2007 From: dfk at ripe.net (Daniel Karrenberg) Date: Mon, 17 Sep 2007 14:57:20 +0200 Subject: [dnssec-key-tf] agreements on the use of the repository In-Reply-To: <1A79B03C-0BBC-4ED0-BE28-A3D6B33CD72E@isc.org> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> <20070917122018.GS355@reiftel.karrenberg.net> <1A79B03C-0BBC-4ED0-BE28-A3D6B33CD72E@isc.org> Message-ID: <20070917125720.GU355@reiftel.karrenberg.net> On 17.09 14:47, Joao Damas wrote: > I have Richard (Rick) Lamb, who setup that ns.iana.org service signed > to talk at the EOF (having seen his presentation at IETF, and then > reminded again by andrei) > My question to him and IANA, apart from expressing the appreciation > for the work done, is whether his bosses will allow this to continue > to be available. Good! Excellent content. I suggested to David Conrad that this presentation make the clearest possible statement about the service quality and viability in the medium term. He understood. He also told me that this service was approved at the highest level in ICANN. But some more candid public statements are needed. I also suggested to David, that he provide a preview of that presentation to Jim whenever Jim happens to wear his RIPE TF and WG chair hat. ;-) Further, in my judgement, a statement from RIPE like "Should IANA discontinue the service before the root is signed we want the RIPE NCC to take it over asap.?" would not be necessary bt sufficient for ICANN to keep a "provisional" service up. ICANN will intrinsically be inclined to retain services which it must consider "core" to its raison d'etre. (A "provisional" service probably is even more stable because it presents less of a target for ICANN's layer 10 processes. :-) Daniel From jim at rfc1035.com Mon Sep 17 15:07:51 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 17 Sep 2007 14:07:51 +0100 Subject: [dnssec-key-tf] IANA as the trust anchor repository? In-Reply-To: <20070917125720.GU355@reiftel.karrenberg.net> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> <20070917122018.GS355@reiftel.karrenberg.net> <1A79B03C-0BBC-4ED0-BE28-A3D6B33CD72E@isc.org> <20070917125720.GU355@reiftel.karrenberg.net> Message-ID: <82ECA14B-DC5B-46AE-BA3B-471E2E0359EB@rfc1035.com> On Sep 17, 2007, at 13:57, Daniel Karrenberg wrote: > A "provisional" service probably is even more stable because it > presents less of a target for ICANN's layer 10 processes. :-) IMO "provisional service" is too much of a target for the ICANN policy/process wonks. :-( Something that sounds more technical and experimental in nature would be safer: "testbed", "evaluation exercise", etc. From jim at rfc1035.com Mon Sep 17 15:58:48 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 17 Sep 2007 14:58:48 +0100 Subject: [dnssec-key-tf] Physical meeting at RIPE 55 Message-ID: <4B844C70-6664-480A-9136-E86536C48A55@rfc1035.com> The NCC meeting organisers have allocated a slot for us at 11:00 on the Monday morning. (Sorry about the time Sam!) It'll be in the Grand Ballroom at the Kras. Details will be on the NCC web site soon. Please let me know if there are any requests for remote access -- web cams, speaker phones, Marratech (which hates me), etc. I will forward these to the NCC meeting people and hope they will able to help. From david.conrad at icann.org Mon Sep 17 17:19:20 2007 From: david.conrad at icann.org (David Conrad) Date: Mon, 17 Sep 2007 17:19:20 +0200 Subject: [dnssec-key-tf] IANA as the trust anchor repository? In-Reply-To: <82ECA14B-DC5B-46AE-BA3B-471E2E0359EB@rfc1035.com> References: <96723B80-FE24-46DC-9F93-0F85CC62CB72@rfc1035.com> <20070829180024.GQ16250@unknown.office.denic.de> <985C89CC-840C-4B7D-BA75-D50463F7C53D@isc.org> <69E0F154-AE18-42D1-B37D-EA15A012A3DC@rfc1035.com> <20070908123810.I15945@fledge.watson.org> <20070913072332.GO376@reiftel.karrenberg.net> <20070913032730.B35615@fledge.watson.org> <20070917122018.GS355@reiftel.karrenberg.net> <1A79B03C-0BBC-4ED0-BE28-A3D6B33CD72E@isc.org> <20070917125720.GU355@reiftel.karrenberg.net> <82ECA14B-DC5B-46AE-BA3B-471E2E0359EB@rfc1035.com> Message-ID: Hi, On Sep 17, 2007, at 3:07 PM, Jim Reid wrote: > On Sep 17, 2007, at 13:57, Daniel Karrenberg wrote: >> A "provisional" service probably is even more stable because it >> presents less of a target for ICANN's layer 10 processes. :-) > > IMO "provisional service" is too much of a target for the ICANN > policy/process wonks. :-( Something that sounds more technical and > experimental in nature would be safer: "testbed", "evaluation > exercise", etc. Trust me, it isn't ICANN's processes that folk need worry about. It would likely be helpful if someone could define the level of service you anticipate for this demonstration testbed evaluative exercise... Regards, -drc From daniel.karrenberg at ripe.net Tue Sep 18 07:11:56 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 18 Sep 2007 07:11:56 +0200 Subject: [dnssec-key-tf] Physical meeting at RIPE 55 In-Reply-To: <4B844C70-6664-480A-9136-E86536C48A55@rfc1035.com> References: <4B844C70-6664-480A-9136-E86536C48A55@rfc1035.com> Message-ID: <20070918051156.GG355@reiftel.karrenberg.net> On 17.09 14:58, Jim Reid wrote: > The NCC meeting organisers have allocated a slot for us at 11:00 on > the Monday morning. (Sorry about the time Sam!) It'll be in the Grand > Ballroom at the Kras. > Details will be on the NCC web site soon. > > Please let me know if there are any requests for remote access -- web > cams, speaker phones, Marratech (which hates me), etc. I will forward > these to the NCC meeting people and hope they will able to help. If we want to make it easier for Mr. Weiler to participate, I am sure that I can arrange for use of our boardroom at the office at an evening hour. this has a confrencing setup that may even work by the time of the meeting. Decision is up to whoever is chair of this, i am just offering. Daniel From jim at rfc1035.com Tue Sep 18 10:49:29 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 18 Sep 2007 09:49:29 +0100 Subject: [dnssec-key-tf] Physical meeting at RIPE 55 In-Reply-To: <20070918051156.GG355@reiftel.karrenberg.net> References: <4B844C70-6664-480A-9136-E86536C48A55@rfc1035.com> <20070918051156.GG355@reiftel.karrenberg.net> Message-ID: <6D5D07ED-D4AF-4973-9EB0-9979C9FF8763@rfc1035.com> On Sep 18, 2007, at 06:11, Daniel Karrenberg wrote: > If we want to make it easier for Mr. Weiler to participate, I am > sure that > I can arrange for use of our boardroom at the office at an evening > hour. > this has a confrencing setup that may even work by the time of the > meeting. > Decision is up to whoever is chair of this, i am just offering. Thanks Daniel for this kind offer. I have asked the NCC meeting people about the state of communications in the Kras at the time that they have allocated for us and expect to get a response shortly. That will allow us to make a decision on where and when we meet. Personally speaking, I would prefer there to be fewer variables and options to consider because it reduces the amount of cat-herding. Which is already quite tricky with all the other things that go on around a RIPE meeting. From sanz at denic.de Mon Sep 24 14:59:01 2007 From: sanz at denic.de (Marcos Sanz/Denic) Date: Mon, 24 Sep 2007 14:59:01 +0200 Subject: [dnssec-key-tf] Publication method (was: DLV and trust anchor repositories) In-Reply-To: <20070913103016.A35615@fledge.watson.org> Message-ID: > As I wrote yesterday: "I agree with Daniel: 'As many as are required > by the users.' Multiple formats are good and I have no strong > preferences re: dynamically queriable v. bulk only. (In particular, > I'm not going to insist on DLV as a publication format.)" I don't think that a "dynamically queriable" publication method is a hard requirement, only an optimization. https://ns.iana.org/dnssec/status.html looks nice, but: a) it is difficult to parse b) it is not signed by my favourite CA (hey, that will probably be stuff for lots of discussion) Coming back to other aspects discussed so far: * The more transports and syntaxes the repository offers, the better. They all must be synchronized among themselves, though. * I defend a repository for "TLD-like only" because of the different requirements that deeper levels of the tree would impose. And because that was the initial scope of our work, IIRC. * I certainly prefer IANA doing the publication than any other instance. We don't want to have a tree with two roots, one for content and one for authentication. The "flimsy authentication" argument and the TEL-example is not valid for me here: there shouldn't be more security expectations for changing a trust anchor than for changing a TLD delegation. * Dropping the experiment when the root is signed is good enough. It would be convenient and professional to set an absolute deadline for the experiment, though. This will address the worries of a possible loss of pressure on getting the root signed if the experiment were to become very successful. * TAR in passive mode: absolutely. Best regards, Marcos From daniel.karrenberg at ripe.net Tue Sep 25 14:08:57 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 25 Sep 2007 14:08:57 +0200 Subject: [dnssec-key-tf] Publication method (was: DLV and trust anchor repositories) In-Reply-To: References: <20070913103016.A35615@fledge.watson.org> Message-ID: <20070925120857.GP3955@reiftel.karrenberg.net> On 24.09 14:59, Marcos Sanz/Denic wrote: > ... > https://ns.iana.org/dnssec/status.html looks nice, but: > a) it is difficult to parse Well, I considered it obvious that port 53 would also work on *ns*.iana.org. I just checked to be sure and yes it does. This provides the canonical format .... There are even DS RRs there: ARPA. 3600 IN DS 53018 5 1 535BB7466E21C7C21E0DC09957EF42AAA055C1DD ARPA. 3600 IN DS 53018 5 2 87B205F87E55D3E5CA82EA1514E3D846D0E2C1BFBBEFEE9B4D7EBE72 4F33C362 ARPA. 3600 IN DS 35407 5 1 63F5D9F091CC46DA26C1671400A4379A8603D9A8 ARPA. 3600 IN DS 35407 5 2 1202D3B051ED0F790C7FED717F445EE461568E41874F9B1B8421C8A0 29AFB79E BG. 3600 IN DS 61993 5 1 ABC9B1EB085C12AB3214BC5B08269C24B918B623 BR. 3600 IN DS 61207 5 1 637724A380ECE3426F5EBDCD6795AD4F729AB3E9 INT. 3600 IN DS 31688 5 1 430F0C47AD06260BB0674B5B17BF5E257B726EBE INT. 3600 IN DS 31688 5 2 9334B7765E6BEC8AC8FC56FE33F925CC56E3B9F25A97EDEB701571AD 7EB4DC52 INT. 3600 IN DS 53077 5 1 967B69846136CCBDFE40DA23701CD426D3F12641 INT. 3600 IN DS 53077 5 2 B2855882738BCFC4CA3942B552A628E0BE2049BDF91ECFD5B7C33AB5 2EEE5680 SE. 3600 IN DS 17686 5 1 9E5E81A0B71A9B6B251077F700AA730E18D712EF SE. 3600 IN DS 17686 5 2 B78C0E213B17285C7BCC78884D81A5F09145F800C564954F856140D1 689153B9 SE. 3600 IN DS 6166 5 1 CE2B007F6D000B064B4A82E8840C19D3D09B8F8E SE. 3600 IN DS 6166 5 2 CD9D147E24D866412216ADA5DBCB257DAE6CF0FFEF234415D6BD1114 D833F213 but I am sure the IANA would also transpose this into other formats if there was a serious demand. Daniel From daniel.karrenberg at ripe.net Thu Sep 27 14:17:09 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 27 Sep 2007 14:17:09 +0200 Subject: [dnssec-key-tf] Publication method (was: DLV and trust anchor repositories) In-Reply-To: <20070925120857.GP3955@reiftel.karrenberg.net> References: <20070913103016.A35615@fledge.watson.org> <20070925120857.GP3955@reiftel.karrenberg.net> Message-ID: <20070927121709.GC440@reiftel.karrenberg.net> On 25.09 14:08, Daniel Karrenberg wrote: > > Well, I considered it obvious that port 53 would also work > on *ns*.iana.org. I just checked to be sure and yes it does. > This provides the canonical format .... ... deafening silence ... are we considering our job done by the good folks at the IANA? One particular recommendation we could make is to ask the RIPE NCC to operate dedicated secondary servers for the signed root zone published by the IANA on ns.iana.org. Important seems to me that - these remain isolated from the rest of the DNS, - there be a defined level of service - there be an authenticated method of fetching the data and - there be an agreement with IANA about this. Another thing the RIPE NCC could do is to help IANA make their fetching of the data from TLD servers more spoof-proof by fetching it reglarly by the 60+ probes that DNSMON uses making an aggregate of the most often heared responses and lag any inconsistencies... Daniel From pk at DENIC.DE Thu Sep 27 18:01:26 2007 From: pk at DENIC.DE (Peter Koch) Date: Thu, 27 Sep 2007 18:01:26 +0200 Subject: [dnssec-key-tf] Publication method (was: DLV and trust anchor repositories) In-Reply-To: <20070927121709.GC440@reiftel.karrenberg.net> References: <20070913103016.A35615@fledge.watson.org> <20070925120857.GP3955@reiftel.karrenberg.net> <20070927121709.GC440@reiftel.karrenberg.net> Message-ID: <20070927160126.GB11304@unknown.office.denic.de> Hi Daniel, > ... deafening silence ... are we considering our job done by > the good folks at the IANA? now that you ask -- I, for one, don't. An alternative, err, additional, root zone with DNSSEC is not really the outcome I'd like to see. For reasons of clarity and uniqueness I think the TAR should be published in one standard way, e.g. list of DS RRs or maybe an S/Key or OPIE like mnemonics based list of DSes. Then, (pointers to) conversion tools will help making this list usable in various validators. -Peter From pk at DENIC.DE Thu Sep 27 18:21:08 2007 From: pk at DENIC.DE (Peter Koch) Date: Thu, 27 Sep 2007 18:21:08 +0200 Subject: [dnssec-key-tf] Publication method (was: DLV and trust anchor repositories) In-Reply-To: <20070927161456.GV1260@reiftel.karrenberg.net> References: <20070913103016.A35615@fledge.watson.org> <20070925120857.GP3955@reiftel.karrenberg.net> <20070927121709.GC440@reiftel.karrenberg.net> <20070927160126.GB11304@unknown.office.denic.de> <20070927161456.GV1260@reiftel.karrenberg.net> Message-ID: <20070927162108.GD11304@unknown.office.denic.de> On Thu, Sep 27, 2007 at 06:14:56PM +0200, Daniel Karrenberg wrote: > Are we entering the realm of the complications department? sure, since you like picking on german engineering ;-) My aversion against a signed root at a special place is layer9ish. If it smells like an alternative root and responds like ... -Peter From daniel.karrenberg at ripe.net Thu Sep 27 18:14:56 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 27 Sep 2007 18:14:56 +0200 Subject: [dnssec-key-tf] Publication method (was: DLV and trust anchor repositories) In-Reply-To: <20070927160126.GB11304@unknown.office.denic.de> References: <20070913103016.A35615@fledge.watson.org> <20070925120857.GP3955@reiftel.karrenberg.net> <20070927121709.GC440@reiftel.karrenberg.net> <20070927160126.GB11304@unknown.office.denic.de> Message-ID: <20070927161456.GV1260@reiftel.karrenberg.net> On 27.09 18:01, Peter Koch wrote: > Hi Daniel, > > > ... deafening silence ... are we considering our job done by > > the good folks at the IANA? > > now that you ask -- I, for one, don't. An alternative, err, additional, > root zone with DNSSEC is not really the outcome I'd like to see. > For reasons of clarity and uniqueness I think the TAR should be published > in one standard way, e.g. list of DS RRs or maybe an S/Key or OPIE like > mnemonics based list of DSes. Then, (pointers to) conversion tools will > help making this list usable in various validators. What exactly is the problem with conversion tools that go to ns.iana.org:53 (and a possible list of secondary places), get the zone, validate the sig and then spit out whatever format is necessary for their particular output format? Are we entering the realm of the complications department? Daniel From daniel.karrenberg at ripe.net Thu Sep 27 19:33:18 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 27 Sep 2007 19:33:18 +0200 Subject: [dnssec-key-tf] Publication method (was: DLV and trust anchor repositories) In-Reply-To: <20070927162108.GD11304@unknown.office.denic.de> References: <20070913103016.A35615@fledge.watson.org> <20070925120857.GP3955@reiftel.karrenberg.net> <20070927121709.GC440@reiftel.karrenberg.net> <20070927160126.GB11304@unknown.office.denic.de> <20070927161456.GV1260@reiftel.karrenberg.net> <20070927162108.GD11304@unknown.office.denic.de> Message-ID: <20070927173318.GY1260@reiftel.karrenberg.net> On 27.09 18:21, Peter Koch wrote: > On Thu, Sep 27, 2007 at 06:14:56PM +0200, Daniel Karrenberg wrote: > > > Are we entering the realm of the complications department? > > sure, since you like picking on german engineering ;-) Hey - I am a German engineer .... eh European .... eh Chief Scientist ...... well trained as a German angineer ..... ;-) > > My aversion against a signed root at a special place is layer9ish. > If it smells like an alternative root and responds like ... OK. I get that. Best discussed and resolved f2f. Daniel