From owner-dns-security@lists.tislabs.com Tue Jul 6 18:14:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12553 for ; Tue, 6 Jul 1999 18:14:18 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09695 Tue, 6 Jul 1999 17:22:07 -0400 (EDT) Message-ID: From: Stuart Kwan To: "'Harald Tveit Alvestrand'" , "'Robert Elz'" , namedroppers@internic.net Cc: dns-security@lists.tislabs.com Subject: RE: skwan-utf8-dns (RE: (Almost final) Agenda for dnsind/dnssec i n Oslo) Date: Tue, 6 Jul 1999 14:19:42 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Harald, draft-skwan-utf8-dns-02.txt is merely a republishing of -01, to keep the draft alive. Your comments are relevant, and welcome. I have only just seen Draft Unicode Technical Report #15 (http://www.unicode.org/unicode/reports/tr15/) and need to take some time to study it further. Cheers, - Stuart -----Original Message----- From: Harald Tveit Alvestrand [mailto:Harald@Alvestrand.no] Sent: Friday, July 02, 1999 2:55 PM To: Stuart Kwan; 'Robert Elz'; namedroppers@internic.net Cc: dns-security@lists.tislabs.com Subject: skwan-utf8-dns (RE: (Almost final) Agenda for dnsind/dnssec in Oslo) At 19:50 28.06.99 -0700, Stuart Kwan wrote: >Unfortunately, Levon Esibov and I will not be attending in Oslo. > >I have no suitable proxy to lead a discussion on UTF-8 DNS >(ftp://ftp.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt) or on the >GSS algorithm for TSIG >(http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt), so you >may remove those from the schedule. Both Levon and I would be happy to hear >comments on the mailing list. I would like to comment on draft-skwan-utf8-dns, but my comments may be somewhat savage. And also out of sync, since on this remote island off the north coast of Norway, I don't have a copy of version -02. The most important problem I see is: This document defines an input transformation (UTF-8 downcasing) on data without defining which data this input transformation will be applied to. The idea of "all textual data" seems logical, but exactly which record types does that mean? The devil is in the details.... And - do we KNOW that no application ever depends on case data in a text record? URLs, for instance, are case sensitive. The other problem is the idea that byte-wise comparision of downcased strings is sufficient for the comparision of UTF-8 encoded strings. Much work is currently ongoing wrt Unicode normalization. Do we want to lock ourselves in now? I've long wanted UTF-8 data in the DNS. And I think it's possible to Do Right. But I don't think -skwan-utf8-dns-01 is the Answer. But -02 may be. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-dns-security@lists.tislabs.com Wed Jul 7 09:23:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08851 for ; Wed, 7 Jul 1999 09:23:09 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11844 Wed, 7 Jul 1999 08:28:56 -0400 (EDT) Message-Id: <4.2.0.56.19990702234339.00e1e3c0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Fri, 02 Jul 1999 23:55:19 +0200 To: Stuart Kwan , "'Robert Elz'" , namedroppers@internic.net From: Harald Tveit Alvestrand Subject: skwan-utf8-dns (RE: (Almost final) Agenda for dnsind/dnssec in Oslo) Cc: dns-security@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dns-security@lists.tislabs.com Precedence: bulk At 19:50 28.06.99 -0700, Stuart Kwan wrote: >Unfortunately, Levon Esibov and I will not be attending in Oslo. > >I have no suitable proxy to lead a discussion on UTF-8 DNS >(ftp://ftp.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt) or on the >GSS algorithm for TSIG >(http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt), so you >may remove those from the schedule. Both Levon and I would be happy to hear >comments on the mailing list. I would like to comment on draft-skwan-utf8-dns, but my comments may be somewhat savage. And also out of sync, since on this remote island off the north coast of Norway, I don't have a copy of version -02. The most important problem I see is: This document defines an input transformation (UTF-8 downcasing) on data without defining which data this input transformation will be applied to. The idea of "all textual data" seems logical, but exactly which record types does that mean? The devil is in the details.... And - do we KNOW that no application ever depends on case data in a text record? URLs, for instance, are case sensitive. The other problem is the idea that byte-wise comparision of downcased strings is sufficient for the comparision of UTF-8 encoded strings. Much work is currently ongoing wrt Unicode normalization. Do we want to lock ourselves in now? I've long wanted UTF-8 data in the DNS. And I think it's possible to Do Right. But I don't think -skwan-utf8-dns-01 is the Answer. But -02 may be. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-dns-security@lists.tislabs.com Mon Jul 12 17:12:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17561 for ; Mon, 12 Jul 1999 17:12:34 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28649 Mon, 12 Jul 1999 16:05:17 -0400 (EDT) From: Robert Elz To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Brief summary of Oslo DNSIND/DNSSEC meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 19:53:03 +0200 Message-ID: <21746.931801983@cs.mu.OZ.AU> Sender: owner-dns-security@lists.tislabs.com Precedence: bulk This message is not the minutes of the meeting. Nor is anything reported here binding in any way of the group, we will discuss issues on the list. That can be done now (please start a new thread though, don't just reply to this message, and keep such discussions on namedropeprs alone), or you can wait for the minutes (or at least the first draft of them) to appear. Also, a reminder of the request to all who attended the meeting. If you took any notes, please send me a copy, now. Please don't wait to clean them up, etc - I'd prefer to have them as they first appeared (I also don't care if they contain references to how useless I am as a WG chair, etc ... I won't be resending your notes anywhere, just using them to assist in preparation of the minutes). Also, if anything below doesn't agree with your recollection of what the meeting did, please say so now, so the real minutes can be as accurate as possible. Say so on the list, so everyone can see, and respond. First announcements: edns0 has passed the IESG, it ought appear as an RFC sometime (the announcement to the RFC Editor from the IESG probably won't happen until after this meeting is over, and Steve Coya returns to his office). That will also release dname and binary-labels from the RFC editor's hold queue (or the IESG's hold queue, or something). An IETF last call of tsig-09 should appear soon (you will probably have seen the request for that in your mailbox sometime around the time that you see this message). The proposed charter for the new combined group was discussed briefly. Since the last version posted on the list, it has had a sentence added includig TSIG along with the DNSSEC in the "what the group does", as requested by Ed Lewis. The people in the room were generally happy to call the new group dnsext. No new issues were raised, though the "work in progress" and "milestones" will need to be revised as a result of this meeting, and then again as the result of discussions anticipated on the list. Matt Crawford asked (again) whether there were any more comments on draft-ietf-ipngwg-dns-lookups-04.txt - that is the definition of A6 records. That (ipngwg) draft should be going to IETF last call soon. There are suggestions that the IESG are looking for DNS review. What ought be done with 2052bis was discussed. General opinion favoured continuing to push it as PS. A long list of IESG requested changes were discussed (these to appear on the list soon). Aside from a bunch of trivial changes, the two of most substance concerned the definition of the weight field, and its processing - the suggested wording for that will still need some more work (either rephrasing, or a complete new method) but was generally considered acceptable. The other concerned the examples. There was much feeling that giving examples using protocols that don't use SRV records was not a good idea (and that the examples/test that relate to SMTP was particularly bad). What to replace them with wasn't as obvious. There were two basic suggestions - either use some of the protocols/usages that are now being created (there are a few in drafts scattered about, I will probably find some of them for the next, longer, message on 2052bis, but please, everyone, send pointers if you know them). Or, create a fictitious protocol, the foobar protocol, or something, and use that for the examples. I detected no consensus on which is the best approach. edns1 was very briefly mentioned. Discussion of it ought take place on the list. This is one of our major work items - please read it and comment. Some discussion on tkey. It has been waiting on tsig, but that is done now. Question on whether it ought be simplified, and whether as a mechanism it belongs in the DNS at all. Opinion expressed that as a bootstrap method it might be needed - it provides a way to get somekeys initially, without depending upon some other protocol, which is likely to be depending upon the DNS. After that, if better keys are needed, other mechanisms can be used. Opinion: this leads to multiple ways existing of doing much the same thing. More discussion of tkey on the list is needed. Some discussion on simple-secure-update. A list of the changes in the draft was given (without explanations in all cases, the draft author was not at the meeting). Dynamic update needs this or update2 (next draft to be discussed). Q: are there any implementations of this, or is it all just theory? A: so far, theory. But BIND9 is to implement this it was reported (but not update2). On update2 - this is the intended replacement for rfc2137, which has been obsoleted by 2535, but not yet replaced. As it stands it is too complex. A new draft, rather simpler, will eventually appear. General opinion that a mechanism like update2 is required, but not update2 as it stands. Not recommended for anyone to implement as it is. Also suggested that "simple-secure-update" and "secure-update" are loaded names, and that "shared key update" and "public key update" might be better terms. List discussion is needed on how we go about authenticating dynamic update, both in the local area, and over the internet as a whole. Brief discussions on rollover - mechanism to allow automated key-resigning requests (nb: not the signing itself, necessarily, just the notification that a resigning is required, if I understood it correctly). There has been little comment on this draft, comments were solicited. Q raised on how all this relates to a parent zone with shared administration, might it not be complex? A: yes. Series of questions/answers related to whether this is a good mechanism to request a key-signing, that might then take days to actually occur. More discussion of this needed on the list. Brief discussions on sec-rr (and on keyreferral, which was not on the agenda itself, but which is a related draft). Explanation of the motivation for these drafts, and then statement that perhaps the problems they were addressing weren't such great problems as had originally been thought. The author who spoke to them suggested that these drafts be left to stew while more experience with dnssec is gained. The kitchen-sink rr - an idea which has been percolating for a while now. Intended as a place in which those who desire a new rr, but don't want to standardise it (perhaps who cannot get an RR type code from IANA, because they won't reveal the details of the internals of the RR). That is, this is suggested as an alternate to the use of TXT records as a place to put junk, but with a bit more structure that should make it safer to use. There should be a new draft of this within about a month, after which it will be considered for advancement as an Experimental RFC. A new draft on the apl-rr has been published, has accounted for earlier concerns, no new issues have been raised - this one considered ready for WG last call, whether it is ready to be advanced as a PS RFC. Discussions on the DDDD draft (deferred delete). Another idea which keeps coming back, over and over again. General agreement that there's the essence of a problem here that there should be a way found to solve. General agreement that this draft is not the way - considered to be much too complex, especially in dealing with all kinds of failure cases that don't really matter anyway. Overall consensus to avoid further work on this draft. Then the verify and local-compression drafts. These largely are alternatives, both attempt to solve the basic problem of dealing with compressed names in RR types which are unknown to the server processing them. local-compression deals with that by not requiring the server to know thee's a name there (unless it is the end user of the RR, in which case it had better understand the type). Verify deals with it by requiring that all RR types (except a list of known existing ones, whose characteristics are assumed known to all servers) explicitly declare where any embedded names can be found. There was no enthusiasm in the meeting for proceeding any further with verify. local-compression seems to be ready for WG last call for PS. But it was also asked whether we really need to allow compression in the RDATA field of any RRs at all, other than NS records (and particularly for the root domain). Would anyone suffer much if all compression was prohibited. No-one could think of any cases where anything much would be lost. The A6 record was the one suggestion where it might matter, but it was also considered that compression (of any kind) might not often save much there - being able to negotiate bigger payloads was a much more important issue. Some discussion on local-names. Author says that the draft contains two distinct issues, the first of which is just a "how to" (of I understood that correctly), and is relatively non-controversial. The second (which includes creating a "local" TLD - which to be effective needs to actually be implemented in the root zone) is more so. Q: is there any demand for this draft at all? Author reported some contacts indicating that it was already in use. Author suggests BCP as preferred target. A new draft will appear, after which the WG will discuss this draft again. Comments welcome any time of course. On other business: Don Eastlake suggested that a doc of IANA considerations for DNS RR's needs to be written. Bill Manning said that he had also been asked to put some effort in that direction. They will co-author a draft. No-one had looked at the dnssec-external-keys draft that recently appeared. If that is to progress anywhere, some motivation will need to be established, and then it be resubmitted as a dnsind draft (if agreed by the WG). On the question of whether there had been any consideration of the global location RR (GLOC) there was nothing but laughter. A new policy for dnsind (whatever) was announced as a trial for the next IETF meeting (the 46th, in Washington). Drafts to be considered at the dnsind (or dnsext if it exists then) will be required to be submitted at least 2 weeks before the ietf secretariat's draft deadline. Any that miss this earlier deadline will be considered in the meeting only if time permits - discussion of other drafts will not be squeezed to make time for them. This will be reviewed at/after the Washington meeting for future meetings. The meeting actually managed to end on time, or even a couple of minutes early. That's why the "brief discussion" phrase occurs so much, many of the "discussions" truly were brief. kre From owner-dns-security@lists.tislabs.com Tue Jul 13 09:14:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12009 for ; Tue, 13 Jul 1999 09:14:57 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01347 Tue, 13 Jul 1999 08:31:25 -0400 (EDT) Date: Mon, 12 Jul 99 22:54:54 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Robert Elz Cc: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: Brief summary of Oslo DNSIND/DNSSEC meeting In-Reply-To: Your message of Mon, 12 Jul 1999 19:53:03 +0200 Message-ID: Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > > What ought be done with 2052bis was discussed. General opinion favoured > continuing to push it as PS. A long list of IESG requested changes were > discussed (these to appear on the list soon). Aside from a bunch of > trivial changes, the two of most substance concerned the definition of > the weight field, and its processing - the suggested wording for that will > still need some more work (either rephrasing, or a complete new method) > but was generally considered acceptable. The other concerned the examples. > There was much feeling that giving examples using protocols that don't > use SRV records was not a good idea (and that the examples/test that relate > to SMTP was particularly bad). What to replace them with wasn't > as obvious. There were two basic suggestions - either use some of the > protocols/usages that are now being created (there are a few in drafts > scattered about, I will probably find some of them for the next, longer, > message on 2052bis, but please, everyone, send pointers if you know them). > Or, create a fictitious protocol, the foobar protocol, or something, and > use that for the examples. I detected no consensus on which is the best > approach. As was mentioned during the WG there is a significant chicken and egg scenario in this process. One of the most interesting aspects of the IESG complaint is that the examples complaint is being leveled against a draft which is meant to replace an existing Experimental RFC that has used similar examples for quite some time. When I look at the SRV RR records and this draft I see it as a way of accomplishing two goals which are now achieved by dubious methods: (1) SRV RR records allow a host administrator to implement a distributed getservbyname() which facilitates new services on their networks without: (a) requiring their users to add new configuration information to their etc/services (or equivalent) file. This is especially important on certain PC operating systems that do not provide complete nor up to date copies of http://www.isi.edu/in-notes/iana/assignments/port-numbers (b) hard coding service name to port number assignments into applications in case the entry is not in the etc/services file (2) SRV RR records allow a host adminstrator to redirect a service for a domain of machines to a particular subset of those hosts. This is of particular use in University lab environments where it is desired to not have remote telnet or ssh users logging into all of the publicly accessed machines. In many cases a small number of higher power servers in the lab are the ones which the adminstrators desire the remote traffic to be handled whereas the smaller systems are dedicated to console use. A set of _telnet._tcp.domain IN SRV records for each of the desired servers does accomplish this purpose quite cleanly without requiring hacks like a CNAME telnet.domain which may map to multiple machines but does not provide a mechanism for distributing the connections based upon capacity. A third purpose (which I can appreciate the IESGs desire to avoid) is also possible with SRV RR records. A SRV RR records allows a host adminstrator to redirect "clients that know" away from the IANA allocated port to an alternate locally used port number. This is being considered for use at Columbia University to avoid the following problem: We wish to have all students using a Kerberos aware Telnet client "kermit" connect to a port that only allows Kerberos authenticated connections. Eventually we will require authenticated connections but we have a problem with an installed based of telnet clients that break when offered a Telnet Option number great than 36. It is not possible for political and technical reasons to replace the broken telnet clients. Therefore, we cannot replace the standard OS telnetd on port 23. In order to support Kerberos authenticated logins we must install the new telnetd on another port number (999). By adding SRV RR records for _telnet._tcp. to our DNS we are able to redirect the Kerberos telnet clients to the correct ports without breaking applications that are ignorant of them. This flexibility is extremely important. I don't think it is appropriate for the IESG to come out and say that SRV RR records MUST only be used with protocols that specify their use. I think an alternate writing should be true SRV RR records should be described as an alternative to getservbyname() which allows important infrastructure information to be distributed by host administrators to clients. Does this open the getservbyname() function to a DNS spoofing attack? Yes. But this attack is no more dangerous than the spoofing of a CNAME or A record. If the IESG is serious about insisting that SRV RR's not be used with common services for which they are approriate with there being a specific RFC that declares that they should be used I would recommend that this working group solicit Internet-Drafts from the appropriate groups to ensure their submission to IESG simultaneous to the re-submission of this draft. If the group decides to follow this direction I will take responsibility for putting my name on a Telnet SRV RR draft. > > On other business: Don Eastlake suggested that a doc of IANA considerations > for DNS RR's needs to be written. Bill Manning said that he had also been > asked to put some effort in that direction. They will co-author a draft. This is extremely important. In the TELNET arena the lack of an IANA considerations document has resulted in IANA giving out Telnet Option numbers to non-IETF participants at an alarming rate. It is especially alarming considering that most people think that Telnet development has ceased. Instead it has gone underground with most Telnet implementors designing things that the IESG would choke on. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org From owner-dns-security@lists.tislabs.com Tue Jul 13 12:13:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13589 for ; Tue, 13 Jul 1999 12:13:21 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01903 Tue, 13 Jul 1999 11:29:02 -0400 (EDT) Message-Id: <199907131529.LAA26964@all-night-tool.mit.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: dns-security@lists.tislabs.com Cc: ahmeds@mit.edu Subject: DNSSEC backward compatibility Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 11:29:06 EDT From: Sarah Ahmed Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Hi, Is TIS/DNSSEC backward compatible with non-security aware name-servers? If it is, then how does a security aware resolver know whether the name-server it contacts is security aware or not and vice-versa ( i.e. how does a security aware server know whether the client it is being queried by is security aware or not? ) What is the difference in the format of the request or response to/from a security-aware client/server and a non-security aware one? ------------------------------------------------------------------------- Sarah Ahmed Ph# (617)-225-8607 Mass Inst of Tech email : ahmeds@mit.edu Rm#527 , McCormick Hall 320 Memorial Drive Cambridge , MA - 02139 From owner-dns-security@lists.tislabs.com Tue Jul 13 12:21:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13643 for ; Tue, 13 Jul 1999 12:21:43 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01919 Tue, 13 Jul 1999 11:30:34 -0400 (EDT) Message-Id: <4.2.0.56.19990713170947.00be5c00@dokka.maxware.no> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Tue, 13 Jul 1999 17:17:25 +0200 To: jaltman@columbia.edu, Robert Elz From: Harald Alvestrand Subject: Re: Brief summary of Oslo DNSIND/DNSSEC meeting Cc: namedroppers@internic.net, dns-security@lists.tislabs.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dns-security@lists.tislabs.com Precedence: bulk At 22:54 12.07.99 -0400, Jeffrey Altman wrote: >A third purpose (which I can appreciate the IESGs desire to avoid) is >also possible with SRV RR records. A SRV RR records allows a host >adminstrator to redirect "clients that know" away from the IANA >allocated port to an alternate locally used port number. This is >being considered for use at Columbia University to avoid the following >problem: > > We wish to have all students using a Kerberos aware Telnet client > "kermit" connect to a port that only allows Kerberos authenticated > connections. Eventually we will require authenticated connections > but we have a problem with an installed based of telnet clients > that break when offered a Telnet Option number great than 36. It > is not possible for political and technical reasons to replace > the broken telnet clients. Therefore, we cannot replace the > standard OS telnetd on port 23. In order to support Kerberos > authenticated logins we must install the new telnetd on another > port number (999). By adding SRV RR records for _telnet._tcp. > to our DNS we are able to redirect the Kerberos telnet clients > to the correct ports without breaking applications that are > ignorant of them. > >This flexibility is extremely important. I don't think it is >appropriate for the IESG to come out and say that SRV RR records MUST >only be used with protocols that specify their use. This is, as you say, quite useful but architecturally unsound. It is one example of selecting the service to offer based on the capabilities of the client; you get to use this trick once - if anything occurs that means you need to split either the new or the old groups of clients again, you can't use SRV, because you've already used it up. It's reasonably architecturally sound to reconfigure the old (or new) telnet clients to point to the two hosts broken-telnetd.columbia.edu and fixed-telnetd.columbia.edu instead; you can scale this to any number of broken clients. the two things can be different IP addresses on the same host, if you want them to be, or one can be a relay; old clients are usually not in a desperate hurry. Disclaimer: I'm not terribly convinced that the total ban on SRV with stuff that doesn't tell you how to use it is very important in all cases - but in this particular case, the example doesn't "smell right" to me. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-dns-security@lists.tislabs.com Tue Jul 13 16:02:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15412 for ; Tue, 13 Jul 1999 16:02:03 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02478 Tue, 13 Jul 1999 15:18:34 -0400 (EDT) X-Authentication-Warning: spiral.gw.tislabs.com: bwelling owned process doing -bs Date: Tue, 13 Jul 1999 15:18:28 -0400 (EDT) From: Brian Wellington X-Sender: bwelling@spiral.gw.tislabs.com To: Sarah Ahmed cc: dns-security@lists.tislabs.com Subject: Re: DNSSEC backward compatibility In-Reply-To: <199907131529.LAA26964@all-night-tool.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@lists.tislabs.com Precedence: bulk On Tue, 13 Jul 1999, Sarah Ahmed wrote: > Is TIS/DNSSEC backward compatible with non-security aware name-servers? If it > is, then how does a security aware resolver know whether the name-server it > contacts is security aware or not and vice-versa ( i.e. how does a security > aware server know whether the client it is being queried by is security aware > or not? ) What is the difference in the format of the request or response > to/from a security-aware client/server and a non-security aware one? TIS/DNSSEC is not supported anymore. DNSSEC is currently being incorporated into BIND - BIND 8.2.1 contains a subset of DNSSEC, and BIND 9 will include a full implementation. A security-aware resolver may trust its local nameserver, in which case it would issue a query that looks identical to a non-security-aware resolver's query. It would, though, expect the AD (authenticated data) bit set in the response. Transaction security should be used in this case to prevent malicious tampering over the local link. A security-aware resolver may also issue a query with the CD (checking disabled) bit set, which would instrust the local name server to forgo any authentication checks. The resolver would then perform the security checks itself. A security-aware server will always include SIG records corresponding to each resource record set returned, and may return KEY records in the additional section if there is room in the packet. NXT records will be returned to signify nonexistent records (this is not implemented in BIND 8.x). The AD bit will be set if all answers can be verified. Brian From owner-dns-security@lists.tislabs.com Wed Jul 14 05:58:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02637 for ; Wed, 14 Jul 1999 05:58:43 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05096 Wed, 14 Jul 1999 05:10:12 -0400 (EDT) X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <199907131529.LAA26964@all-night-tool.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Jul 1999 05:13:03 -0400 To: "Sarah Ahmed" From: Edward Lewis Subject: Re: DNSSEC backward compatibility Cc: , ahmeds@mit.edu Sender: owner-dns-security@lists.tislabs.com Precedence: bulk The answer is yes - DNSSEC is backwards compatible with non-DNSSEC servers. Brian's comments are right about BIND versions - use the latest BIND. The critical operation to backwards compatibility is whether a secure resolver get secured data from a remote secured zone via an unsecured recursive server. The answer is yes. The reason is that the recursive (and cacheing) server may only return unsigned data on the first query - the secured resolver can ask for SIG records on a second try. The unsecured resolver would pass SIG records as an opaque type - it wouldn't (if this is an older BIND) cache them. At 11:29 AM -0400 7/13/99, Sarah Ahmed wrote: >Hi, > >Is TIS/DNSSEC backward compatible with non-security aware name-servers? If it >is, then how does a security aware resolver know whether the name-server it >contacts is security aware or not and vice-versa ( i.e. how does a security >aware server know whether the client it is being queried by is security aware >or not? ) What is the difference in the format of the request or response >to/from a security-aware client/server and a non-security aware one? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From owner-dns-security@lists.tislabs.com Wed Jul 14 09:46:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09192 for ; Wed, 14 Jul 1999 09:46:05 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06309 Wed, 14 Jul 1999 09:08:37 -0400 (EDT) Message-Id: <378C8BB7.C3B44F98@athena.polito.it> Date: Wed, 14 Jul 1999 15:08:07 +0200 From: Marius Marian X-Mailer: Mozilla 4.06 [en] (WinNT; U) Mime-Version: 1.0 To: "dns-security@lists.tislabs.com" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody, Could someone tell from which version are supported the KEY, SIG and NXT RRs in BIND. Also, is it actually an existing TSIG RR used by the resolver and nameserver in the TIS - DNSSEC implementation. If so how could it be set? Will it be kept in the future releases of BIND? Another question I have is how will be managed the root servers keys and what will be a presumable safe period of life for keys. And finally are there any links to documentation regarding DNSSEC except the RFCs - since I'm a neophyte in the DNSSEC field :-) Thanks in advance, Marius Marian. From owner-dns-security@lists.tislabs.com Wed Jul 14 12:23:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11977 for ; Wed, 14 Jul 1999 12:23:48 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07124 Wed, 14 Jul 1999 11:32:03 -0400 (EDT) X-Authentication-Warning: spiral.gw.tislabs.com: bwelling owned process doing -bs Date: Wed, 14 Jul 1999 11:32:19 -0400 (EDT) From: Brian Wellington X-Sender: bwelling@spiral.gw.tislabs.com To: Marius Marian cc: dns-security@lists.tislabs.com Subject: Re: (no subject) In-Reply-To: <378C8BB7.C3B44F98@athena.polito.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@lists.tislabs.com Precedence: bulk On Wed, 14 Jul 1999, Marius Marian wrote: > Could someone tell from which version are supported the KEY, SIG and > NXT RRs in BIND. BIND 8.2 and above have support for KEY and SIG. No version supports NXT. These refer to the correct processing of the records, not just handling of the records. 8.2 can handle NXT records, it just doesn't return them in negative answers. > Also, is it actually an existing TSIG RR used by the > resolver and nameserver in the TIS - DNSSEC implementation. If so how > could it be set? Will it be kept in the future releases of BIND? What do you mean by "an existing TSIG RR"? TSIGs are generated on the fly by the server/resolver sending the packet. The shared secret used to generate the TSIG is stored in the server configuration file in BIND 8.2, and passed as a parameter to the res_nsendsigned() function. The earlier TIS/DNSSEC implementations did not include TSIG authentication, and should be considered obsolete. > Another question I have is how will be managed the root servers keys and > what will be a presumable safe period of life for keys. The root servers keys will be managed by some Internet governing body (ICANN or ISI). The keys will be statically configured into each server at startup time, and are expected to have a long lifetime. The lifetime of keys depends on several factors, including key strength, importance of the data, etc. I would expect to see a BCP (Best Current Practice) or similar document describing recommended key lengths on the future. > And finally are there any links to documentation regarding DNSSEC except > the RFCs - since I'm a neophyte in the DNSSEC field :-) The only documentation I know of other than RFC and Internet Drafts is a paper I wrote about 6 months ago: http://www.nai.com/nai_labs/asp_set/network_security/dns_secure_paper.asp Brian [The DNSSEC working group is being merged into the DNSIND working group. This mailing list should be considered deprecated, and namedroppers@internic.net used instead.] From owner-dns-security@lists.tislabs.com Wed Jul 14 13:32:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12940 for ; Wed, 14 Jul 1999 13:32:46 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07376 Wed, 14 Jul 1999 12:18:44 -0400 (EDT) X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: References: <378C8BB7.C3B44F98@athena.polito.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Jul 1999 12:20:05 -0400 To: Brian Wellington From: Edward Lewis Subject: Re: (no subject) Cc: Marius Marian , dns-security@lists.tislabs.com Sender: owner-dns-security@lists.tislabs.com Precedence: bulk To extend Brian's comments, I've included some claifications. At 11:32 AM -0400 7/14/99, Brian Wellington wrote: >On Wed, 14 Jul 1999, Marius Marian wrote: > >> Could someone tell from which version are supported the KEY, SIG and >> NXT RRs in BIND. > >BIND 8.2 and above have support for KEY and SIG. No version supports NXT. BIND began parsing these records in 4.9.something, but, as Brian says, KEY and SIG are "working" in 8.2 and on. >> Also, is it actually an existing TSIG RR used by the >> resolver and nameserver in the TIS - DNSSEC implementation. If so how >> could it be set? Will it be kept in the future releases of BIND? > >What do you mean by "an existing TSIG RR"? TSIGs are generated on the fly >by the server/resolver sending the packet. The shared secret used to >generate the TSIG is stored in the server configuration file in BIND 8.2, >and passed as a parameter to the res_nsendsigned() function. The earlier >TIS/DNSSEC implementations did not include TSIG authentication, and should >be considered obsolete. TSIG is a meta record, it does not appear in the cache, configuration files, or master files. >> Another question I have is how will be managed the root servers keys and >> what will be a presumable safe period of life for keys. > >The root servers keys will be managed by some Internet governing body >(ICANN or ISI). The keys will be statically configured into each server >at startup time, and are expected to have a long lifetime. The lifetime >of keys depends on several factors, including key strength, importance of >the data, etc. I would expect to see a BCP (Best Current Practice) or >similar document describing recommended key lengths on the future. Watch the work in the DNSOP WG of the IETF. The mail list for this group is dnsop@cafax.se. (Subscribe via dnsop-request@cafax.se.) >> And finally are there any links to documentation regarding DNSSEC except >> the RFCs - since I'm a neophyte in the DNSSEC field :-) Try http://www.nic-se.se/dnssec/. This has a series of presentations on the signer code written for a workshop held in Sweden two months ago. >[The DNSSEC working group is being merged into the DNSIND working group. >This mailing list should be considered deprecated, and >namedroppers@internic.net used instead.] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. [The DNSSEC working group is being merged into the DNSIND working group. This mailing list should be considered deprecated, and namedroppers@internic.net used instead.] From owner-dns-security@lists.tislabs.com Wed Jul 14 15:35:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14239 for ; Wed, 14 Jul 1999 15:35:17 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07819 Wed, 14 Jul 1999 14:49:45 -0400 (EDT) Message-Id: <199907141849.LAA00523@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Edward Lewis cc: Brian Wellington , Marius Marian , dns-security@lists.tislabs.com, gnu@toad.com Subject: Re: (no subject) In-reply-to: Date: Wed, 14 Jul 1999 11:49:36 -0700 From: John Gilmore Sender: owner-dns-security@lists.tislabs.com Precedence: bulk >> Could someone tell from which version are supported the KEY, SIG and >> NXT RRs in BIND. > BIND began parsing these records in 4.9.something, but, as Brian says, KEY To: dnssec-interest, gnu Subject: New production BIND release (4.9.5-REL) Date: Tue, 12 Nov 1996 17:08:03 -0800 From: John Gilmore 4.9.5 is the first production release of BIND to include support for the KEY and SIG records needed for Secure DNS. It also includes numerous bug-fixes, as well as some other features like LOC records (geographical location), better IPv6 support, SOA parameter diagnosis, and domain name character-set checking. It is now running on one of the root servers (d.root-servers.net). Please upgrade to it as soon as you can. The Web page at http://www.isc.org/isc/bind.html hasn't yet been updated; it incorrectly points its "latest release" link at 4.9.4. 4.9.5 was released on Monday, and is available right next to 4.9.4, in: ftp://ftp.vix.com/pub/bind/release/ John Gilmore Electronic Frontier Foundation [The DNSSEC working group is being merged into the DNSIND working group. This mailing list should be considered deprecated, and namedroppers@internic.net used instead.]