From daniel.karrenberg at ripe.net Wed Apr 16 08:13:10 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 08:13:10 +0200 Subject: [thierry.moreau@connotech.com: Re: [dnssec-key-tf] Input for Requirements Requested] Message-ID: <20080416061310.GA342@reiftel.karrenberg.net> Without comment. -------------- next part -------------- An embedded message was scrubbed... From: Thierry Moreau Subject: Re: [dnssec-key-tf] Input for Requirements Requested Date: Fri, 29 Feb 2008 11:51:37 -0500 Size: 3425 Url: https://www.ripe.net/ripe/mail/archives/dnssec-key-tf/attachments/20080416/2e509f13/attachment.mht From daniel.karrenberg at ripe.net Wed Apr 16 08:25:37 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 08:25:37 +0200 Subject: [dnssec-key-tf] [barbara.roseman@icann.org: Re: TLD trust Anchor Repository] Message-ID: <20080416062537.GB351@reiftel.karrenberg.net> Hi, I got the attached from the IANA. Apologies for not sending it on earlier. Was a little too busy in the last few days. This is a plea for requirements. Now is the time to reduce the set of 11 points we came up with earlier to the ones relevant to a repository run by IANA and send it on. My feeling is that this is going ahead unless the ICANN board gets its wires crossed. I have done everything I can (pun unavoidable) to avoid the latter by informing (ex-)board members of the importance and appropriateness of this. Can we have a timely discussion about the requirements to send on by e-mail, or do I get to pick and chose and ask for ratification later ;-). If all goes well we may even declare success in Berlin and clse this TF. Daniel -------------- next part -------------- An embedded message was scrubbed... From: Barbara Roseman Subject: Re: TLD trust Anchor Repository Date: Fri, 11 Apr 2008 11:01:38 -0700 Size: 2389 Url: https://www.ripe.net/ripe/mail/archives/dnssec-key-tf/attachments/20080416/9c9c010b/attachment.mht From daniel.karrenberg at ripe.net Wed Apr 16 09:01:06 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 09:01:06 +0200 Subject: [dnssec-key-tf] [barbara.roseman@icann.org: Re: TLD trust Anchor Repository] In-Reply-To: <20080416062537.GB351@reiftel.karrenberg.net> References: <20080416062537.GB351@reiftel.karrenberg.net> Message-ID: <20080416070106.GD342@reiftel.karrenberg.net> Forgot: It may also help for each of us to send a short note to any ICANN board members we know to support this. Daniel From pk at DENIC.DE Wed Apr 16 09:28:45 2008 From: pk at DENIC.DE (Peter Koch) Date: Wed, 16 Apr 2008 09:28:45 +0200 Subject: [dnssec-key-tf] [barbara.roseman@icann.org: Re: TLD trust Anchor Repository] In-Reply-To: <20080416070106.GD342@reiftel.karrenberg.net> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> Message-ID: <20080416072845.GA8471@unknown.office.denic.de> On Wed, Apr 16, 2008 at 09:01:06AM +0200, Daniel Karrenberg wrote: > > Forgot: It may also help for each of us to send a short note to any ICANN > board members we know to support this. I'm not sure I want to support a "DS Key registry" unless I'm sure this is not DLV. Even then I might not be in a position for said letter. -Peter From Joao_Damas at isc.org Wed Apr 16 09:34:31 2008 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 16 Apr 2008 09:34:31 +0200 Subject: [dnssec-key-tf] [barbara.roseman@icann.org: Re: TLD trust Anchor Repository] In-Reply-To: <20080416072845.GA8471@unknown.office.denic.de> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> Message-ID: <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> Peter, from previous exchanges, what is being proposed that IANA do is the same thing that the RIPE plenary asked the RIPE NCC to do at the last RIPE meeting, the (big) differences being: - the IANA has well established relations with most TLDs - Daniel doesn't get the work, someone else does Joao On 16 Apr 2008, at 09:28, Peter Koch wrote: > On Wed, Apr 16, 2008 at 09:01:06AM +0200, Daniel Karrenberg wrote: >> >> Forgot: It may also help for each of us to send a short note to any >> ICANN >> board members we know to support this. > > I'm not sure I want to support a "DS Key registry" unless I'm sure > this > is not DLV. Even then I might not be in a position for said letter. > > -Peter From pk at DENIC.DE Wed Apr 16 10:01:41 2008 From: pk at DENIC.DE (Peter Koch) Date: Wed, 16 Apr 2008 10:01:41 +0200 Subject: [dnssec-key-tf] [barbara.roseman@icann.org: Re: TLD trust Anchor Repository] In-Reply-To: <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> Message-ID: <20080416080141.GC8471@unknown.office.denic.de> Joao, > RIPE meeting, the (big) differences being: > - the IANA has well established relations with most TLDs > - Daniel doesn't get the work, someone else does fully understood and that's what we've been discussing at length, no disagreement. Maybe I just read too much into Barbara's message. So, to answer Daniel's question, I think none of the 11 requirements is inappropriate in this case, but some might need refinement: > [5] Everybody should sign up to T&C's that hold everyone else harmless. That's the TAR maintainer and the key maintainer and? any potential user? > [7] The TAR must make it clear what they keying material is for and > its political significance: eg "we're not undermining IANA" (or > perhaps not) or "we make no claims about the appropriateness of the > stuff in our TAR" (national sovereignty & competition issues). Given that [11] would mean TAs get inserted only with the consent of the key maintainer, is "appropriateness" still the right term? More important here would be some statement saying that "signing the root" is still a goal (if it is) and that's why the requirements about exit strategies should be kept. > [8] The TAR should treat all parties equally. Provided they > demonstrate suitable levels of DNSSEC clue. Not sure what this was up to. -Peter From daniel.karrenberg at ripe.net Wed Apr 16 10:57:26 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 10:57:26 +0200 Subject: [dnssec-key-tf] [barbara.roseman@icann.org: Re: TLD trust Anchor Repository] Message-ID: <20080416085726.GE342@reiftel.karrenberg.net> The attachment appeared truncated in the msg I got back via the list. In case it wqs, here is the message again. I think it is clear that DLV is not proposed. Daniel ----- Forwarded message from Barbara Roseman ----- Date: Fri, 11 Apr 2008 11:01:38 -0700 From: Barbara Roseman To: Daniel Karrenberg Cc: David Conrad Subject: Re: TLD trust Anchor Repository Thread-Topic: TLD trust Anchor Repository Thread-Index: Acibu9je2HhSwUFDSMCKVQbp/EuVyQAQj2IJ Accept-Language: en-US acceptlanguage: en-US X-RIPE-Spam-Level: Daniel, IANA is going to get Board approval to implement this registry during the April Meeting (if there are no major issues). We're planning on establishing a DS Key registry for Top Level Domains only. This registry will accept DS registrations from TLD managers according to the same processes as are currently used for NS records, only the DoC will not have to approve the registrations prior to their entry in the registry. This registry will be available via https while it is active, and it will have an end-of-life setpoint of 90 days after the introduction of DS records into a signed authoritative root zone. The goal is to have this registry be established by the end of April. Let me know if you see difficulties in how we've defined the registry or the planned implementation. Thanks, -Barb On 4/11/08 3:06 AM, "Daniel Karrenberg" wrote: > > > Any time line? > > RIPE-56 is drawing near and the pressure for the RIPE NCC to start such a > service is mounting. ----- End forwarded message ----- From jim at rfc1035.com Wed Apr 16 11:07:19 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 16 Apr 2008 10:07:19 +0100 Subject: [dnssec-key-tf] clarification of TAR requirements In-Reply-To: <20080416080141.GC8471@unknown.office.denic.de> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> Message-ID: >> [5] Everybody should sign up to T&C's that hold everyone else >> harmless. > > That's the TAR maintainer and the key maintainer and? any potential > user? OK Peter. I see your Prussian tendencies have been re-asserted. :-) My idea behind [5] was that anyone directly using the TAR signs up to some T&Cs. ie The TAR says "we make no claims of any sort about this data" (maybe). Those submitting keys to the TAR say something similar and also promise timely updating of the TAR when a new key is introduced. And have responsive point of contacts. Anyone downloading stuff from the TAR agrees the TAR is making no claims about the validity of the data and they take full responsibility for everything they do with the stuff they download. End users would not be involved. Though they might have to agree to some sort of disclaimer in the contract with their TLD registry and/or service provider. > >> [7] The TAR must make it clear what they keying material is for and >> its political significance: eg "we're not undermining IANA" (or >> perhaps not) or "we make no claims about the appropriateness of >> the >> stuff in our TAR" (national sovereignty & competition issues). > > Given that [11] would mean TAs get inserted only with the consent of > the > key maintainer, is "appropriateness" still the right term? Yes. eg Not claiming or implying one TLD key or DNSSEC flavour or type of trust anchor is better or worse than another. Or that the hypothetical NCC's TAR was better or worse than one run by some other organisation. > More important > here would be some statement saying that "signing the root" is still a > goal (if it is) and that's why the requirements about exit strategies > should be kept. Let's avoid this rat-hole Peter. I think we're now working on the assumption that the IANA repository is going ahead. So this TF could support that effort with some ideas about that TAR's requirements. If we can get consensus on that, we can ask the WG to endorse that outcome, send it to ICANN and as Daniel says, declare victory and close the TF. >> [8] The TAR should treat all parties equally. Provided they >> demonstrate suitable levels of DNSSEC clue. > > Not sure what this was up to. The TAR would be for all ICANN-recognised TLDs, not just ccTLDs or those TLDs that happened to be in the NCC service region. Or were NCC members. At the same time however, a TLD that comes to the TAR looking for guidance on how to manage its keys or sign its zone should know they should look elsewhere for that assistance. From pk at DENIC.DE Wed Apr 16 11:31:59 2008 From: pk at DENIC.DE (Peter Koch) Date: Wed, 16 Apr 2008 11:31:59 +0200 Subject: [dnssec-key-tf] clarification of TAR requirements In-Reply-To: References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> Message-ID: <20080416093159.GG8471@unknown.office.denic.de> Hi Jim, > >>[5] Everybody should sign up to T&C's that hold everyone else > >>harmless. > My idea behind [5] was that anyone directly using the TAR signs up to > some T&Cs. ie The TAR says "we make no claims of any sort about this > data" (maybe). Those submitting keys to the TAR say something similar > and also promise timely updating of the TAR when a new key is > introduced. And have responsive point of contacts. Anyone downloading > stuff from the TAR agrees the TAR is making no claims about the > validity of the data and they take full responsibility for everything > they do with the stuff they download. now, if IANA is doing the job, is this still a requirement from our side (assuming this was to protect the NCC from any liability back then)? "Users" should actually have meant the parties downloading the TAR, not end users, so that's fine with me. > >>[7] The TAR must make it clear what they keying material is for and > >> its political significance: eg "we're not undermining IANA" (or > >> perhaps not) or "we make no claims about the appropriateness of > >>the > >> stuff in our TAR" (national sovereignty & competition issues). > > > >Given that [11] would mean TAs get inserted only with the consent of > >the > >key maintainer, is "appropriateness" still the right term? > > Yes. eg Not claiming or implying one TLD key or DNSSEC flavour or type > of trust anchor is better or worse than another. Or that the > hypothetical NCC's TAR was better or worse than one run by some other > organisation. So, setting layer 9+ aside for a second, this would mean there are no requirements for the crypto algorithms and key lengths used, nor any requirement to actually have a ZSK/KSK split or have a live KSK with the SEP flag set? > >here would be some statement saying that "signing the root" is still a > >goal (if it is) and that's why the requirements about exit strategies > >should be kept. > > Let's avoid this rat-hole Peter. I think we're now working on the > assumption that the IANA repository is going ahead. So this TF could > support that effort with some ideas about that TAR's requirements. If > we can get consensus on that, we can ask the WG to endorse that > outcome, send it to ICANN and as Daniel says, declare victory and > close the TF. I'm not sure where you see me rat-holing here. With a non-IANA TAR, having termination conditions and exit strategies was quite natural. With an IANA TAR this requirement may or may not be maintained. I've "voted" in favor, what's your opinion? > >>[8] The TAR should treat all parties equally. Provided they > >> demonstrate suitable levels of DNSSEC clue. > > >Not sure what this was up to. > > The TAR would be for all ICANN-recognised TLDs, not just ccTLDs or > those TLDs that happened to be in the NCC service region. Or were NCC > members. At the same time however, a TLD that comes to the TAR looking > for guidance on how to manage its keys or sign its zone should know > they should look elsewhere for that assistance. So, at the risk of being perceived as Prussian again, lets explain this a bit more (and avoid "recognized" etc.): [8] The TAR is open to receive TAs for any delegated TLD. [?] The TAR maintainers may assist TA/KSK maintainers on a best effort basis only. Inetersted parties are encouraged to consult (RFC 4641, ...) for technical and operational guidance. -Peter From daniel.karrenberg at ripe.net Wed Apr 16 11:34:22 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 11:34:22 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> Message-ID: <20080416093422.GE351@reiftel.karrenberg.net> Let m make a fresh start. Propsed mesage to IANA at bottom. Here is what we had: [1] The TAR should be technology neutral. It should not exclude or prevent different flavours of trust anchors to be published. [2] The TAR should be OS/DNS implementation neutral. Tools and documentation should be provided for the common platforms: "here's how to transform this tarball of crypto gunk into stuff to plug into your name server configuration". [3] The TAR should somehow verify the keying material it's given before publishing or storing it. There should also be a secure channel for authenticating the TAR and any data it's publishing. [4] A process is needed to revoke a trust anchor and notify those who may be using the now withdrawn or invalid trust anchor. [5] Everybody should sign up to T&C's that hold everyone else harmless. [6] The TAR should be clear what support, if any, is available. [7] The TAR must make it clear what they keying material is for and its political significance: eg "we're not undermining IANA" (or perhaps not) or "we make no claims about the appropriateness of the stuff in our TAR" (national sovereignty & competition issues). [8] The TAR should treat all parties equally. Provided they demonstrate suitable levels of DNSSEC clue. [9] There should be regular reviews of the TAR's usefulness: ie clear goals for defining "success" or "failure" and some way of establishing consensus around these goals. [10] The TAR must have exit and escrow strategies [11] The TAR should only publish keying material with the consent of the respective key manager. Discussion: [1] is being satisfied by the proposal. Just publishing RRs as defined in the standards which would otherwise go into the root zone is abut as neutral as one can get. [2] can be done, and we can help. IAnA could publish info or pointers to it. [3] IANA SOP should be good enough. [4] needs to be implemented. Can be opt-in maillist. [5] not sure if relevant in context. drop? [6] relevant [7] not relevant n contet, drop! [8] not clear what this really means, don't know about cluelevel qualiication, drop that? [9] dangerous in ICANN context, really needed? drop? [10] exit part of proposal, escrow not, could delay things, drop? [11] SOP I believe, anyway: relevant So I propose toend the following to IANA (with numbering of requiremetns fixed) : ------ Dear Barbara, thank you for your note about the proposed DS key registry for TLDs. The RIPE DNSSEC Trust Anchor Repository task force welcomes this development. We would like to see IANA providing such a registry as soon as possible. From our own work we have developed the following set of reuirements which may be useful for you when implementing the service: [1] The registry should be technology neutral. It should not exclude or prevent different flavours of trust anchors to be published. Comment: Publishing RRs as defined by the relevant standards meets this requirement. [2] The TAR should be OS/DNS implementation neutral. Tools and documentation should be provided for the common platforms: "here's how to transform this tarball of crypto gunk into stuff to plug into your name server configuration". Comment: IANA should publish such docmentation and tools, or pointers to them. Once we know details of repository, we can help putting together this documentation. [3] The TAR should somehow verify the keying material it's given before publishing or storing it. There should also be a secure channel for authenticating the TAR and any data it's publishing. Comment: We assume this is SOP for TLD requests and would be implemented here also. [4] A process is needed to revoke a trust anchor and notify those who may be using the now withdrawn or invalid trust anchor. Comment: An opt-in mailing list for operational news should be sufficient to satisfy this. [6] The TAR should be clear what support, if any, is available. [10] The TAR must have exit strategy. Comment: The proposal includes that. [10a] the TAR must store its data under escrow somewhere. Comment: Not necessary to start with, i.e. should not delay but needs to be developed [11] The TAR should only publish keying material with the consent of the respective key manager. Comment: we believe that is SOP and part of the proposa. Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make our supoort for this repository known to anyone in the ICANN govenance structure if it helps to push this along. Kind rregards RIPE DNSSEC trust Anchor Repository Task Forkce Jim Reid Chair -------- Can we have a discussion on what needs to be changed in the draft message? Daniel From jim at rfc1035.com Wed Apr 16 12:45:24 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 16 Apr 2008 11:45:24 +0100 Subject: [dnssec-key-tf] clarification of TAR requirements In-Reply-To: <20080416093159.GG8471@unknown.office.denic.de> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093159.GG8471@unknown.office.denic.de> Message-ID: <3FF6A374-92C7-4A65-8655-2C6B45313DC5@rfc1035.com> On 16 Apr 2008, at 10:31, Peter Koch wrote: > now, if IANA is doing the job, is this still a requirement from our > side > (assuming this was to protect the NCC from any liability back then)? I think it would be prudent for IANA/ICANN to have this type of protection and it wouldn't hurt for our TF to suggest that to them. Assuming they've not already considered this. > So, setting layer 9+ aside for a second, this would mean there are no > requirements for the crypto algorithms and key lengths used, nor any > requirement to actually have a ZSK/KSK split or have a live KSK with > the > SEP flag set? Yup. These requirements should be documented (and enforced?) somehow. But not by the TAR. Someone else can be the DNSSEC police. I think it's OK for the TAR to say "the key we have for this TLD doesn't appear to be a live KSK", but no more than that. It's probably not OK IMO for the TAR to refuse a valid key because it's not yet a live KSK. For some definition of valid. >>> here would be some statement saying that "signing the root" is >>> still a >>> goal (if it is) and that's why the requirements about exit >>> strategies >>> should be kept. >> >> Let's avoid this rat-hole Peter. I think we're now working on the >> assumption that the IANA repository is going ahead. So this TF could >> support that effort with some ideas about that TAR's requirements. If >> we can get consensus on that, we can ask the WG to endorse that >> outcome, send it to ICANN and as Daniel says, declare victory and >> close the TF. > > I'm not sure where you see me rat-holing here. Re-opening the discussions about signing the root. Or a debate on if an NCC effort to set up a TAR undermines or supports the IANA TAR. Since you're not doing that, let's move on.... I think Daniel's captured all the salient points, so can we please focus on the text he's drafted? > [8] The TAR is open to receive TAs for any delegated TLD. > [?] The TAR maintainers may assist TA/KSK maintainers on a best effort > basis only. Inetersted parties are encouraged to consult (RFC > 4641, ...) > for technical and operational guidance. Yes! From jim at rfc1035.com Wed Apr 16 13:10:58 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 16 Apr 2008 12:10:58 +0100 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416093422.GE351@reiftel.karrenberg.net> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> Message-ID: <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> On 16 Apr 2008, at 10:34, Daniel Karrenberg wrote: > Dear Barbara, > > thank you for your note about the proposed DS key registry for TLDs. > The RIPE DNSSEC Trust Anchor Repository task force welcomes this > development. We would like to see IANA providing such a registry as > soon as possible. From our own work we have developed the following > set of reuirements which may be useful for you when implementing > the service: > > > [1] The registry should be technology neutral. It should not exclude > or > prevent different flavours of trust anchors to be published. > > Comment: Publishing RRs as defined by the relevant standards meets > this requirement. Perhaps we combine these to get: The registry should be technology neutral. It should not exclude or prevent different flavours of trust anchors to be published provided those trust anchor technologies are documented by relevant standards. > [2] The TAR should be OS/DNS implementation neutral. Tools and > documentation should be provided for the common platforms: "here's how > to transform this tarball of crypto gunk into stuff to plug into your > name server configuration". > > Comment: IANA should publish such docmentation and tools, or > pointers to > them. Once we know details of repository, we can help putting together > this documentation. > > [3] The TAR should somehow verify the keying material it's given > before publishing or storing it. There should also be a secure channel > for authenticating the TAR and any data it's publishing. > > Comment: We assume this is SOP for TLD requests and would be > implemented > here also. I'd like to know this rather than assume it was SOP. At the moment Daniel, not all TLD requests involve something we'd recognise as a secure channel. Though I understand this is one of the many things Kim has in the pipeline. > [4] A process is needed to revoke a trust anchor and notify those who > may be using the now withdrawn or invalid trust anchor. > > Comment: An opt-in mailing list for operational news should be > sufficient > to satisfy this. > > [6] The TAR should be clear what support, if any, is available. > > [10] The TAR must have exit strategy. > > Comment: The proposal includes that. > > [10a] the TAR must store its data under escrow somewhere. > > Comment: Not necessary to start with, i.e. should not delay but > needs to be developed > > [11] The TAR should only publish keying material with the consent of > the respective key manager. > > Comment: we believe that is SOP and part of the proposa. Again, I'd like to know that rather than assume it. As for the rest of the draft Daniel, I like it. You've done a nice job here of weeding out the cruft and aligning things with how the IANA effort is progressing. Thanks. > RIPE DNSSEC trust Anchor Repository Task Forkce > Jim Reid > Chair Er, it's news to me that I chair the TF. :-) I didn't think we had one. However it says this on the web site, so it must be true. :-) My personal preference here would be for the TF to reach consensus and have that endorsed by the DNS WG. And then the WG sends something on behalf of the RIPE community to ICANN. We set up the TF because the WG was evenly divided, so I would be more comfortable if the WG supported the draft rather than the TF. From daniel.karrenberg at ripe.net Wed Apr 16 13:34:55 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 13:34:55 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> Message-ID: <20080416113455.GJ351@reiftel.karrenberg.net> On 16.04 12:10, Jim Reid wrote: > > . > >[3] The TAR should somehow verify the keying material it's given > >before publishing or storing it. There should also be a secure channel > >for authenticating the TAR and any data it's publishing. > > > >Comment: We assume this is SOP for TLD requests and would be > >implemented > >here also. > > I'd like to know this rather than assume it was SOP. At the moment > Daniel, not all TLD requests involve something we'd recognise as a > secure channel. Though I understand this is one of the many things Kim > has in the pipeline. I understand the intention and agree with it. Channels or TLD reuests need to be improved. However we have to be careful not to cause delays and friction by mixing things. Our comment should not be interpreted to require a special process. I'll think up tet saying this. > >[11] The TAR should only publish keying material with the consent of > > the respective key manager. > > > >Comment: we believe that is SOP and part of the proposa. > > Again, I'd like to know that rather than assume it. I'll leave out the comment. > Er, it's news to me that I chair the TF. :-) I didn't think we had > one. However it says this on the web site, so it must be true. :-) Of course it is! > My personal preference here would be for the TF to reach consensus and > have that endorsed by the DNS WG. And then the WG sends something on > behalf of the RIPE community to ICANN. We set up the TF because the WG > was evenly divided, so I would be more comfortable if the WG supported > the draft rather than the TF. Fine with me. Lets reach consensus here, send it to the DB WG, allow a *few* days for discussion and send it on. If we wait until Berlin it will be overtaken by events. New draft coming soon. Daniel From pk at DENIC.DE Wed Apr 16 13:41:51 2008 From: pk at DENIC.DE (Peter Koch) Date: Wed, 16 Apr 2008 13:41:51 +0200 Subject: [dnssec-key-tf] clarification of TAR requirements In-Reply-To: <3FF6A374-92C7-4A65-8655-2C6B45313DC5@rfc1035.com> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093159.GG8471@unknown.office.denic.de> <3FF6A374-92C7-4A65-8655-2C6B45313DC5@rfc1035.com> Message-ID: <20080416114151.GJ8471@unknown.office.denic.de> Jim, > But not by the TAR. Someone else can be the DNSSEC police. I think > it's OK for the TAR to say "the key we have for this TLD doesn't > appear to be a live KSK", but no more than that. It's probably not OK > IMO for the TAR to refuse a valid key because it's not yet a live KSK. > For some definition of valid. time to disagree again. While we might not reach consensus on "technical checks" of the KSK/TA here, I doubt we need this as an explicit non-requirement and could leave this to IANA's discretion. > Re-opening the discussions about signing the root. Or a debate on if > an NCC effort to set up a TAR undermines or supports the IANA TAR. > Since you're not doing that, let's move on.... I think Daniel's > captured all the salient points, so can we please focus on the text > he's drafted? I'm trying to, but "move on" in response to such discussion is, well, unilateral consensus. > >[8] The TAR is open to receive TAs for any delegated TLD. > >[?] The TAR maintainers may assist TA/KSK maintainers on a best effort > > basis only. Inetersted parties are encouraged to consult (RFC > >4641, ...) > > for technical and operational guidance. > > Yes! OK, but it seems the part in '[?]' was already covered by an earlier item. -Peter From daniel.karrenberg at ripe.net Wed Apr 16 13:51:32 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 13:51:32 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416113455.GJ351@reiftel.karrenberg.net> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> Message-ID: <20080416115132.GK351@reiftel.karrenberg.net> New text. I dropped the escrow bit, because further cogitation makes it seem a very bottomless pit to me in the IANA context. I hope y'all can agree. diff follows below: ------ Dear Barbara, thank you for your note about the proposed DS key registry for TLDs. The RIPE DNS working group (DNS WG) force welcomes this development. We would like to see IANA providing such a registry as soon as possible. As you know we have developed a set of requirements for such a repository. As these may be useful for you when implementing the service, we offer them here: [1] The registry should be technology neutral. It should not exclude or prevent different flavours of trust anchors to be published, provided provided those trust anchors conform to the relevant standards. [2] The TAR should be OS/DNS implementation neutral. Tools and documentation should be provided for the common platforms: "here's how to transform this crypto gunk into stuff to plug into your resolver/server configuration". Comment: IANA should publish such docmentation and tools, or pointers to them. Once we know details of repository, we can help putting together this documentation. [3] The TAR should verify that the keying material it receives comes from authorised source, verify it is correctly formatted and verify it is consisten with what is published in the TLD zone before publishing it. There should also be a secure channel for authenticating the TAR and any data it is publishing. Comment: Using the same channels IANA uses to receive update requests to the root zone from TLDs is fine. We do not mean special new channels. https delivery and possibly checksums are sufficient for publication. [4] A process is needed to revoke a trust anchor and notify those who may be using the now withdrawn or invalid trust anchor. Comment: An opt-in mailing list for operational news should be sufficient to satisfy this. [5] The TAR should be clear what support, if any, is available. [6] The TAR must have exit strategy. Comment: The proposal includes that. [7] The TAR should only publish keying material with the consent of the respective key manager. Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make our supoort for this repository known to anyone in the ICANN govenance structure if it helps to push this along. Kind Regards RIPE DNS WG Jim Reid Chair ------ 5c5 < The RIPE DNSSEC Trust Anchor Repository task force welcomes this --- > The RIPE DNS working group (DNS WG) force welcomes this 7,9c7,9 < soon as possible. From our own work we have developed the following < set of reuirements which may be useful for you when implementing < the service: --- > soon as possible. As you know we have developed a set of requirements > for such a repository. As these may be useful for you when implementing > the service, we offer them here: 13,16c13,14 < prevent different flavours of trust anchors to be published. < < Comment: Publishing RRs as defined by the relevant standards meets < this requirement. --- > prevent different flavours of trust anchors to be published, provided > provided those trust anchors conform to the relevant standards. 20,21c18,19 < to transform this tarball of crypto gunk into stuff to plug into your < name server configuration". --- > to transform this crypto gunk into stuff to plug into your > resolver/server configuration". 27,32c25,33 < [3] The TAR should somehow verify the keying material it's given < before publishing or storing it. There should also be a secure channel < for authenticating the TAR and any data it's publishing. < < Comment: We assume this is SOP for TLD requests and would be implemented < here also. --- > [3] The TAR should verify that the keying material it receives comes > from authorised source, verify it is correctly formatted and verify > it is consisten with what is published in the TLD zone before publishing it. > There should also be a secure channel for authenticating the TAR and any > data it is publishing. > > Comment: Using the same channels IANA uses to receive update requests to the > root zone from TLDs is fine. We do not mean special new channels. > https delivery and possibly checksums are sufficient for publication. 40c41 < [6] The TAR should be clear what support, if any, is available. --- > [5] The TAR should be clear what support, if any, is available. 42c43 < [10] The TAR must have exit strategy. --- > [6] The TAR must have exit strategy. 46,50c47 < [10a] the TAR must store its data under escrow somewhere. < < Comment: Not necessary to start with, i.e. should not delay but needs to be developed < < [11] The TAR should only publish keying material with the consent of --- > [7] The TAR should only publish keying material with the consent of 53,55d49 < Comment: we believe that is SOP and part of the proposa. < < 61c55 < Kind rregards --- > Kind Regards 63c57 < RIPE DNSSEC trust Anchor Repository Task Forkce --- > RIPE DNS WG 66,69d59 < From Joao_Damas at isc.org Wed Apr 16 14:06:12 2008 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 16 Apr 2008 14:06:12 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416115132.GK351@reiftel.karrenberg.net> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> Message-ID: <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> On 16 Apr 2008, at 13:51, Daniel Karrenberg wrote: > > New text. > > I dropped the escrow bit, because further cogitation makes it seem > a very bottomless pit to me in the IANA context. I hope y'all can > agree. > diff follows below: > > > ------ > > Dear Barbara, > > thank you for your note about the proposed DS key registry for TLDs. > The RIPE DNS working group (DNS WG) force welcomes this > development. We would like to see IANA providing such a registry as > soon as possible. As you know we have developed a set of requirements > for such a repository. As these may be useful for you when > implementing > the service, we offer them here: > > > [1] The registry should be technology neutral. It should not exclude > or > prevent different flavours of trust anchors to be published, provided > provided those trust anchors conform to the relevant standards. > s/provided provided/provided/ > [2] The TAR should be OS/DNS implementation neutral. Tools and > documentation should be provided for the common platforms: "here's how > to transform this crypto gunk into stuff to plug into your > resolver/server configuration". > > Comment: IANA should publish such docmentation and tools, or > pointers to > them. Once we know details of repository, we can help putting together > this documentation. > > [3] The TAR should verify that the keying material it receives comes > from authorised source, verify it is correctly formatted and verify > it is consisten with what is published in the TLD zone before > publishing it. > There should also be a secure channel for authenticating the TAR > and any > data it is publishing. > what does correctly formatted mean? s/consiten/consistent/ I am struggling with what would constitute a secure channel here? Would it be a phone call, a fax, something over the Internet? Can we just say the verification should be through an IANA trusted channel not including any DNS data? I think most important part here is that key is not slurped from the zone itself, but that it arrives at IANA by another means (and can later be checked against the DNS entries) > Comment: Using the same channels IANA uses to receive update > requests to the > root zone from TLDs is fine. We do not mean special new channels. > https delivery and possibly checksums are sufficient for publication. > > [4] A process is needed to revoke a trust anchor and notify those who > may be using the now withdrawn or invalid trust anchor. > > Comment: An opt-in mailing list for operational news should be > sufficient > to satisfy this. > > [5] The TAR should be clear what support, if any, is available. > > [6] The TAR must have exit strategy. > > Comment: The proposal includes that. > > [7] The TAR should only publish keying material with the consent of > the respective key manager. > > Please let us know any the details of the repository as well as the > time-line > for implementation as soon as they become available. Please feel > free to make > our supoort for this repository known to anyone in the ICANN > govenance structure > if it helps to push this along. OK, with text, minding the comments/typos Joao From daniel.karrenberg at ripe.net Wed Apr 16 14:45:55 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 14:45:55 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> References: <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> Message-ID: <20080416124555.GN351@reiftel.karrenberg.net> Typos corrected, colloquial wording formalised, easy comments folded in. Only thing missing is Joao's comment re verification/secure channel. Looking for guidance there. Did I miss anything else? Diff only this time, but with context: ------ *** iana-keyrep.txt 2008/04/16 12:34:16 1.3 --- iana-keyrep.txt 2008/04/16 12:42:37 *************** *** 2,8 **** Dear Barbara, thank you for your note about the proposed DS key registry for TLDs. ! The RIPE DNS working group (DNS WG) force welcomes this development. We would like to see IANA providing such a registry as soon as possible. As you know we have developed a set of requirements for such a repository. As these may be useful for you when implementing --- 2,8 ---- Dear Barbara, thank you for your note about the proposed DS key registry for TLDs. ! The RIPE DNS working group (DNS WG) welcomes this development. We would like to see IANA providing such a registry as soon as possible. As you know we have developed a set of requirements for such a repository. As these may be useful for you when implementing *************** *** 10,31 **** [1] The registry should be technology neutral. It should not exclude or ! prevent different flavours of trust anchors to be published, provided ! provided those trust anchors conform to the relevant standards. ! [2] The TAR should be OS/DNS implementation neutral. Tools and ! documentation should be provided for the common platforms: "here's how ! to transform this crypto gunk into stuff to plug into your ! resolver/server configuration". ! Comment: IANA should publish such docmentation and tools, or pointers to them. Once we know details of repository, we can help putting together this documentation. ! [3] The TAR should verify that the keying material it receives comes ! from authorised source, verify it is correctly formatted and verify ! it is consisten with what is published in the TLD zone before publishing it. ! There should also be a secure channel for authenticating the TAR and any data it is publishing. Comment: Using the same channels IANA uses to receive update requests to the --- 10,30 ---- [1] The registry should be technology neutral. It should not exclude or ! prevent different flavors of trust anchors to be published, provided ! those trust anchors conform to the relevant standards. ! [2] The registry should be OS/DNS implementation neutral. Tools and ! documentation should be provided for use of the repository with common ! DNS resolver and name server platforms. ! Comment: IANA should publish such documentation and tools, or pointers to them. Once we know details of repository, we can help putting together this documentation. ! [3] The registry should verify that the keying material it receives comes ! from an authorised source, verify it is correctly formatted and verify ! it is consistent with what is published in the TLD zone before publishing it. ! There should also be a secure channel for authenticating the registry and any data it is publishing. Comment: Using the same channels IANA uses to receive update requests to the *************** *** 38,55 **** Comment: An opt-in mailing list for operational news should be sufficient to satisfy this. ! [5] The TAR should be clear what support, if any, is available. ! [6] The TAR must have exit strategy. Comment: The proposal includes that. ! [7] The TAR should only publish keying material with the consent of the respective key manager. Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make ! our supoort for this repository known to anyone in the ICANN govenance structure if it helps to push this along. Kind Regards --- 37,54 ---- Comment: An opt-in mailing list for operational news should be sufficient to satisfy this. ! [5] The registry should be clear what support, if any, is available. ! [6] The registry must have a published exit strategy. Comment: The proposal includes that. ! [7] The registry should only publish keying material with the consent of the respective key manager. Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make ! our support for this repository known to anyone in the ICANN governance structure if it helps to push this along. Kind Regards From daniel.karrenberg at ripe.net Wed Apr 16 14:50:24 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 14:50:24 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416124555.GN351@reiftel.karrenberg.net> References: <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> <20080416124555.GN351@reiftel.karrenberg.net> Message-ID: <20080416125024.GO351@reiftel.karrenberg.net> Peter Koch suggests privately to keep calling it a TAR. Can easily do that. Opinions? Daniel From pk at DENIC.DE Wed Apr 16 15:01:06 2008 From: pk at DENIC.DE (Peter Koch) Date: Wed, 16 Apr 2008 15:01:06 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416125024.GO351@reiftel.karrenberg.net> References: <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> <20080416124555.GN351@reiftel.karrenberg.net> <20080416125024.GO351@reiftel.karrenberg.net> Message-ID: <20080416130106.GM8471@unknown.office.denic.de> On Wed, Apr 16, 2008 at 02:50:24PM +0200, Daniel Karrenberg wrote: > > Peter Koch suggests privately to keep calling it a TAR. Can easily do that. to clarify: it started as a nit about consistent wording. "TAR" is a more or less commonly used term these days and that's why I prefer it over 'registry' or even 'DS key registry'. One could also argue that the trust anchor repository indeed isn't a registry but collects attributes ofg another registry. No big issue, though. -Peter From Joao_Damas at isc.org Wed Apr 16 15:01:19 2008 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 16 Apr 2008 15:01:19 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416125024.GO351@reiftel.karrenberg.net> References: <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> <20080416124555.GN351@reiftel.karrenberg.net> <20080416125024.GO351@reiftel.karrenberg.net> Message-ID: sure On 16 Apr 2008, at 14:50, Daniel Karrenberg wrote: > > Peter Koch suggests privately to keep calling it a TAR. Can easily > do that. > Opinions? > > Daniel From jim at rfc1035.com Wed Apr 16 15:02:58 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 16 Apr 2008 14:02:58 +0100 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416125024.GO351@reiftel.karrenberg.net> References: <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> <20080416124555.GN351@reiftel.karrenberg.net> <20080416125024.GO351@reiftel.karrenberg.net> Message-ID: <91ADF3D5-8668-4C6E-9ECA-094A837309E3@rfc1035.com> On 16 Apr 2008, at 13:50, Daniel Karrenberg wrote: > Peter Koch suggests privately to keep calling it a TAR. Can easily > do that. > Opinions? Make it so. :-) From jim at rfc1035.com Wed Apr 16 15:11:30 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 16 Apr 2008 14:11:30 +0100 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> References: <20080416062537.GB351@reiftel.karrenberg.net> <20080416070106.GD342@reiftel.karrenberg.net> <20080416072845.GA8471@unknown.office.denic.de> <8F34C62D-217C-4932-864E-E0F58B571727@isc.org> <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> Message-ID: <79B6182F-CEC5-4A8C-9EB2-94DBB75F712D@rfc1035.com> On 16 Apr 2008, at 13:06, Joao Damas wrote: > I am struggling with what would constitute a secure channel here? I think we all are Joao. So let's duck this and leave it as an implementation detail for the consenting parties. > I think most important part here is that key is not slurped from the > zone itself, but that it arrives at IANA by another means (and can > later be checked against the DNS entries) Yup! How the key gets from A to B securely (for some definition of securely) is up to A and B to figure out. Nobody else needs to know or care about that. As long as this does not involve B grabbing A's keying material from the zone, as you rightly pointed out. From daniel.karrenberg at ripe.net Wed Apr 16 15:29:59 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Apr 2008 15:29:59 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <91ADF3D5-8668-4C6E-9ECA-094A837309E3@rfc1035.com> References: <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> <20080416124555.GN351@reiftel.karrenberg.net> <20080416125024.GO351@reiftel.karrenberg.net> <91ADF3D5-8668-4C6E-9ECA-094A837309E3@rfc1035.com> Message-ID: <20080416132959.GF342@reiftel.karrenberg.net> On 16.04 14:02, Jim Reid wrote: > On 16 Apr 2008, at 13:50, Daniel Karrenberg wrote: > > >Peter Koch suggests privately to keep calling it a TAR. Can easily > >do that. > >Opinions? > > Make it so. :-) OK. Can we send this to the DNS WG? ---- Dear Barbara, thank you for your note about the proposed DS key registry for TLDs. The RIPE DNS working group (DNS WG) welcomes this development. We would like to see IANA providing a TLD trust anchor repository (TAR) as soon as possible. As you know we have developed a set of requirements for such a repository. As these may be useful for you when implementing the service, we offer them here: [1] The TAR should be technology neutral. It should not exclude or prevent different flavors of trust anchors to be published, provided those trust anchors conform to the relevant Internet standards. [2] The TAR should be OS/DNS implementation neutral. Tools and documentation should be provided for use of the repository with common DNS resolver and name server platforms. Comment: IANA should publish such documentation and tools, or pointers to them. Once we know details of the repository, we can help putting together this documentation. [3] The TAR should verify that the keying material it receives comes from an authorised source, verify it is correctly formatted and verify it is consistent with what is published in the TLD zone before publishing it. There should also be a secure channel for authenticating the TAR and any data it is publishing. Comment: Using the same channels IANA uses to receive update requests to the root zone from TLDs is fine. We do not mean special new channels. https delivery and possibly checksums are sufficient for publication. [4] A process is needed to revoke a trust anchor and notify those who may be using the now withdrawn or invalid trust anchor. Comment: An opt-in mailing list for operational news should be sufficient to satisfy this. [5] The TAR should be clear what support, if any, is available. [6] The TAR must have a published exit strategy. Comment: The proposal includes that. [7] The TAR should only publish keying material with the consent of the respective key manager. Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make our support for this repository known to anyone in the ICANN governance structure if it helps to push this along. Kind Regards RIPE DNS WG Jim Reid Chair ---- *** iana-keyrep.txt 2008/04/16 12:34:16 1.3 --- iana-keyrep.txt 2008/04/16 13:27:09 *************** *** 2,31 **** Dear Barbara, thank you for your note about the proposed DS key registry for TLDs. ! The RIPE DNS working group (DNS WG) force welcomes this ! development. We would like to see IANA providing such a registry as ! soon as possible. As you know we have developed a set of requirements ! for such a repository. As these may be useful for you when implementing the service, we offer them here: ! ! [1] The registry should be technology neutral. It should not exclude or ! prevent different flavours of trust anchors to be published, provided ! provided those trust anchors conform to the relevant standards. [2] The TAR should be OS/DNS implementation neutral. Tools and ! documentation should be provided for the common platforms: "here's how ! to transform this crypto gunk into stuff to plug into your ! resolver/server configuration". ! Comment: IANA should publish such docmentation and tools, or pointers to ! them. Once we know details of repository, we can help putting together this documentation. [3] The TAR should verify that the keying material it receives comes ! from authorised source, verify it is correctly formatted and verify ! it is consisten with what is published in the TLD zone before publishing it. ! There should also be a secure channel for authenticating the TAR and any data it is publishing. Comment: Using the same channels IANA uses to receive update requests to the --- 2,29 ---- Dear Barbara, thank you for your note about the proposed DS key registry for TLDs. ! The RIPE DNS working group (DNS WG) welcomes this development. We would ! like to see IANA providing a TLD trust anchor repository (TAR) ! as soon as possible. As you know we have developed a set of requirements ! for such a repository. As these may be useful for you when implementing the service, we offer them here: ! [1] The TAR should be technology neutral. It should not exclude or ! prevent different flavors of trust anchors to be published, provided ! those trust anchors conform to the relevant Internet standards. [2] The TAR should be OS/DNS implementation neutral. Tools and ! documentation should be provided for use of the repository with common ! DNS resolver and name server platforms. ! Comment: IANA should publish such documentation and tools, or pointers to ! them. Once we know details of the repository, we can help putting together this documentation. [3] The TAR should verify that the keying material it receives comes ! from an authorised source, verify it is correctly formatted and verify ! it is consistent with what is published in the TLD zone before publishing it. ! There should also be a secure channel for authenticating the TAR and any data it is publishing. Comment: Using the same channels IANA uses to receive update requests to the *************** *** 40,46 **** [5] The TAR should be clear what support, if any, is available. ! [6] The TAR must have exit strategy. Comment: The proposal includes that. --- 38,44 ---- [5] The TAR should be clear what support, if any, is available. ! [6] The TAR must have a published exit strategy. Comment: The proposal includes that. *************** *** 49,55 **** Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make ! our supoort for this repository known to anyone in the ICANN govenance structure if it helps to push this along. Kind Regards --- 47,53 ---- Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make ! our support for this repository known to anyone in the ICANN governance structure if it helps to push this along. Kind Regards From pk at DENIC.DE Wed Apr 16 15:36:53 2008 From: pk at DENIC.DE (Peter Koch) Date: Wed, 16 Apr 2008 15:36:53 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416132959.GF342@reiftel.karrenberg.net> References: <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> <20080416124555.GN351@reiftel.karrenberg.net> <20080416125024.GO351@reiftel.karrenberg.net> <91ADF3D5-8668-4C6E-9ECA-094A837309E3@rfc1035.com> <20080416132959.GF342@reiftel.karrenberg.net> Message-ID: <20080416133653.GO8471@unknown.office.denic.de> On Wed, Apr 16, 2008 at 03:29:59PM +0200, Daniel Karrenberg wrote: > > Make it so. :-) > > OK. Can we send this to the DNS WG? ACK from me. Thanks, Daniel. -Peter From Joao_Damas at isc.org Wed Apr 16 15:38:13 2008 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 16 Apr 2008 15:38:13 +0200 Subject: [dnssec-key-tf] Proposed Mesage to IANA In-Reply-To: <20080416132959.GF342@reiftel.karrenberg.net> References: <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> <20080416124555.GN351@reiftel.karrenberg.net> <20080416125024.GO351@reiftel.karrenberg.net> <91ADF3D5-8668-4C6E-9ECA-094A837309E3@rfc1035.com> <20080416132959.GF342@reiftel.karrenberg.net> Message-ID: <46DEC33B-57B9-4B01-AA47-3B721F86AEBF@isc.org> Yes On 16 Apr 2008, at 15:29, Daniel Karrenberg wrote: > On 16.04 14:02, Jim Reid wrote: >> On 16 Apr 2008, at 13:50, Daniel Karrenberg wrote: >> >>> Peter Koch suggests privately to keep calling it a TAR. Can easily >>> do that. >>> Opinions? >> >> Make it so. :-) > > OK. Can we send this to the DNS WG? > > > ---- > > Dear Barbara, > > thank you for your note about the proposed DS key registry for TLDs. > The RIPE DNS working group (DNS WG) welcomes this development. We > would > like to see IANA providing a TLD trust anchor repository (TAR) > as soon as possible. As you know we have developed a set of > requirements > for such a repository. As these may be useful for you when > implementing > the service, we offer them here: > > [1] The TAR should be technology neutral. It should not exclude or > prevent different flavors of trust anchors to be published, provided > those trust anchors conform to the relevant Internet standards. > > [2] The TAR should be OS/DNS implementation neutral. Tools and > documentation should be provided for use of the repository with common > DNS resolver and name server platforms. > > Comment: IANA should publish such documentation and tools, or > pointers to > them. Once we know details of the repository, we can help putting > together > this documentation. > > [3] The TAR should verify that the keying material it receives comes > from an authorised source, verify it is correctly formatted and verify > it is consistent with what is published in the TLD zone before > publishing it. > There should also be a secure channel for authenticating the TAR and > any > data it is publishing. > > Comment: Using the same channels IANA uses to receive update > requests to the > root zone from TLDs is fine. We do not mean special new channels. > https delivery and possibly checksums are sufficient for publication. > > [4] A process is needed to revoke a trust anchor and notify those who > may be using the now withdrawn or invalid trust anchor. > > Comment: An opt-in mailing list for operational news should be > sufficient > to satisfy this. > > [5] The TAR should be clear what support, if any, is available. > > [6] The TAR must have a published exit strategy. > > Comment: The proposal includes that. > > [7] The TAR should only publish keying material with the consent of > the respective key manager. > > Please let us know any the details of the repository as well as the > time-line > for implementation as soon as they become available. Please feel > free to make > our support for this repository known to anyone in the ICANN > governance structure > if it helps to push this along. > > Kind Regards > > RIPE DNS WG > Jim Reid > Chair > > ---- > > > *** iana-keyrep.txt 2008/04/16 12:34:16 1.3 > --- iana-keyrep.txt 2008/04/16 13:27:09 > *************** > *** 2,31 **** > Dear Barbara, > > thank you for your note about the proposed DS key registry for TLDs. > ! The RIPE DNS working group (DNS WG) force welcomes this > ! development. We would like to see IANA providing such a registry as > ! soon as possible. As you know we have developed a set of > requirements > ! for such a repository. As these may be useful for you when > implementing > the service, we offer them here: > > ! > ! [1] The registry should be technology neutral. It should not > exclude or > ! prevent different flavours of trust anchors to be published, > provided > ! provided those trust anchors conform to the relevant standards. > > [2] The TAR should be OS/DNS implementation neutral. Tools and > ! documentation should be provided for the common platforms: "here's > how > ! to transform this crypto gunk into stuff to plug into your > ! resolver/server configuration". > > ! Comment: IANA should publish such docmentation and tools, or > pointers to > ! them. Once we know details of repository, we can help putting > together > this documentation. > > [3] The TAR should verify that the keying material it receives comes > ! from authorised source, verify it is correctly formatted and verify > ! it is consisten with what is published in the TLD zone before > publishing it. > ! There should also be a secure channel for authenticating the TAR > and any > data it is publishing. > > Comment: Using the same channels IANA uses to receive update > requests to the > --- 2,29 ---- > Dear Barbara, > > thank you for your note about the proposed DS key registry for TLDs. > ! The RIPE DNS working group (DNS WG) welcomes this development. We > would > ! like to see IANA providing a TLD trust anchor repository (TAR) > ! as soon as possible. As you know we have developed a set of > requirements > ! for such a repository. As these may be useful for you when > implementing > the service, we offer them here: > > ! [1] The TAR should be technology neutral. It should not exclude or > ! prevent different flavors of trust anchors to be published, provided > ! those trust anchors conform to the relevant Internet standards. > > [2] The TAR should be OS/DNS implementation neutral. Tools and > ! documentation should be provided for use of the repository with > common > ! DNS resolver and name server platforms. > > ! Comment: IANA should publish such documentation and tools, or > pointers to > ! them. Once we know details of the repository, we can help putting > together > this documentation. > > [3] The TAR should verify that the keying material it receives comes > ! from an authorised source, verify it is correctly formatted and > verify > ! it is consistent with what is published in the TLD zone before > publishing it. > ! There should also be a secure channel for authenticating the TAR > and any > data it is publishing. > > Comment: Using the same channels IANA uses to receive update > requests to the > *************** > *** 40,46 **** > > [5] The TAR should be clear what support, if any, is available. > > ! [6] The TAR must have exit strategy. > > Comment: The proposal includes that. > > --- 38,44 ---- > > [5] The TAR should be clear what support, if any, is available. > > ! [6] The TAR must have a published exit strategy. > > Comment: The proposal includes that. > > *************** > *** 49,55 **** > > Please let us know any the details of the repository as well as the > time-line > for implementation as soon as they become available. Please feel > free to make > ! our supoort for this repository known to anyone in the ICANN > govenance structure > if it helps to push this along. > > Kind Regards > --- 47,53 ---- > > Please let us know any the details of the repository as well as the > time-line > for implementation as soon as they become available. Please feel > free to make > ! our support for this repository known to anyone in the ICANN > governance structure > if it helps to push this along. > > Kind Regards From jim at rfc1035.com Wed Apr 16 17:55:39 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 16 Apr 2008 16:55:39 +0100 Subject: [dnssec-key-tf] decision time on IANA letter In-Reply-To: <20080416132959.GF342@reiftel.karrenberg.net> References: <20080416080141.GC8471@unknown.office.denic.de> <20080416093422.GE351@reiftel.karrenberg.net> <9BFCCDC3-B757-45E3-8EA4-2C12EBAF2482@rfc1035.com> <20080416113455.GJ351@reiftel.karrenberg.net> <20080416115132.GK351@reiftel.karrenberg.net> <86783FAD-F275-4B8E-AB48-7B5879763F7D@isc.org> <20080416124555.GN351@reiftel.karrenberg.net> <20080416125024.GO351@reiftel.karrenberg.net> <91ADF3D5-8668-4C6E-9ECA-094A837309E3@rfc1035.com> <20080416132959.GF342@reiftel.karrenberg.net> Message-ID: On 16 Apr 2008, at 14:29, Daniel Karrenberg wrote: > OK. Can we send this to the DNS WG? I think so. Thanks Daniel. Although it looks like we have a consensus, I would like to hear from the other (silent) members of the TF. So since Daniel made me TF Chair, I have made an executive decision. :-) Unless there are any objections or amendments by Friday, I will declare TF consensus on Daniel's latest text on Monday. It will then go to the DNS WG for endorsement. From sanz at denic.de Thu Apr 17 15:39:54 2008 From: sanz at denic.de (Marcos Sanz/Denic) Date: Thu, 17 Apr 2008 15:39:54 +0200 Subject: [dnssec-key-tf] decision time on IANA letter In-Reply-To: Message-ID: > I think so. Thanks Daniel. Although it looks like we have a consensus, > I would like to hear from the other (silent) members of the TF. Silent consent, no objections. Thanks Daniel. Best, Marcos From jim at rfc1035.com Wed Apr 23 13:42:30 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 23 Apr 2008 12:42:30 +0100 Subject: [dnssec-key-tf] final text for ICANN/IANA Message-ID: <59A1716A-FAE1-4B9C-9D7B-F89ABC2E76AD@rfc1035.com> Chaps, here is what I hope is the final version of the TF text. I've replaced the references to "registry" with "TAR" as we agreed following Peter's request. There are some minor cosmetic changes too: like spelling "flavour" correctly. :-) Please scream if there's anything in the text that you violently disagree with. My intention is to send this to the WG list on Friday saying this is the consensus view of the TF and to ask the WG to endorse the statement to ICANN. -------------- next part -------------- A non-text attachment was scrubbed... Name: text Type: application/octet-stream Size: 2271 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/dnssec-key-tf/attachments/20080423/617d5dea/attachment.obj From pk at DENIC.DE Wed Apr 23 14:09:26 2008 From: pk at DENIC.DE (Peter Koch) Date: Wed, 23 Apr 2008 14:09:26 +0200 Subject: [dnssec-key-tf] final text for ICANN/IANA In-Reply-To: <59A1716A-FAE1-4B9C-9D7B-F89ABC2E76AD@rfc1035.com> References: <59A1716A-FAE1-4B9C-9D7B-F89ABC2E76AD@rfc1035.com> Message-ID: <20080423120926.GD2238@unknown.office.denic.de> Hi Jim, On Wed, Apr 23, 2008 at 12:42:30PM +0100, Jim Reid wrote: > Chaps, here is what I hope is the final version of the TF text. I've > replaced the references to "registry" with "TAR" as we agreed > following Peter's request. There are some minor cosmetic changes too: well, actually the opposite happened, but that's OK in that one case ;-) > anything in the text that you violently disagree with. My intention One nit only: "Once we know details of _the_ repository, we can help putting together this documentation" > is to send this to the WG list on Friday saying this is the consensus > view of the TF and to ask the WG to endorse the statement to ICANN. Now, last time this communication was sent via the NCC on behalf of the whole RIPE community. Shall this "stop" at the DNS WG this time or am I now disclosing the Secret Plan? -Peter From daniel.karrenberg at ripe.net Wed Apr 23 14:59:41 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 23 Apr 2008 14:59:41 +0200 Subject: [dnssec-key-tf] final text for ICANN/IANA In-Reply-To: <59A1716A-FAE1-4B9C-9D7B-F89ABC2E76AD@rfc1035.com> References: <59A1716A-FAE1-4B9C-9D7B-F89ABC2E76AD@rfc1035.com> Message-ID: <20080423125941.GE326@reiftel.local> On 23.04 12:42, Jim Reid wrote: I thaough this was past friday :-( ;-). Agree on the tet. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: text Type: application/octet-stream Size: 2271 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/dnssec-key-tf/attachments/20080423/0c5194e2/attachment.obj From weiler at watson.org Wed Apr 23 17:41:08 2008 From: weiler at watson.org (Samuel Weiler) Date: Wed, 23 Apr 2008 11:41:08 -0400 (EDT) Subject: [dnssec-key-tf] final text for ICANN/IANA In-Reply-To: <59A1716A-FAE1-4B9C-9D7B-F89ABC2E76AD@rfc1035.com> References: <59A1716A-FAE1-4B9C-9D7B-F89ABC2E76AD@rfc1035.com> Message-ID: <20080423113828.J63819@fledge.watson.org> On Wed, 23 Apr 2008, Jim Reid wrote: > Chaps, here is what I hope is the final version of the TF text. I've replaced > the references to "registry" with "TAR" as we agreed following Peter's > request. There are some minor cosmetic changes too: like spelling "flavour" > correctly. :-) Please scream if there's anything in the text that you > violently disagree with. My intention is to send this to the WG list on > Friday saying this is the consensus view of the TF and to ask the WG to > endorse the statement to ICANN. I'm very happy with this text. I've sent some editorial suggestions to Jim separately. I'd be happier to say "...should have a published exit strategy" instead of "must", but I'm content with what's in the document. -- Sam From jim at rfc1035.com Sun Apr 27 18:24:45 2008 From: jim at rfc1035.com (Jim Reid) Date: Sun, 27 Apr 2008 17:24:45 +0100 Subject: [dnssec-key-tf] final text Message-ID: <97A8F65D-9060-4E1A-BB3D-F0A0106F80F7@rfc1035.com> I've incorporated the changes Sam suggested: a couple of minor tidy- ups of the language. Here's the final version that's about to to to the WG. Dear Barbara, Thank you for your note about the proposed DNSSEC key repository for TLDs. The RIPE DNS working group (DNS WG) welcomes this development. We would like to see IANA establish this DNSSEC Trust Anchor Repository (TAR) as soon as possible. We have developed a set of requirements for such a repository. As these may be useful for you when implementing the service, we offer them here: [1] The TAR should be technology neutral. It should not exclude or prevent different flavours of trust anchors from being published, provided those trust anchors conform to the relevant standards. [2] The TAR should be OS/DNS implementation neutral. Tools and documentation should be provided for use of the repository with common DNS resolver and name server platforms. Comment: IANA should publish such documentation and tools, or pointers to them. Once we know details of repository, we can help putting together this documentation. [3] The TAR should verify that the keying material it receives comes from an authorised source, verify it is correctly formatted and verify it is consistent with what is published in the TLD zone before publishing it. There should also be a secure channel for authenticating the repository and any data it is publishing. Comment: Using the same channels IANA uses to process update requests to the root zone from TLDs should be fine. We do not mean special new channels. https delivery and possibly checksums are sufficient for publication. [4] A process is needed to revoke a trust anchor and notify those who may be using the now withdrawn or invalid trust anchor. Comment: An opt-in mailing list for operational news should be sufficient to satisfy this. [5] The TAR should be clear what support, if any, is available. [6] The TAR must have a published exit strategy. Comment: The proposal includes that. [7] The TAR should only publish keying material with the consent of the respective key manager. Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make our support for this repository known publicly or within ICANN. Kind Regards RIPE DNS WG Jim Reid Chair From weiler at watson.org Mon Apr 28 18:53:43 2008 From: weiler at watson.org (Samuel Weiler) Date: Mon, 28 Apr 2008 12:53:43 -0400 (EDT) Subject: [dnssec-key-tf] explaining the IANA requirement letter In-Reply-To: <97A8F65D-9060-4E1A-BB3D-F0A0106F80F7@rfc1035.com> References: <97A8F65D-9060-4E1A-BB3D-F0A0106F80F7@rfc1035.com> Message-ID: <20080428124903.C5224@fledge.watson.org> Someone elsewhere asked for clarification about requirement 1, re: technology neutral. Here's what I wrote in response (stealing briefly from a note from Peter). Feel free to let me know if you disagree, and feel free to steal the text for other things: I think the requirement re: technology neutrality means at least two things: First, the TAR should not exclude trust anchors based on crypto algorithm, key length, status of the SEP bit, use of the keys (e.g. separation of ZSK & KSK functionality), or similar reasons, so long as the trust anchors reasonably conform to the specifications. More requirements might be imposed by other parties or community consensus, but the TAR operator shouldn't be doing such on its own. The TAR operator might provide some helpful support ("er, are you sure you want to do that?"), but it shouldn't be making up rules. Second, the publication mechanism(s) and format(s) should not favor or disfavor any particular use of the trust anchors, as much as possible. It would be unacceptable to have the only mechanism for accessing the TAR require particular code (e.g., rsync, which doesn't have _independent_ interoperable implementations, or a particular resolver). And it would be unacceptable to use only an (uncommon) TA format that is not boardly supported (e.g., a configuration file for a resolver that, due to design, needs less information on each TA than other resolvers, meaning that it might not be trivially transformed into a config file for other resolvers). I think both IANA and most members of the task force are envisioning IANA's repository being formatted either as DS records or as config statements for common DNSSEC resolver(s) and published AT LEAST in some bulk distribution mechanism (e.g., a signed file or tarball, available over ftp or/and http), which easily meets this requirement. -- Sam From jim at rfc1035.com Mon Apr 28 19:29:13 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 28 Apr 2008 18:29:13 +0100 Subject: [dnssec-key-tf] Re: explaining the IANA requirement letter In-Reply-To: <20080428124903.C5224@fledge.watson.org> References: <97A8F65D-9060-4E1A-BB3D-F0A0106F80F7@rfc1035.com> <20080428124903.C5224@fledge.watson.org> Message-ID: On Apr 28, 2008, at 17:53, Samuel Weiler wrote: > Someone elsewhere asked for clarification about requirement 1, re: > technology neutral. Here's what I wrote in response (stealing > briefly from a note from Peter). Feel free to let me know if you > disagree, and feel free to steal the text for other things Thanks Sam. I think it would be helpful if you posted your clarification to the WG list. Further discussion probably belongs there rather than here. Since we are trying to get WG support for these TAR requirements, we may well have to explain a little bit more to the WG what the TF has produced. Your comments should help to move things along. In short, I think/hope we all know what the TF has agreed but the WG overall might still be uncertain about that. :-) From pk at DENIC.DE Mon Apr 28 19:37:49 2008 From: pk at DENIC.DE (Peter Koch) Date: Mon, 28 Apr 2008 19:37:49 +0200 Subject: [dnssec-key-tf] Re: explaining the IANA requirement letter In-Reply-To: References: <97A8F65D-9060-4E1A-BB3D-F0A0106F80F7@rfc1035.com> <20080428124903.C5224@fledge.watson.org> Message-ID: <20080428173749.GA14499@x27.adm.denic.de> On Mon, Apr 28, 2008 at 06:29:13PM +0100, Jim Reid wrote: > Thanks Sam. I think it would be helpful if you posted your > clarification to the WG list. Further discussion probably belongs > there rather than here. Since we are trying to get WG support for > these TAR requirements, we may well have to explain a little bit more > to the WG what the TF has produced. Your comments should help to move > things along. well, we might be at the rough edge here. The note Sam referred to was probably my list of questions, but that didn't mean I expressed an (equal) opinion to all of those options. That said, the IANA TAR shouldn't prefer a particular DNS vendor, but I'm not convinced that it is a good _requirement_ not to ask for, say, the SEP bit. Some consistency checks won't be too bad, but the exact form was and is out of the scope of this task force. -Peter