From owner-dns-security Wed Apr 23 13:53:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09222 for dns-security-outgoing; Wed, 23 Apr 1997 13:48:12 -0400 (EDT) Message-Id: <3.0.1.32.19970423134428.0069eafc@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 23 Apr 1997 13:44:28 -0400 To: Robert Elz From: Olafur Gudmundsson Subject: Re: Year 2000 problems in the DNS Cc: Olafur Gudmundsson , Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com In-Reply-To: <15644.861802532@munnari.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 11:35 PM 4/23/97 +1000, Robert Elz wrote: > Date: Tue, 22 Apr 1997 12:46:02 -0400 > From: Olafur Gudmundsson > Message-ID: <3.0.1.32.19970422124602.0070ef08@pop.hq.tis.com> > > This is not strictly a year 2000 problem it is a year 2038 or year 2106 > problem > >Yes, and while technically we could ignore that for present purposes, >I don't think we should, otherwise in 35 years some other sucker will be >doing all of this all over again. > > depending on wheither the time is treated as signed or unsigned value. > >Which is it? I assume it is defined in the dnssec docs? > >kre RFC2065 page 19 first line: The "time signed" field is and unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. Yes we have a 2106 problem, should we fix it now or can we specify that serial number arithmetic will save use, as specified later. My preference is to fix it now, If we change this from seconds to minutes we postpone the problem to roughly 10130 AD. If we change to 64 bit value we are covered. This will increase the size of each signature by 8 bytes to each SIG record which is not a big deal, compared to the size of the overall SIG record. Olafur From owner-dns-security Wed Apr 23 14:45:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09659 for dns-security-outgoing; Wed, 23 Apr 1997 14:45:39 -0400 (EDT) Message-Id: <199704231851.LAA06396@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Wed, 23 Apr 97 11:51:08 -0700 To: Olafur Gudmundsson Subject: Re: Year 2000 problems in the DNS cc: Robert Elz , Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <3.0.1.32.19970423134428.0069eafc@pop.hq.tis.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk > Yes we have a 2106 problem, should we fix it now or can we specify > that serial number arithmetic will save use, as specified > later. > > My preference is to fix it now, If we change this from seconds to > minutes we postpone the problem to roughly 10130 AD. If we > change to 64 bit value we are covered. This will increase the > size of each signature by 8 bytes to each SIG record which is not a > big deal, compared to the size of the overall SIG record. > On the other hand, is it worth the effort? We're talking a lifetime of over 100 years. Will DNS we a viable tool in 2106? Will the Internet exist in 2106? It is unlikely any of us will be around in 2106, more or less care. -dpg From owner-dns-security Wed Apr 23 15:41:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10180 for dns-security-outgoing; Wed, 23 Apr 1997 15:41:13 -0400 (EDT) Date: Wed, 23 Apr 1997 14:47:01 -0500 Message-Id: <199704231947.OAA16640@hosaka> From: Jim Thompson To: ogud@tis.com CC: kre@munnari.oz.au, ogud@tis.com, Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com In-reply-to: <3.0.1.32.19970423134428.0069eafc@pop.hq.tis.com> (message from Olafur Gudmundsson on Wed, 23 Apr 1997 13:44:28 -0400) Subject: Re: Year 2000 problems in the DNS Sender: owner-dns-security@ex.tis.com Precedence: bulk You have to be kidding. The DNS won't be in-use in 2106. -- Jim Thompson / Smallworks, Inc. / jim@smallworks.com 512 338 0619 phone / 512 338 0625 fax HTML: The 3270 of the 90s From owner-dns-security Wed Apr 23 19:21:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11605 for dns-security-outgoing; Wed, 23 Apr 1997 19:20:52 -0400 (EDT) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA90365CD3F@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Jim Thompson , ogud@tis.com Cc: kre@munnari.oz.au, ogud@tis.com, Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com Subject: RE: Year 2000 problems in the DNS Date: Wed, 23 Apr 1997 15:08:38 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.14) Sender: owner-dns-security@ex.tis.com Precedence: bulk Seems like I've heard (and made!) this argument before - 10, 15 years ago, I didn't believe that the application I was working on would still be in production today. Guess again! -----Original Message----- From: Jim Thompson [SMTP:jim@hosaka.SmallWorks.COM] Sent: Wednesday, April 23, 1997 12:47 PM To: ogud@TIS.COM Cc: kre@MUNNARI.OZ.AU; ogud@TIS.COM; Mark.Andrews@cmis.csiro.au; namedroppers@internic.net; dns-security@TIS.COM Subject: Re: Year 2000 problems in the DNS You have to be kidding. The DNS won't be in-use in 2106. -- Jim Thompson / Smallworks, Inc. / jim@smallworks.com 512 338 0619 phone / 512 338 0625 fax HTML: The 3270 of the 90s From owner-dns-security Thu Apr 24 07:21:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15225 for dns-security-outgoing; Thu, 24 Apr 1997 07:18:54 -0400 (EDT) Date: Thu, 24 Apr 1997 07:18:54 -0400 (EDT) Message-Id: <199704241118.HAA15225@portal.ex.tis.com> From: Don Bonaddio To: Glen Zorn cc: kre@munnari.oz.au, ogud@tis.com, Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com, Jim Thompson , ogud@tis.com Subject: Re: RE: Year 2000 problems in the DNS <61CDD2C9A961CF11B6A000805FD40AA90365CD3F@RED-84-MSG.dns.microsoft.com> Message-ID: Date: Wed, 23 Apr 1997 20:30:54 -0400 (Eastern Daylight Time) X-Mailer: Simeon for Win32 Version 4.1 X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk Well, ya know, in 2038 we'll need to be using 64-bit OS's. Since the date is stored as the number of seconds since 00:00:00, January 1, 1970, the total number of seconds that can be stored in a signed 32-bit integer is 214,748,364 which means the last day for the 32-bit OS January 19, 2038 (Of course, this will be probably be the least of my problems in 41 years :-) db On Wed, 23 Apr 1997 15:08:38 -0700 Glen Zorn wrote: | Seems like I've heard (and made!) this argument before - 10, 15 years | ago, I didn't believe that the application I was working on would still | be in production today. Guess again! | -----Original Message----- | From: Jim Thompson [SMTP:jim@hosaka.SmallWorks.COM] | Sent: Wednesday, April 23, 1997 12:47 PM | To: ogud@TIS.COM | Cc: kre@MUNNARI.OZ.AU; ogud@TIS.COM; | Mark.Andrews@cmis.csiro.au; namedroppers@internic.net; | dns-security@TIS.COM | Subject: Re: Year 2000 problems in the DNS | | | You have to be kidding. The DNS won't be in-use in 2106. | | -- | Jim Thompson / Smallworks, Inc. / jim@smallworks.com | 512 338 0619 phone / 512 338 0625 fax | HTML: The 3270 of the 90s ---------------------- From owner-dns-security Thu Apr 24 07:21:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15231 for dns-security-outgoing; Thu, 24 Apr 1997 07:19:55 -0400 (EDT) Message-Id: <199704241119.HAA15231@portal.ex.tis.com> From: "John S. Quarterman" To: Glen Zorn Cc: "John S. Quarterman" cc: Jim Thompson , ogud@tis.com, kre@munnari.oz.au, Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com Subject: Re: Year 2000 problems in the DNS Date: Wed, 23 Apr 1997 20:30:42 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk >Seems like I've heard (and made!) this argument before - 10, 15 years >ago, I didn't believe that the application I was working on would still >be in production today. Guess again! Yes, isn't this exactly the source of the year 2000 problem? > -----Original Message----- > From: Jim Thompson [SMTP:jim@hosaka.SmallWorks.COM] > Sent: Wednesday, April 23, 1997 12:47 PM > To: ogud@TIS.COM > Cc: kre@MUNNARI.OZ.AU; ogud@TIS.COM; >Mark.Andrews@cmis.csiro.au; namedroppers@internic.net; >dns-security@TIS.COM > Subject: Re: Year 2000 problems in the DNS > > > You have to be kidding. The DNS won't be in-use in 2106. > > -- > Jim Thompson / Smallworks, Inc. / jim@smallworks.com > 512 338 0619 phone / 512 338 0625 fax > HTML: The 3270 of the 90s From owner-dns-security Thu Apr 24 07:23:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15297 for dns-security-outgoing; Thu, 24 Apr 1997 07:22:26 -0400 (EDT) Message-Id: <199704241122.HAA15297@portal.ex.tis.com> Date: Wed, 23 Apr 1997 20:48:26 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: Year 2000 problems in the DNS To: dennis.glatting@plaintalk.bellevue.wa.us cc: Olafur Gudmundsson , Robert Elz , Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com In-Reply-To: "Your message with ID" <199704231851.LAA06396@imo.plaintalk.bellevue.wa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk > > > Yes we have a 2106 problem, should we fix it now or can we specify > > that serial number arithmetic will save use, as specified > > later. > > > > My preference is to fix it now, If we change this from seconds to > > minutes we postpone the problem to roughly 10130 AD. If we > > change to 64 bit value we are covered. This will increase the > > size of each signature by 8 bytes to each SIG record which is not a > > big deal, compared to the size of the overall SIG record. > > > > On the other hand, is it worth the effort? We're talking a > lifetime of over 100 years. Will DNS we a viable tool in 2106? > Will the Internet exist in 2106? It is unlikely any of us will be > around in 2106, more or less care. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I hope that geriatrics advance to the point that that you'll be alive in 2106 to answer for this. half :-) As for the survival of specifications past 100 years, the Arabic numbering system is a good counter example. I believe that the distance between rails of North American trans continental freight trains has been the same for over 100 years. For something higher tech, I'll bet that AM radio sees its 100th birthday, and NTSC too. -mre From owner-dns-security Thu Apr 24 08:16:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA15713 for dns-security-outgoing; Thu, 24 Apr 1997 08:15:03 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199704241118.HAA15225@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Apr 1997 08:09:37 -0400 To: namedroppers@internic.net, dns-security@tis.com From: Edward Lewis Subject: Re: RE: Year 2000 problems in the DNS Cc: glennz@microsoft.com, kre@munnari.oz.au, ogud@tis.com, Mark.Andrews@cmis.csiro.au, donbon@hq.nasa.gov Sender: owner-dns-security@ex.tis.com Precedence: bulk At 7:18 AM -0400 4/24/97, Don Bonaddio wrote: >Well, ya know, in 2038 we'll need to be using 64-bit OS's. Ok, back to the year "2000" problem - another potential problem (in 2038) is the use of the seconds since '70 as a sequence number. Coding as yyyymmdd### (eg 19970424001, 19970424002,...) limits updates to 1000/day but extends the encoding to the year 10000. One thousand updates a day may be a bottleneck with the advent of dynamic update. I don't think it would be wise to enlarge the sequence number field ;) - that would break everything at once. Is the sequence number roll-over serious enough to worry about in practice, or would it just need a zone by zone flag day to correct? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Thu Apr 24 08:34:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA15920 for dns-security-outgoing; Thu, 24 Apr 1997 08:33:08 -0400 (EDT) Date: Thu, 24 Apr 1997 08:38:01 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704241238.IAA27132@argon.ncsc.mil> To: dns-security@tis.com Subject: Re: Year 2000 problems in the DNS X-Sun-Charset: US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk > From: Mike Eisler > > As for the survival of specifications past 100 years, the Arabic numbering > system is a good counter example. I believe that the distance between rails of > North American trans continental freight trains has been the same for over 100 > years. For something higher tech, I'll bet that AM radio sees its 100th > birthday, and NTSC too. > > -mre You might lose money on the NTSC bet - it is to be phased out by ~2006? Anyone who wants to use NTSC user agents (TVs :-) after that date will need an external converter. From owner-dns-security Thu Apr 24 10:10:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16523 for dns-security-outgoing; Thu, 24 Apr 1997 10:08:48 -0400 (EDT) From: owner-dns-security@ex.tis.com Message-Id: <199704241354.JAA27567@scfn.thpl.lib.fl.us> Subject: Re: Year 2000 problems in the DNS To: jim@hosaka.smallworks.com (Jim Thompson) Date: Thu, 24 Apr 1997 09:54:27 -0400 (EDT) Cc: ogud@tis.com, kre@munnari.oz.au, Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com In-Reply-To: <199704231947.OAA16640@hosaka> from "Jim Thompson" at Apr 23, 97 02:47:01 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk You wrote: > You have to be kidding. The DNS won't be in-use in 2106. Gee... we're trolling on _mailing lists_, now? I didn't realize it had been transplanted from Usenet, as a discipline... Cheers, -- jra -- Jay R. Ashworth jra@scfn.thpl.lib.fl.us Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "To really blow up an investment house requires Tampa Bay, Florida a human being." - Mark Stalzer +1 813 790 7592 From owner-dns-security Thu Apr 24 10:57:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16877 for dns-security-outgoing; Thu, 24 Apr 1997 10:56:08 -0400 (EDT) Date: Thu, 24 Apr 1997 10:57:22 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: "David P. Kemp" Cc: dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-Reply-To: <199704241238.IAA27132@argon.ncsc.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk This isn't very relevant to dnssec but I'm convinced that the ever accumulating number of desired improvements in DNS will lead to a DNS-2 in less than 100 years. (If not, I do not believe there is ever a reason to have a certificate that lasts for even 10 years, let alone over a 100, and following the dnssec guidlines of changing keys ever 5 years, at max, there is never a problem. In the unlikely event that DNS was still in use in 2106 or whatever with the current formats, you just wrap around and keep wrapping arond. Old certs that might become "valid" again due to date ambiguity would fail due to key changes.) So I don't think there is any reason to change the current scheme because I think a major DNS change will occur first and if not the current scheme will work. And if it were changing, I'm strongly opposed to some kludge ascii variable length thing. The first place I'd look for a new time format (if it were needed) would be NTP. Donald On Thu, 24 Apr 1997, David P. Kemp wrote: > Date: Thu, 24 Apr 1997 08:38:01 -0400 > From: David P. Kemp > To: dns-security@tis.com > Subject: Re: Year 2000 problems in the DNS > > > From: Mike Eisler > > > > As for the survival of specifications past 100 years, the Arabic numbering > > system is a good counter example. I believe that the distance between rails of > > North American trans continental freight trains has been the same for over 100 > > years. For something higher tech, I'll bet that AM radio sees its 100th > > birthday, and NTSC too. > > > > -mre > > > You might lose money on the NTSC bet - it is to be phased out by > ~2006? Anyone who wants to use NTSC user agents (TVs :-) after that > date will need an external converter. > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Thu Apr 24 11:34:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17168 for dns-security-outgoing; Thu, 24 Apr 1997 11:33:24 -0400 (EDT) Message-Id: <199704241434.JAA21636@akasha.tic.com> From: "John S. Quarterman" To: Mike Eisler Cc: "John S. Quarterman" cc: dennis.glatting@plaintalk.bellevue.wa.us, Olafur Gudmundsson , Robert Elz , Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-reply-to: Your message of "Wed, 23 Apr 1997 20:48:26 PDT." Date: Thu, 24 Apr 1997 09:34:46 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk >> >> > Yes we have a 2106 problem, should we fix it now or can we specify >> > that serial number arithmetic will save use, as specified >> > later. >> > >> > My preference is to fix it now, If we change this from seconds to >> > minutes we postpone the problem to roughly 10130 AD. If we >> > change to 64 bit value we are covered. This will increase the >> > size of each signature by 8 bytes to each SIG record which is not a >> > big deal, compared to the size of the overall SIG record. >> > >> >> On the other hand, is it worth the effort? We're talking a >> lifetime of over 100 years. Will DNS we a viable tool in 2106? >> Will the Internet exist in 2106? It is unlikely any of us will be >> around in 2106, more or less care. >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I hope that geriatrics advance to the point that that you'll be alive in 2106 >to answer for this. half :-) > >As for the survival of specifications past 100 years, the Arabic numbering >system is a good counter example. I believe that the distance between rails of >North American trans continental freight trains has been the same for over 100 >years. For something higher tech, I'll bet that AM radio sees its 100th >birthday, and NTSC too. Rail spacing goes back a lot farther than that. I'm not sure where the message forwarded below was originally posted, but the truth of the history in it has been attested by numerous independent parties. Perhaps now we can get back to fixing the problem. ---------- Forwarded message ---------- Subject: US Standard Railroad Gauge or How MilSpecs Live Forever From: Bill Innanen US Standard Railroad Gauge or How MilSpecs Live Forever - -------------------------- The US standard railroad gauge (distance between the rails) is 4 ft 8 1/2 in (1.44 m). That's an exceedingly odd number. Why is that gauge used? Because that's the way they built them in England, and the US railroads were built by English ex patriots. Why did the English build 'em like that? Because the first rail lines were built by the same people who built the pre-railroad tramways, and that's the gauge they used. Why did *they* use that gauge then? Because the people who built the tramways used the same jigs and tools as they used for building wagons, which used that wheel spacing. OK! Why did the wagons use that wheel spacing? Well, if they tried to use any other spacing the wagons would break on some of the old, long distance roads, because that's the spacing of the ruts. So who built these old rutted roads? The first long distance roads in Europe were built by Imperial Rome for the benefit of their legions. The roads have been used ever since. And the ruts? The initial ruts, which everyone else had to match for fear of breaking their wagons, were first made by Roman war chariots. Since the chariots were made by or for Imperial Rome they were all alike in the matter of wheel spacing (ruts again). Thus we have the answer to the original question. The United States standard railroad gauge of 4 ft 8 1/2 in derives from the original military specification (MilSpec) for an Imperial Roman army war chariot. MisSpecs (and bureaucracies) live forever! ----- End Forwarded Message ----- From owner-dns-security Thu Apr 24 12:20:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17436 for dns-security-outgoing; Thu, 24 Apr 1997 12:18:48 -0400 (EDT) Date: Thu, 24 Apr 1997 11:24:29 -0500 From: jim@hosaka.smallworks.com (Jim Thompson) Message-Id: <199704241624.LAA19713@hosaka> To: glennz@microsoft.com, jsq@mids.org Subject: Re: Year 2000 problems in the DNS Cc: Mark.Andrews@cmis.csiro.au, dns-security%tis.com.jsq@mids.org, kre@munnari.oz.au, namedroppers@internic.net, ogud@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk >> Seems like I've heard (and made!) this argument before - 10, 15 years >> ago, I didn't believe that the application I was working on would still >> be in production today. Guess again! > > Yes, isn't this exactly the source of the year 2000 problem? Look. IP is what, 14-15 years 'old' now? And its got to be replaced (by IPv6) soon, anyway, right? We're out of addresses, and carrying the routing has become burdonsome. You've heard it all before. DNS, in its current form, can't survive another 110 years of growth. Very likely that none of us (if we're alive) will even understand what the net will have become by then. Even if the growth slows down to doubling every 10 years. (DNS, as currently engineered won't scale to that size either.) Jim From owner-dns-security Thu Apr 24 13:15:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17776 for dns-security-outgoing; Thu, 24 Apr 1997 13:14:35 -0400 (EDT) To: Edward Lewis Cc: dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-Reply-To: Your message of "Thu, 24 Apr 1997 08:09:37 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Apr 1997 03:20:24 +1000 Message-Id: <16780.861902424@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Thu, 24 Apr 1997 08:09:37 -0400 From: Edward Lewis Message-ID: Ok, back to the year "2000" problem - another potential problem (in 2038) is the use of the seconds since '70 as a sequence number. I didn't send my original message to the dnssec mailing list, but in that I indicated that serial number problems were already understood (such as they are) and I didn't need to be told about those. In any case, you can't do yyyymmddXXX - that's too many digits, only 2 X's will fit, which would be just 100 updates (or the serial number) a day. If thatscheme was to be adopted. But it's not needed. kre From owner-dns-security Thu Apr 24 13:23:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17837 for dns-security-outgoing; Thu, 24 Apr 1997 13:23:15 -0400 (EDT) To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-Reply-To: Your message of "Thu, 24 Apr 1997 10:57:22 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Apr 1997 03:27:31 +1000 Message-Id: <16792.861902851@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Thu, 24 Apr 1997 10:57:22 -0400 (EDT) From: "Donald E. Eastlake 3rd" Message-ID: This isn't very relevant to dnssec but I'm convinced that the ever accumulating number of desired improvements in DNS will lead to a DNS-2 in less than 100 years. I wouldn't be at all surprised, but I would much prefer that current designs not be based upon such an assumption, that is what leads to problems later when the expected revolution turns into a series of small evolutionary steps, all designed to keep the status quo working, leading to the data you expected to be long buried still being in viable use for MUCH longer than you expect now. As others have said, this is exactly what has caused the (more prevalent) year 2000 problems - 30 years ago, all those cobol programmers never imagined their code would still be in use today. But more importantly, I don't understand this at all... (If not, I do not believe there is ever a reason to have a certificate that lasts for even 10 years, let alone over a 100, and following the dnssec guidlines of changing keys ever 5 years, at max, there is never a problem. I had thought that the relevant field (from what I had heard) contained an absolute timestamp (seconds since 1970). How can the period for which the certificate is valid possibly matter? A certificate issuse in 2103, with an expiry in 5 years (as recommended for an upper limit, or whateevr) would run past 2106, would it not? If this field contains relative times, to what are they relative? So I don't think there is any reason to change the current scheme because I think a major DNS change will occur first and if not the current scheme will work. I would not assume the former (nor would I predict against it), and is the latter really true? The first place I'd look for a new time format (if it were needed) would be NTP. This, fortunately, is someone else's problem (but yes, it is going to need work). kre From owner-dns-security Thu Apr 24 13:26:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17891 for dns-security-outgoing; Thu, 24 Apr 1997 13:26:13 -0400 (EDT) To: jim@hosaka.smallworks.com (Jim Thompson) Cc: glennz@microsoft.com, jsq@mids.org, Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, ogud@tis.com, dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-Reply-To: Your message of "Thu, 24 Apr 1997 11:24:29 EST." <199704241624.LAA19713@hosaka> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Apr 1997 03:31:29 +1000 Message-Id: <16802.861903089@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Thu, 24 Apr 1997 11:24:29 -0500 From: jim@hosaka.SmallWorks.COM (Jim Thompson) Message-ID: <199704241624.LAA19713@hosaka> DNS, in its current form, can't survive another 110 years of growth. This is silly. Of course it can, and probably must. If there really is a problem we should be addressing it right now - as delaying can only make deployment of a replacement more and more difficult until that reaches towards impossible. For sure there will be evolutionary changes, and it is possible that the need for a DNS will, for some reason, simply vanish, but don't just assume this. Certainly don't assume that there will be a replacement DNS system designed and deployed, ever. kre From owner-dns-security Thu Apr 24 13:43:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA18059 for dns-security-outgoing; Thu, 24 Apr 1997 13:42:56 -0400 (EDT) Date: Thu, 24 Apr 1997 13:42:56 -0400 (EDT) Message-Id: <199704241722.NAA09536@charon.MIT.EDU> From: Derek Atkins To: Mike Eisler CC: dennis.glatting@plaintalk.bellevue.wa.us, Olafur Gudmundsson , Robert Elz , Mark.Andrews@cmis.csiro.au, namedroppers@internic.net, dns-security@tis.com In-reply-to: "[1920] in namedroppers" Subject: Re: Year 2000 problems in the DNS Sender: owner-dns-security@ex.tis.com Precedence: bulk > years. For something higher tech, I'll bet that AM radio sees its 100th > birthday, and NTSC too. Actually, NTSC is going to die by 2006. ATSC is taking over, according to a recent FCC ruling. See www.fcc.gov for more details. -derek From owner-dns-security Fri Apr 25 14:00:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26555 for dns-security-outgoing; Fri, 25 Apr 1997 13:53:51 -0400 (EDT) Date: Fri, 25 Apr 1997 13:55:15 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Robert Elz Cc: dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-Reply-To: <16792.861902851@munnari.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Though currently documented as an absolute time, I was just pointing out that it is really the number of seconds since 1 January 1970 modulo 2**32 (perhaps it could be called cyclic time). If certificates are always much shorter lived than the 100+years 2**32 seconds represents, then you can always figure out what infinte set of short time intervals the certificate could represent. As long as keys are changed with reasonable frequency, there isn't any danger that as old certificate will appear valid n*2**32 seconds alter. Donald On Fri, 25 Apr 1997, Robert Elz wrote: > Date: Fri, 25 Apr 1997 03:27:31 +1000 > From: Robert Elz > To: "Donald E. Eastlake 3rd" > Cc: dns-security@tis.com > Subject: Re: Year 2000 problems in the DNS > > Date: Thu, 24 Apr 1997 10:57:22 -0400 (EDT) > From: "Donald E. Eastlake 3rd" > Message-ID: > > This isn't very relevant to dnssec but I'm convinced that the ever > accumulating number of desired improvements in DNS will lead to a DNS-2 in > less than 100 years. > > I wouldn't be at all surprised, but I would much prefer that current > designs not be based upon such an assumption, that is what leads to problems > later when the expected revolution turns into a series of small evolutionary > steps, all designed to keep the status quo working, leading to the data > you expected to be long buried still being in viable use for MUCH longer than > you expect now. > > As others have said, this is exactly what has caused the (more prevalent) > year 2000 problems - 30 years ago, all those cobol programmers never imagined > their code would still be in use today. > > But more importantly, I don't understand this at all... > > (If not, I do not believe there is ever a reason to > have a certificate that lasts for even 10 years, let alone over a 100, and > following the dnssec guidlines of changing keys ever 5 years, at max, there > is never a problem. > > I had thought that the relevant field (from what I had heard) contained an > absolute timestamp (seconds since 1970). How can the period for which the > certificate is valid possibly matter? A certificate issuse in 2103, with > an expiry in 5 years (as recommended for an upper limit, or whateevr) would > run past 2106, would it not? > > If this field contains relative times, to what are they relative? > > So I don't think there is any reason to change the current scheme because I > think a major DNS change will occur first and if not the current scheme will > work. > > I would not assume the former (nor would I predict against it), and is the > latter really true? > > The first place I'd look for a new time format (if it > were needed) would be NTP. > > This, fortunately, is someone else's problem (but yes, it is going to > need work). > > kre > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Mon Apr 28 22:42:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14998 for dns-security-outgoing; Mon, 28 Apr 1997 22:42:07 -0400 (EDT) Date: Mon, 28 Apr 1997 10:02:19 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Robert Elz Cc: dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-Reply-To: <5447.862218651@munnari.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk All the DNSSEC RFCs will get revised in due course, actually quite soon for the one in questions (RFC 2065) and I'll make this change then. It would be absurd to try to re-issue the RFC instantly to change a couple of words when (1) it will be revised, probably within a month or so anyway, (2) the delay through the RFC Editor is at least a couple of months, (3) the problem won't appear for decades, and (4) most reasonable implementations of the spec will actualy by cyclic anyway. Donald On Mon, 28 Apr 1997, Robert Elz wrote: > Date: Mon, 28 Apr 1997 19:10:51 +1000 > From: Robert Elz > To: "Donald E. Eastlake 3rd" > Cc: dns-security@tis.com > Subject: Re: Year 2000 problems in the DNS > > Date: Fri, 25 Apr 1997 13:55:15 -0400 (EDT) > From: "Donald E. Eastlake 3rd" > Message-ID: > > Though currently documented as an absolute time, I was just pointing out > that it is really the number of seconds since 1 January 1970 modulo > 2**32 (perhaps it could be called cyclic time). > > No, if it is documented as an absolute time, then that is what it is. > Update the RFC to show it as a cyclic time, and that makes the problem > go away (though you also need to limit certificate life, not just hope > that people will be sane with the certificates they issue). > > This is the whole point of this 2000 effort in the IETF - to find the places > where we have time/date related problems that should be fixed, and get > them really fixed. > > kre > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Mon Apr 28 22:42:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14943 for dns-security-outgoing; Mon, 28 Apr 1997 22:41:06 -0400 (EDT) To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-Reply-To: Your message of "Mon, 28 Apr 1997 10:02:19 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Apr 1997 01:07:01 +1000 Message-Id: <8743.862240021@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Mon, 28 Apr 1997 10:02:19 -0400 (EDT) From: "Donald E. Eastlake 3rd" Message-ID: All the DNSSEC RFCs will get revised in due course, actually quite soon for the one in questions (RFC 2065) and I'll make this change then. Fine. It would be absurd to try to re-issue the RFC instantly to change a couple of words Fine - but until it is revised, it remains on the list of protocols with a date problem. kre From owner-dns-security Mon Apr 28 22:47:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA15100 for dns-security-outgoing; Mon, 28 Apr 1997 22:47:09 -0400 (EDT) To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com Subject: Re: Year 2000 problems in the DNS In-Reply-To: Your message of "Fri, 25 Apr 1997 13:55:15 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Apr 1997 19:10:51 +1000 Message-Id: <5447.862218651@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Fri, 25 Apr 1997 13:55:15 -0400 (EDT) From: "Donald E. Eastlake 3rd" Message-ID: Though currently documented as an absolute time, I was just pointing out that it is really the number of seconds since 1 January 1970 modulo 2**32 (perhaps it could be called cyclic time). No, if it is documented as an absolute time, then that is what it is. Update the RFC to show it as a cyclic time, and that makes the problem go away (though you also need to limit certificate life, not just hope that people will be sane with the certificates they issue). This is the whole point of this 2000 effort in the IETF - to find the places where we have time/date related problems that should be fixed, and get them really fixed. kre From owner-dns-security Mon Apr 28 22:56:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA15281 for dns-security-outgoing; Mon, 28 Apr 1997 22:56:44 -0400 (EDT) From: Samuli Mattila Message-Id: <199704272046.XAA21909@pallo.cs.hut.fi> Subject: CLR Implementation To: dns-security@tis.com Date: Sun, 27 Apr 1997 23:46:00 +0300 (EETDST) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk I am looking for a little friendly advice here. If CRL were to be implemented to DNSSEC or similar system as an optional extension how should it be done? If we assume that we have a revocation instance (cri) which consists of array of trusted revocation servers (crls). Each time a key is to be revoced the distributed revocation instance (cri) reserves a counting index for that key with some majority decision voting protocol. Reserved index can be used only once and all indexes are to be reserved in order. The revoced key and index is then broadcasted(*) realtime in the network to all DNSSEC. Each DNSSEC keeps track of latest valid index. If DNSSEC notices an index missing it can request the revocation information corresponding the missing index from cri (or possibly from superzone). Whenever DNSSEC comes up or has no received index update in sertain time period, it can request the latest index from cri (or possibly from superzone). If DNSSEC receives a revocation broadcast it clears it's cache from target entry and removes the entry from it's db if it exists there. Does this make any sence? Could the index check be integrated to some name query? ...and how should the broadcast be done in wide area network? I am open to all suggestions. -- Samuli